Failure catalogue · The number is plausible, and wrong · 1 of 51
OBSERVED FAILURE MODE
The 100x slip that ties perfectly.
A magnitude slip is a single value entered at the wrong scale: a price keyed as 5900.00 where 59.00 belongs. The error multiplies through every subtotal consistently, so every reconciliation still ties, and the headline carries a figure no reader would believe if anyone had looked at the row behind it.
What we saw
In our own audits we plant a price of 5900.00 where 59.00 belongs and send the file through a full build. Every anchor ties. The line ties to its invoice, the invoice ties to the export's own stated total, and two independent reads agree to the cent, because both are reading the same wrong number correctly. The headline triples. Nothing on the page is arithmetically false, and nothing on it is true either. The only tell is the row itself, sitting far above what its plan normally charges.
Why it passes a glance
A glance sees a total that ties and stops there. A total check is arithmetic over the values present, so a wrong value passes it as cleanly as a right one. A green badge on reconciliation is a claim about addition, not about magnitude, and the two independent reads that catch a wrong column both read this value correctly. Consistency is exactly what the slip manufactures.
What addresses it
Doctrine principle 11, reconciliation proves arithmetic, not plausibility, makes a screen mandatory before any figure is certified: every value column compared against its group's typical value, in both directions, with each flagged row stating its share of every headline it feeds. The hostile-exports skill carries the same warning at the file level, that arithmetic tying is not magnitude clearance.
Check your own file in two minutes
- Sort your largest value column high to low and read the top twenty rows against what that plan, SKU, or category normally charges.
- Do the same from the low end, since a decimal that slipped the other way hides at the bottom rather than the top.
- For any row that looks off, recompute the headline with that row valued at its group's typical figure and see how far the headline moves.
- If the move is material, treat the figure as unproven until a person rules on the row, and say that on the page.
What this does not catch
The screen finds values that sit far from their group. It cannot find a slip that is small, one that repeats across enough rows to move the group's own typical value, or a column whose groups are too thin to compare against. Those columns are reported unscreened, never certified.
Quick answers
- Does a total that ties prove the numbers are right?
- It proves the addition is right, and a value entered at the wrong scale ties at every level of that addition.
- Why compare each value against its own group instead of a global range?
- A group's typical value is the only comparison that survives a catalogue where a small plan and a large contract are both ordinary.
- What happens when the slipped row is the only row in its group?
- The screen reports that group as uncalibrated by name, and no figure resting on it may be described as certified.
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.