Failure catalogue · The verification is theater · 27 of 51
OBSERVED FAILURE MODE
The check that cannot fail.
A rendered check row that no input can turn red is decoration with a runtime cost. It sits beside real gates in the same type and colour, it counts toward the number of checks a page advertises, and a reader has no way to tell a guarantee from a printed word. The build passes it every time, by construction.
What we saw
In our own audits we caught a shipped check that was literally pass if true. It rendered green on four surfaces beside real gates, in identical styling, indistinguishable to any reader of the page. Nothing about the row disclosed that no data could ever change it. The surrounding rows were genuine, which is what made the decoration effective: the page's credibility came from the checks that worked, and the row that could not fail borrowed all of it.
Why it passes a glance
It renders identically to a working gate, which is the whole failure. Reviewers count check rows rather than exercise them, and a row that always passes never draws attention by breaking a build. On a page whose other rows are real, the inert row reads as one more piece of evidence rather than as a claim with nothing behind it.
What addresses it
The verification-practice skill enforces the rule per row: a rendered check must have a fire test that turns that exact row red through the production pipeline, and a row without one may not render as PASS. Principle 6, test that a check fires, not that it exists, also supplies the vocabulary. A row that cannot change renders as INFO or not at all.
Check your own file in two minutes
- For each check row on the page, name the input that would turn it red.
- Create that input and run the build.
- Delete any row you cannot make fail, or restate it as informational with no green mark.
- Keep the captured red run beside the check as its evidence.
What this does not catch
This proves each rendered row is capable of failing. It does not prove the row checks the right thing, and a fire test aimed at a neighbouring scenario can turn a row red while the original defect still passes. Mechanics can be gated; meaning cannot.
Quick answers
- What is the difference between PASS and INFO on a certified page?
- PASS means the row is red capable and fire tested through the production path, so it carries a guarantee. INFO means the row informs without claiming one. A row that cannot fail may render as INFO, never as PASS.
- Why not just remove weak checks quietly?
- Removing them is the right move. The failure is rendering them as guarantees. A row that cannot change should be deleted or demoted, because leaving it green makes a claim the build never earned.
- Can a build enforce this automatically?
- The mechanical half can be enforced. A gate can require fire test evidence for every rendered pass and fail the build when a row has none. What it cannot judge is whether the check tests the thing that matters.
Nearby failures
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.