Failure catalogue · The file lies · 13 of 51
OBSERVED FAILURE MODE
Names doing the work of keys.
An export with no stable identifier leaves a name doing a key's job. Two accounts that share a name silently merge, and one account written two ways silently splits. Either way the history that gets built is fiction, and it is a fiction that adds up perfectly against every total the file states.
What we saw
A subscriber export at Meridian Journal Group carried no account number, only a display name. Two distinct accounts shared a name closely enough to be treated as one, and their histories were combined into a single record that had never existed. Grand totals were unaffected, because merging two accounts moves no money; only the per-account view was wrong, and that is the view somebody acts on. The join keyed on the name matched one row where it should have matched two, and the build had no way to notice, because a match is what a join is for.
Why it passes a glance
Every total ties, since merging two rows under one label changes nothing about the sum. The page shows one account with a plausible history. A reviewer who does not already know both accounts exist has nothing to compare against, and a coverage check that counts matched rows counts this as a match. The failure lives entirely in identity, which arithmetic cannot see.
What addresses it
Doctrine principle 3, refuse to guess, is exact here: a label appearing more than once is an error to raise, never a join to guess, and a label appearing zero times is an error too. The anchor-discovery skill enforces it in the spec, selecting rows by what they say and refusing rather than picking when a selector matches zero rows or several, and blocking a file whose entity column holds values no alias covers.
Check your own file in two minutes
- Count distinct names and distinct identifiers in your file; if there is no identifier column, say so out loud before building anything on it.
- List every name appearing more than once with different addresses, terms, or start dates.
- Check the reverse case: near-duplicate spellings of one name that should have been a single account.
What this does not catch
Raising duplicate labels finds collisions inside one file. It cannot tell you whether two spellings are one account or two, which is a fact about the business, and it does nothing where the source system has no stable identifier to give you in the first place.
Quick answers
- Why not merge accounts that share a name?
- Because a merge invents a history that never existed, and it does so without moving a total, so nothing downstream objects.
- What if the source genuinely has no identifier?
- Then the gap is stated on the page and a person rules on the duplicates, with the ruling recorded rather than buried in the code.
- Does a total check catch a wrong merge?
- No, merging two rows under one label leaves every sum exactly where it was.
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.