Run vs Release

"One asks what the model said. The other asks what we're showing today."

Two Nouns, Two Questions

Recall splits a transcript into two first-class things with two very different jobs. Learn which question each answers and the whole data model clicks into place:

Run answers: "What exactly did this model, at this configuration, return for these source bytes?" It is frozen evidence. It never changes.
Release answers: "Which version of the text is the product presenting right now, and deriving summaries and search from?" It is a version. It changes as you correct it.

These are not two names for the same row. They live in separate tables with separate rules. The run is written once and sealed. The release is a moving, numbered pointer that says 'this is the current best text for this video.'

One Run, Many Releases

Here's the relationship that matters: a single immutable run can sit underneath many releases over time. The model transcribed the video once (that's the run). Then you noticed it misheard a name, so you made a correction — that produced release v2. Later you fixed a timestamp — release v3. The run never moved; the releases stacked. At any moment exactly one release per video is marked current, and that's what search and summaries use.

Think of it like version control: the run is an immutable commit — a permanent record of exactly what was captured. The current release is like a branch pointer that moves to the newest good version. You can always walk back to the raw commit, and you can always ask 'which version is HEAD right now?' Two questions, two answers, never conflated.

Why Not Just Edit the Text?

Because 'just edit the text' collapses both questions into one mutable blob and loses both answers. Edit in place and you can no longer say what the model originally returned (the run is gone) or track how the text evolved (the versions are gone). By keeping the run frozen and the release versioned, Recall can answer 'what did the machine actually say?' and 'what do we present now?' and 'how did we get from one to the other?' — all at once. The next lesson shows what happens at the moment of correction, and why it branches instead of overwrites.

Code

Frozen run underneath; versioned releases on top·sql

-- Evidence: one row per (video, source, config). Sealed.
-- transcript_runs(run_id, video_id, raw_response, ...)  [immutable]

-- Product truth: many versions per video, one current.
CREATE TABLE transcript_releases (
  release_id     TEXT PRIMARY KEY,
  video_id       TEXT NOT NULL,
  run_id         TEXT NOT NULL,     -- which evidence it derives from
  release_number INTEGER NOT NULL,  -- v1, v2, v3 ...
  content_sha256 TEXT NOT NULL,     -- hash of THIS version's text
  is_current     INTEGER NOT NULL,  -- exactly one =1 per video
  UNIQUE (video_id, release_number)
);

-- run  = "what did the model say?"     (never changes)
-- release = "what are we showing now?"  (v1 -> v2 -> v3)

Exercise

Take a record in your own work that has a 'current value' and gets updated over time — a document, a config, a profile. Split it into the two-question model: what is the immutable evidence of what was originally captured, and what is the versioned 'current' layer on top? Sketch the two tables (or two shapes) and mark where 'exactly one current' lives. Then name a question the split lets you answer that in-place editing couldn't.

Hint

If you can only ever see the latest value, you've fused the run and the release. The fix is two layers: an append-only record of what was captured, and a versioned pointer to the current best version. The payoff question is usually 'how did we get from the original to now?' — answerable only if both layers exist.