Content Hash Detects Stale

"A summary that doesn't know which text it summarized can't know when it's wrong."

The Problem With Derived Things

A transcript spawns children: a summary, a title, a search index, maybe a future embedding. Each is derived from a specific version of the text. Here's the quiet danger: the text can change (you corrected it), but the derived children don't automatically know. Yesterday's summary is still sitting there, quoting a line you've since fixed, looking exactly as authoritative as a fresh one. How does the system tell a current summary from a stale one?

The weak answer is timestamps — 'the summary is older than the release, so maybe it's stale.' But clocks lie, jobs run out of order, and 'older' doesn't prove 'derived from a different version.' Recall uses something exact instead: the content hash.

Bind Every Child to the Hash of Its Parent

Every release carries a content hash — a fingerprint computed from its exact text. When Recall generates a summary, it stamps that summary with the content hash of the release it summarized. The summary doesn't just know which video it came from; it knows which exact version of the text. That stamp is the whole trick.

Now staleness detection is trivial and deterministic. Take the video's current release, read its content hash. Read the hash stamped on the summary. If they match, the summary reflects the current text. If they differ, the text has moved since the summary was made — the summary is provably stale, and Recall can flag it for regeneration. No timestamps, no guessing, no 'probably.' Two hashes are equal or they aren't.

This Is Why Branching Was Non-Negotiable

Look back at the last lesson and it clicks: corrections had to branch to a new version precisely so the content hash would change. If corrections had overwritten the text in place, the hash could have stayed the same (or changed with no old version to compare against), and the summary would have no way to know its source moved. The immutable run, the versioned release, and the content-hash stamp are one system with one purpose: make every derived artifact able to detect that its source changed. That is content-addressing applied to lineage — the same idea that lets version-control systems know a file changed by its hash, pointed at the problem of keeping summaries honest.

Code

Staleness is a hash comparison, not a guess·python

# Every derived artifact stamps the hash of the release it used.
summary = {
    'video_id': video_id,
    'text': generated_summary,
    'source_release_sha256': release.content_sha256,  # the stamp
}

# Detecting stale is now exact and deterministic:
def is_stale(summary, current_release) -> bool:
    return summary['source_release_sha256'] != current_release.content_sha256

# match  -> summary reflects the current text
# differ -> the text was corrected after this summary; regenerate
# No clocks. No 'probably older'. Two hashes are equal or they aren't.

Exercise

Find a derived artifact in your own work — a cached computation, a generated report, a summary, an index — that could go stale when its source changes. Ask: does it record the identity (a hash, a version id) of the exact source it was built from? If it only records a timestamp, or nothing, design the stamp. Then write the one-line staleness check that compares the stamped identity to the source's current identity.

Hint

If your staleness logic contains the word 'older' or a time comparison, it's a heuristic that can be fooled. Replace it with identity: stamp the derived thing with the hash/version of its source, and detect stale by inequality. The goal is a check that returns a hard true/false, not a 'probably.'