Corrections Branch

"A correction is a new version, not a smaller lie on top of the old one."

The Moment You Spot a Mistake

Search turns up a segment where the model misheard a name — it wrote 'Mathilda' where Dad clearly said 'Pippa.' You want to fix it. This is the exact fork in the road where most systems make the wrong choice. The tempting move is to reach into the transcript and edit that segment in place. It's one UPDATE. It feels done.

Recall refuses to make that edit. A correction never mutates the raw run, and it never mutates the existing release either. Instead it branches: the correction is recorded as an explicit segment replacement, and that produces a brand-new release version with a fresh content hash. The old release still exists. The frozen run underneath is, as always, untouched.

Why Branching Beats Overwriting

Three payoffs, and they compound:

The evidence survives. The immutable run still holds exactly what the model said, so 'Mathilda' is preserved as the recorded fact even though the product now shows 'Pippa.' You can always prove the model's error was the model's, not yours.
The change is visible. Because the corrected text is a new version with a new content hash, the correction is a first-class event, not a silent mutation. You can see that v2 exists, what it changed, and when.
Staleness becomes detectable. This is the big one, and the next lesson is entirely about it: any summary or index built on the old release named the old content hash. The new release has a new hash. That mismatch is how the system knows the summary is now out of date.

Copy-on-Write, Applied to Truth

This is the copy-on-write pattern you've seen in filesystems and functional data structures, applied to a transcript. You don't mutate the shared thing; you write a new version that shares everything unchanged and differs only where you corrected it. The old version stays valid for anyone (or any artifact) still pointing at it, and the new version becomes current. Overwriting is a destructive act that erases history; branching is an additive act that records history. When the data matters — and your own memory matters — you want the additive one.

Code

A correction records a replacement and births a new release·sql

-- The correction itself is explicit and stored, not a silent UPDATE.
CREATE TABLE corrections (
  correction_id  TEXT PRIMARY KEY,
  from_release   TEXT NOT NULL,   -- the release being corrected
  segment_index  INTEGER NOT NULL,
  old_text       TEXT NOT NULL,   -- "...Mathilda..."
  new_text       TEXT NOT NULL,   -- "...Pippa..."
  created_at     TEXT NOT NULL
);

-- Applying it does NOT edit the old release. It creates a new one:
--   release v2  (run_id = same frozen run)
--               (release_number = 2, is_current = 1)
--               (content_sha256 = hash of the corrected text)
-- release v1 still exists; the raw run never moved.

Exercise

Find an edit path in your own work that overwrites a value to 'fix' it — a corrected field, an updated status, a patched record. Trace what depends on that value downstream (a cached result, a report, a derived count). Now ask: when you overwrite, does anything downstream learn that it's stale? Redesign the fix as a new version with its own identity, and note how a downstream consumer could detect it changed.

Hint

The failure mode of overwriting isn't the edit itself — it's that everything derived from the old value keeps trusting a number that quietly moved. Branch instead: new version, new hash/id. Then a downstream artifact that remembers which version it was built from can compare and notice it's out of date. That comparison is impossible if you overwrote.