How do I know a fix landed on the harm?

Run the original failure through the repaired build and watch it block, then revert the fix completely and watch the same case go red. If a partial revert stays green, the case proves redundancy rather than protection.

Why review the last round's changes first?

Because the fix is the most likely source of the next defect. Whole audit rounds have found every confirmed finding introduced by the previous round's repairs, at the moment nobody is suspicious of them.

Does testing against the harm make the rule redundant?

No. The rule is how the harm gets named, taught and applied to work nobody has seen yet. The test is what proves the wording still points at the harm after the code moved underneath it.

Failure catalogue · The verification is theater · 39 of 51

OBSERVED FAILURE MODE

The fix that landed on the letter.

A rule names a mechanism. The mechanism gets repaired, the wording is satisfied, and the harm the rule exists to prevent goes on landing exactly as before. A fix that cannot be shown stopping the original failure is not a fix, it is a change that reads as one. Reviewers grade it against the sentence, and the sentence passes.

What we saw

In our own audits the round-four fixes did this to us. Each one repaired the mechanism its rule named, each one passed review, and round five found the original harm still landing through a path the wording never described. Nothing had been done carelessly. The rules were followed to the letter, and the letter was the wrong target. That round is why every law here is now graded against the failure it was written for rather than against its own sentence.

Why it passes a glance

A fix is reviewed against the rule that motivated it, and the rule is the thing everyone is holding. If the wording is satisfied the change looks complete, tests written from the same wording go green, and the reviewer has no separate handle on the harm. The gap shows only when someone re-runs the original failure through the repaired build and watches what happens.

What addresses it

The adversarial-review skill requires sabotage that reproduces the measured defect rather than a neighbour of it, and it weights each round toward the previous round's diff because the fix is the most likely source of the next defect. Doctrine principle 11, Reconciliation proves arithmetic, not plausibility, carries the same lesson in its closing clause: test every rule against the harm, not against its own wording.

Check your own file in two minutes

Write the original failure as one sentence, an input and a wrong output, before touching the fix.
Run that exact input through the repaired build and watch it block.
Revert the fix completely and confirm the case goes red for the reason you expect.
Review the lines the last fix changed before reviewing anything else.

What this does not catch

Grading against the harm proves this failure is stopped. It does not prove the neighbouring shapes of it are, and a defect no lens is pointed at survives every round untouched. Rounds are not correctness: the defect rate falls without reaching zero.

Quick answers

How do I know a fix landed on the harm?: Run the original failure through the repaired build and watch it block, then revert the fix completely and watch the same case go red. If a partial revert stays green, the case proves redundancy rather than protection.
Why review the last round's changes first?: Because the fix is the most likely source of the next defect. Whole audit rounds have found every confirmed finding introduced by the previous round's repairs, at the moment nobody is suspicious of them.
Does testing against the harm make the rule redundant?: No. The rule is how the harm gets named, taught and applied to work nobody has seen yet. The test is what proves the wording still points at the harm after the code moved underneath it.

Nearby failures

The honest refusal that catches nothingThe verification is theater The screen calibrated by its own targetThe verification is theater Fire-test theaterThe verification is theater

Last updated 2026-09-02 · Dylan, founder · one of 51 observed failure modes, every one seen in a real build or in our own audits, none invented.

Get the free skill → The doctrine All 51 failure modes