Remake, Not Remaster

"Remake from the spirit of the original. Don't remaster the old data into the new shape."

There Was a Predecessor

Recall isn't the first attempt. Before it, a legacy metadata database indexed the same archive with an older speech model. Recall replaces its implementation — but how it treats the old project is the whole lesson, and it's a trap most engineers walk straight into.

The instinct is migration: take the old database, transform it in place, mutate it into the new schema, done. It feels efficient. It is a trap. The old data was produced by a weaker pipeline and carries the pipeline's flaws — silence hallucinations, stock phrases, Korean/English confusion. Migrate it in place and you don't get a clean new system. You get the old rot wearing new clothes, and now you can't tell which rows are trustworthy.

Remaster vs Remake

Borrow the game-industry distinction:

Remaster — keep the old content, improve the texture. Upscale the same assets. This is the migration mindset: old data stays, you just polish it.
Remake — rebuild from the spirit of the original, using current ground truth. New engine, new evidence, better schema, in one pass.

Recall is a remake. The current ground truth is a better ASR model, a two-host architecture, and an evidence-first data model. So the transcripts get re-derived from that ground truth, not up-scaled from the old ones. You don't remaster a contaminated corpus into a clean one — the contamination survives the polish.

The Legacy Becomes Two Things, Neither of Them 'Truth'

So what happens to the old project? It becomes two carefully bounded things:

A parity oracle. The legacy repo is frozen, untouched, and used only to answer one question: "did the new system keep every feature the old one had?" It's a reference for completeness, not a source of data. It never runs; it's the answer key.
A one-time, read-only import. The old Markdown transcripts are imported once as clearly-labeled legacy evidence — its own kind, quarantined — so nothing is lost. But search runs on freshly structured, timestamped segments, not on that Markdown. The Markdown is a human-readable export, never the live data model.

That's the discipline: the old thing is a reference and a quarantined import, but current ground truth is the source of the new system. The moment you let old data become the truth, you've remastered the rot. Remake instead.

Code

Migration vs Remake — where the truth comes from·text

MIGRATION (remaster):
  old DB  ──mutate in place──▶  new DB
  (old data IS the truth; flaws survive the polish)

REMAKE:
  current ground truth ──re-derive──▶ new DB
  old project ──frozen──▶ parity oracle  (answer key, never runs)
  old markdown ──import once, read-only──▶ quarantined evidence

The test: is the OLD DATA the source of truth,
or is CURRENT GROUND TRUTH? If old data → you remastered the rot.

Exercise

Think of an old project, dataset, or document you're tempted to 'clean up and reuse.' Ask the honest question: do you actually trust the old content, or are you keeping it because re-doing it feels wasteful? If you don't trust it, migrating it forward just hides the distrust. Decide what current ground truth you'd rebuild from instead — and what role (if any) the old thing should play: parity oracle, quarantined import, or nothing.

Hint

The tell is the sentence 'it's already there, so let's just reuse it.' That's the remaster instinct. If the old content came from a process you no longer trust, reuse imports the flaws. The remake move is: freeze the old as a reference, re-derive from ground truth, and never let old data quietly become the new truth.