What makes two reads independent?

They share no logic. One locates a value by position, the other by the label next to it, and they meet only when the two results are compared against a written tolerance. Shared parsing upstream makes them one read.

How would I notice this in an existing build?

Change something both reads depend on. If both sides move together and the comparison still passes, the second rail is a copy of the first rather than a check on it.

Is a dual read still worth building?

Yes. A silent layout shift or a wrong column cannot fool two genuinely different methods in the same way. The failure here is claiming the property without building it.

Failure catalogue · The verification is theater · 31 of 51

OBSERVED FAILURE MODE

Both rails from one blueprint.

A two independent reads check whose reads share their parse logic, field list, or configuration is one read reported twice. It agrees with itself perfectly, and would agree just as perfectly if the shared step were wrong. Agreement between two copies of one method is guaranteed, and means nothing. The page presents it as corroboration.

What we saw

In our own audits, a verification claiming two independent reads built both from the same field list and compared 537 values with themselves. The comparison passed. It could not have done anything else. A layout shift or a wrong column read would have moved both sides identically and the tie would still have come out clean. The page reported the dual read as its strongest guarantee, and the strength was the part that did not exist, because the paths never diverged.

Why it passes a glance

Independence is a property of code paths, not of output, and output is what a reviewer sees. Two rails that agree to the value look exactly like two rails built separately. The shared step sits upstream of both, so every downstream check stays consistent, and consistency is precisely what the reader was told to look for.

What addresses it

The verification-practice skill requires the two paths to share no logic: find each value once by where it sits in the file and once by the label beside it, then compare within a written tolerance. That is Principle 2, two independent reads beat one careful one. Shared parse logic is disclosed and counted as a single read rather than presented as corroboration.

Check your own file in two minutes

Trace both reads back to their first shared function, list, or configuration value.
Change that shared step deliberately and see whether both sides move together.
Rebuild one read by position and the other by label so they meet only at the compare.
Where a shared step cannot be removed, say so on the page and count the result as one read.

What this does not catch

Independent paths catch a wrong column, a shifted layout, and a mis-parsed row. They do not catch a symmetric error in the specification, because both rails implement the same wrong filter faithfully and agree to the cent. Independence protects the read, not the plan behind it.

Quick answers

What makes two reads independent?: They share no logic. One locates a value by position, the other by the label next to it, and they meet only when the two results are compared against a written tolerance. Shared parsing upstream makes them one read.
How would I notice this in an existing build?: Change something both reads depend on. If both sides move together and the comparison still passes, the second rail is a copy of the first rather than a check on it.
Is a dual read still worth building?: Yes. A silent layout shift or a wrong column cannot fool two genuinely different methods in the same way. The failure here is claiming the property without building it.

Nearby failures

The tolerance that ate the errorThe verification is theater Borrowed evidenceThe verification is theater The check that cannot failThe 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