Raw Is Immutable

"What the machine returned is a fact. Whether it's true is a separate question."

Two Different Things Wearing One Word

When a speech model transcribes a video, it hands back some text. It is dangerously easy to call that text 'the transcript' and move on. But that text is really two different things fused together, and Recall's whole data model depends on prying them apart:

What the model returned — a hard fact. This exact model, at this exact configuration, given these exact audio bytes, produced this exact output. That never changes. It happened.
What is actually true — a judgment. Did it hear the words right? Did it hallucinate during silence? Did it confuse Korean and English? That can be wrong, and you'll want to fix it.

Fuse these and you get the classic bug: you 'fix' a transcript by editing it, and now you've destroyed the record of what the model actually said. Recall refuses. The raw output is immutable evidence — an accepted transcription run can never be updated or deleted. Corrections happen in a separate layer (the next lessons). The evidence is frozen the instant it's accepted.

Why Freezing the Raw Output Matters

Immutability isn't neatness for its own sake. It buys three concrete powers:

Audit. Six months later you can ask, 'did the summary faithfully represent what was actually transcribed?' — but only if the original transcription still exists unaltered. Overwrite it and the question becomes unanswerable.
Re-derivation. Every downstream artifact (release, summary, index) is derived from the evidence. If a projection step had a bug, you can re-run it against the untouched evidence. If the evidence itself were mutable, you'd have nothing solid to re-derive from.
Drift detection. A new model version returns different text? Keep both runs and you can measure the difference. Overwrite the old one and the drift is invisible.

Think Like a Lab, Not Like a Notepad

A scientific lab keeps the raw instrument readings forever, even after publishing a cleaned dataset — because the cleaned data is a claim and the raw readings are the evidence behind it. A notepad, by contrast, just gets erased and rewritten. Most software treats data like a notepad: edit in place, keep the latest. Recall treats it like a lab: the raw reading is permanent, and every polished version above it is a dated, traceable claim you can always check against the original. That single reframing — raw output is evidence, not a draft — is the most portable idea in this whole quest.

Code

The run table is append-only evidence (shape sketch)·sql

-- An accepted transcription run: frozen the instant it lands.
CREATE TABLE transcript_runs (
  run_id           TEXT PRIMARY KEY,
  video_id         TEXT NOT NULL,
  source_sha256    TEXT NOT NULL,   -- exact source bytes
  asr_config_sha   TEXT NOT NULL,   -- exact model + settings
  proxy_config_sha TEXT NOT NULL,   -- exact audio prep
  raw_response     TEXT NOT NULL,   -- the model's exact output
  accepted_at      TEXT NOT NULL,
  -- one run per (video + source + asr config + proxy config)
  UNIQUE (video_id, source_sha256, asr_config_sha, proxy_config_sha)
);

-- No UPDATE, no DELETE path in application code.
-- Corrections live in a SEPARATE releases table (next lessons).

Exercise

Find a place in a system you know where 'the data' is edited in place — a status that gets overwritten, a record that's updated to fix a mistake, a field that always holds 'the latest.' Ask: could you later prove what the value originally was? If not, redesign it so the original is frozen evidence and the correction is a new, dated layer on top. Note what audit or drift question that unlocks.

Hint

The tell is any column that means 'the current value' with no history behind it. Split it: an immutable record of what was first observed/returned, plus a separate, versioned layer for corrections. Now 'what did it originally say?' and 'what do we believe now?' are two answerable questions instead of one lost one.