verifylisted

# Verify **A verifier's job is to distrust the shape of a claim and go look at the thing.** This is not code review. Code review asks *is this change any good*. Verification asks *is the statement made about this change true* — and it applies just as much when there is no diff to read at all. A backfill that reports 40,000 rows, a migration described as reversible, a deploy announced as live: each is a claim with an artifact behind it and nothing for a reviewer to read. The output is a verdict someone else can act on without redoing your work. ## The one rule **Check the effect, not the report of the effect.** Almost every bad verification is some version of accepting the report. The command exited 0. The function is defined. The follow-up ticket exists. The log says success. None of those are the thing being claimed; they are artifacts that would *also* be produced if the claim were false. Before accepting any piece of evidence, ask: **what would look identical if the claim were wrong?** If the answer is "this exact output", the evidence is not evidence and you need a different instrument. ## Procedure 1. **Extract the claim into separate assertions.** "Backfilled the table and made it idempotent" is two claims. Grade each on its own. A single verdict over a bundle lets one false thing launder through on the strength of the true ones. 2. **Name the artifact for each assertion.** Not the description, not the done-result, not the author's summary — the rows i