Why is one shared fire test not enough for two checks?

Because the run turned one row red. The other row's behaviour was never observed at all. Evidence attached to more claims than it exercised is an assertion, not a record.

What should a check's evidence contain?

The captured run where that exact row went red through the production path, naming the check, produced by sabotaging the deployed code behind it, with the restored run showing it green again.

Does this apply to informational rows?

No. An INFO row makes no guarantee and needs no red run. The requirement attaches to any row rendered as a pass, because that is the row making a claim.

Failure catalogue · The verification is theater · 30 of 51

OBSERVED FAILURE MODE

Borrowed evidence.

Two check rows cite the same fire test log as proof that each of them fires. One of them might have been exercised by that run; the other is claiming credit for work done on its behalf. Shared evidence proves at most one check, and usually proves neither. The page shows two guarantees and holds one, at best.

What we saw

In our own audits, two checks pointed at one fire-test log. Neither row named itself in the evidence it cited. The log recorded a red run, so the evidence looked real, and each row inherited the credibility of a genuine captured failure. Following the log back showed a single check turning red and two rows on the page claiming the result. Nobody had faked anything. The evidence was true, and it was attached to more rows than it could support.

Why it passes a glance

The evidence file is genuine, which defeats a review that asks only whether evidence exists. A reader comparing rows to logs sees a real red run behind each claim. The mismatch appears only if someone opens the log and asks which check it exercised, and evidence rarely gets opened once its presence has been confirmed.

What addresses it

The verification-practice skill treats evidence as a per check artifact rather than a per suite one: each rendered check keeps its own captured red run, naming that exact check, produced by sabotaging the deployed code behind it. Principle 6, test that a check fires, not that it exists, is enforced per row, so a row without its own evidence may not render as a pass.

Check your own file in two minutes

List every rendered check and the evidence file it cites.
Flag any file cited more than once.
Open each log and confirm it names the row it is attached to.
Generate a separate red run for every check that was sharing one.

What this does not catch

One evidence file per check proves each row is capable of failing. It does not prove the rows are independent of each other, and two checks reading one computed value can both fail for a single underlying reason. Independence of evidence is not independence of logic.

Quick answers

Why is one shared fire test not enough for two checks?: Because the run turned one row red. The other row's behaviour was never observed at all. Evidence attached to more claims than it exercised is an assertion, not a record.
What should a check's evidence contain?: The captured run where that exact row went red through the production path, naming the check, produced by sabotaging the deployed code behind it, with the restored run showing it green again.
Does this apply to informational rows?: No. An INFO row makes no guarantee and needs no red run. The requirement attaches to any row rendered as a pass, because that is the row making a claim.

Nearby failures

Fire-test theaterThe verification is theater The check that cannot failThe verification is theater Both rails from one blueprintThe 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