"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.