C.W.K.
Stream
Lesson 02 of 04 · published

Sources Before the Brain

~11 min · provenance, checksum, op-log, preservation

Level 0Unmarked Path
0 XP0/35 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"Save the raw stone before you carve it. The chisel can slip; the stone should not."

Preserve, Then Interpret

Carve does something before Pippa ever reads the rough plan: it preserves the exact inputs. Every carve stores its raw material — the pasted text, the screenshots — under a per-import folder, each with a sha256 checksum, and appends a carve event to an append-only op-log. Only then does the brain run. The order is the whole point: preservation is not a step after interpretation, it is the step before it. Because normalization is an act of judgment — Pippa deciding what a blurry table cell means — the raw source has to survive independently, so the interpretation can always be checked against the thing it interpreted.

The Op-Log Discipline

The imports log follows the same discipline as breadcrumbs: it is append-only, folded on read, never rewritten. A carve appends a carve event; accepting a proposal later appends an accept event. You never edit a past entry to reflect a new state — you append the new state and let the fold produce the current view. This is the same refusal-to-overwrite that runs through the whole engine, applied to imports: the history of what was imported and when is evidence, and evidence is appended to, not edited.

Why This Traceability Pays

Months later, a day in the plan might look wrong — a hotel in the wrong town, a date that doesn't line up. Because the sources were preserved with checksums and logged, you can trace that day back to the exact rough input it was carved from and see whether the error was in the source or in the carving. Without preservation, a normalization mistake is unfixable at the root: you have the wrong output and no way to tell where it came from. Sources-first turns "the plan is wrong somewhere" into "here is the exact stone this was carved from" — the difference between a mystery and a diff.

A field-earned deploy rule lives here: when the payload sent to the brain grows a new field (like image inputs), the brain side must be updated first. An older brain silently ignores an unknown field, quietly degrading a vision carve to text-only with no error — a machine for producing confident nonsense. Deploy the consumer before the producer, or the extra data vanishes without a trace.

Code

Preserve first, then carve·text
carve(rough_input):
    id = new_import_id()
    save(rough/{id}/text.md,  input.text,   sha256=...)   # BEFORE the brain
    save(rough/{id}/shot-1.png, input.image, sha256=...)
    append(imports.jsonl, {event: 'carve', id, checksums})
    # --- only now does the brain run ---
    scaffold = pippa.normalize(input)
    return proposal(scaffold)   # accept appends {event: 'accept', id}

# The op-log is append-only, folded on read, never rewritten.
# Every carved day can be traced back to the stone it came from.

External links

Exercise

Think of a time a tool transformed your input — an importer, a converter, an AI summary — and the output was subtly wrong. Could you still get back the exact original input to see where it went wrong, or had the tool discarded it? Now design the minimum preservation that would have made the error traceable: what would you save, and how would you prove it was intact?
Hint
The traceability test is whether you can still produce the exact input a bad output was derived from. If the tool kept the source with a checksum, a wrong result is a diff you can inspect. If it discarded the source, the same wrong result is a permanent mystery. Preservation is cheap; the mystery is not.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.