A Backup Is a Check You Run, Not a Claim You Assume

Choose your door

• Builder — Builder Track: audit one of your own safety claims right now.
• Architect — Architect Track: claims vs. checks, and the reviewer's role.
• Translator — Bridge below.
• Validator — Gates at the bottom.

The story this comes from

The harness docs asserted a Drive mirror — the cross-project doctrine layer was "backed up." An independent adversarial reviewer (Module 5's witness principle, applied to documents) went looking for the mirror. It did not exist. The claim had been written down once, felt true ever after, and was never checked. The most-leveraged layer in the whole system had a single copy on one machine.

The fix landed within the hour: the folder became a private git repo with full history and a remote copy — the same chassis discipline as every project.

The sister lesson came from the same day's GitHub sight grant: docs written in the "blind era" confidently stated three repos were local-only. Direct sight of GitHub showed all three already existed there — and two duplicate repos had been created from that false memory. Reconstruction drifts; sight doesn't. A record of what you believe is true decays silently; only looking at the thing itself is ground truth.

Translator Bridge

Every school has fire drills, and the reason isn't that anyone doubts the doors exist. The claim is "we can evacuate in three minutes." The drill is running it — and drills routinely surface the propped-shut exit, the class that can't hear the alarm. "The docs say we have a Drive mirror" without ever opening Drive is a school that has fire-exit signage but has never once walked the route.

Builder Track (DO FIRST)

1. Write down three safety claims you currently believe about your own work. ("My photos are backed up." "That document is in Drive." "A teammate has the latest version.")
2. Pick one. Now run the check: open the backup location and confirm today's file is actually there — better, restore one file from it. A backup you've never restored from is a claim.
3. Score honestly: claim CONFIRMED or claim EXPOSED. If exposed — fix it now, not later; the B2 fix took under an hour and the fix window is always cheapest immediately after the finding.
4. Sister-lesson drill: find one fact you've been repeating from memory about your own systems (which folder something's in, whether a site has a page). Go look at the actual thing. Did memory match sight?

Architect Track (MODEL FIRST)

Three states a safety property can be in — deliberately parallel to Module 4's three regimes:

Design rules that fall out: every safety claim in a doc should carry a date and a method ("verified 2026-07-11 by direct read"), undated claims are treated as rumors; the reviewer who hunts for false claims must be independent of the author (author-verifier correlation is exactly what let B2 survive — the writer of the claim is the least likely person to doubt it); and where possible, promote checks to enforced checks (the harness repo now gets history and remote copy on every push, structurally, instead of by assertion).

The deepest version: prefer sight over reconstruction everywhere. Before creating a repo, look at GitHub. Before citing a file, open it. The duplicate-repo incident cost real cleanup and came entirely from trusting a well-written memory.

Validator Gates

1. Gate 1: In one sentence: what's the difference between a backup and a claim of a backup?
2. Gate 2: Why was the author of the Drive-mirror line the wrong person to catch B2?
3. Gate 3: State the sister lesson and give the concrete incident that proved it.
4. Gate 4: What two pieces of metadata turn a safety claim into a check?
5. Gate 5 (own words): Write the one-line rule you'd add to your own workflow so this class of failure can't happen to you.