Verify

Covers splitting a claim into checkable assertions, the three-state verdict (pass, fail, not-reached), and the specific failure modes that survive a careless check.

Keywords: verify, verification, grade, verdict, acceptance, prove it, did it actually work, confirm the fix, check the claim, QA sign-off.

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 in the table, the running process, the response from the live endpoint, the committed file. Write down which one you looked at.
3. Check that the artifact you read is the artifact that shipped. A local working tree, a stale branch, a staging database and the deployed thing are different objects. Confirm they are the same, or say which one you graded.
4. Try to make each assertion false. Find the input, the ordering, or the environment where it breaks. A verification that only confirms is a re-reading.
5. Emit a verdict per assertion, with the instrument named.

Three states, not two

PASS · FAIL · NOT-REACHED

The third one is the one people drop, and dropping it is how a broken check reads as a passing one. If the probe did not run — no fixture, no credentials, the environment was missing, the code path was never entered — that is not a pass. It is an absence of information, and it must render differently from a clean result.

Unmeasured and measured-clean must never look the same. If your report cannot distinguish "I checked and it was fine" from "I could not check", the report is broken regardless of the verdict.

Composition rule: an overall verdict cannot be PASS if any assertion is NOT-REACHED. A headline PASS printed above a NOT-REACHED line reproduces the exact collapse this section exists to prevent. Say "PASS on 2 of 3" and let the third stay visible.

Failure modes that survive a careless check

These are the ones that get past people who are genuinely paying attention.

Grade the premise, not just the work

Sometimes the change is correctly built on something that cannot hold — a privilege boundary that does not exist in the environment, an ordering guarantee nothing enforces, a file that another process rewrites. The work is fine and the claim still fails.

When you reject on a premise, say which premise and what measurement killed it. "This relies on X being true; I measured X and it is false" is actionable. "Doesn't look right" is not.

Writing the verdict

State, in this order: the verdict, what you checked it against, and what the verdict does not extend to.

PASS on 2 of 3 intents, verified against the production table — not the migration script.
  1. backfill touched 40,312 rows — PASS. Counted rows with filled_at set against the
     pre-run snapshot. The job's own log said "40k", which was rounded, not measured.
  2. no existing values were overwritten — PASS. Checksum of the untouched column is
     unchanged from the snapshot.
  3. re-running is idempotent — NOT-REACHED. No safe way to re-run against production,
     and staging has 0 matching rows, so the staging run would have proved nothing.
THIS VERDICT DOES NOT EXTEND TO: rows created after the snapshot was taken.

Note what the third line does. Running it in staging would have produced a green — against zero matching rows. A check that cannot fail is not a check, and reporting it as NOT-REACHED is the honest result.

The scope line is not a confession and it is not optional. Frame it as what this verdict covers, which is answerable even when coverage was complete. A verdict that lists only what was confirmed reads as total coverage, and the next person will believe it.

Bounce, or fix and hand back?

Bounce when the work is wrong, when the premise fails, or when the claim overstates what the artifact does. Give the reason and the measurement, not a vibe — the maker has to act on it.

Locate and post when the work is right and only the receipt is missing — the run happened but the log was left somewhere nobody else can read. Attaching the evidence is faster than a round trip and keeps the record honest.

On verifying your own work

Auditing your own claim before you publish it is worth doing, and this procedure applies to it. It lowers what a verifier finds.

It does not make you the verifier of record. If a process names a maker and a separate verifier, the point is that two different contexts looked at the artifact — grading your own work reproduces the reasoning that produced the mistake. Self-audit reduces the defect rate; it does not discharge the independent check.

See also

code-review — the complementary skill. Use code-review when you have a diff and the question is whether the change is any good; use verify when you have a claim and the question is whether it is true.