Failure catalogue · The file lies · 16 of 51
OBSERVED FAILURE MODE
The join that quietly covers 62%.
A reference join is a filter nobody declared. When only 62% of rows find a match, the report is built from the survivors and says nothing, because a join reports what it matched and never what it dropped. The averages that follow describe the matched subset while the heading describes the whole business.
What we saw
A build at Meridian Journal Group joined transaction rows to a title reference table and matched 62% of them. The report that came out was computed correctly over everything that matched, and the rest of the rows were simply absent from it. No error appeared, because nothing had asked how many rows survived the join. Totals inside the report tied to each other, since they were all built from the same surviving set, and the one figure that would have exposed the gap, the file's own stated grand total, was never compared against the post-join sum.
Why it passes a glance
A join that drops rows is not an error condition; it is the normal behaviour of a join. Every figure computed afterwards is internally consistent, because they all rest on the same subset. A glance sees plausible numbers of a plausible size. The absence is invisible unless somebody prints the coverage rate or ties the post-join total back to the total the source file states.
What addresses it
Doctrine principle 5, fail closed and stale, is what makes coverage matter: join coverage is a published number with a configured threshold, and below it the build holds the prior good pack, marks it as having a newer cut under review, and tells a person, rather than averaging the survivors. The verification-practice skill supplies the tie that exposes the gap, reconciling the post-join total against the total the source file states about itself.
Check your own file in two minutes
- Count rows before and after every join in your build, and print both numbers.
- Sum your money column before and after the join, and compare the difference against the file's own stated total.
- Read a sample of the unmatched rows, since they are usually a category the reference table has never heard of.
- Set a coverage threshold a person chose, and make a build below it stop instead of publishing.
What this does not catch
A coverage number tells you how many rows matched. It cannot tell you whether they matched correctly, and a join that matches everything to the wrong reference row reports full coverage while quietly relabelling the business.
Quick answers
- Is a join that drops rows always wrong?
- No, but a report built from the survivors is describing a subset, and the page has to say which subset.
- What number should be on the page?
- The share of rows that matched, beside the figures built from them, against a threshold a person chose.
- How does a coverage gap escape the totals?
- Every total in the report is computed from the same surviving rows, so they agree with each other and only the source file's own total disagrees.
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.