Failure catalogue · The file lies · 14 of 51

OBSERVED FAILURE MODE

The substring that misfiles a customer.

Channel and category classification by name matching works until a name contains a word belonging to something else: a surname holding a retailer's name, a title holding a distributor's. The account lands in the wrong channel and stays there, quietly moving revenue between the segments a decision gets made on.

What we saw

At Meridian Journal Group accounts were classified into channels by matching text in the account name. It held until an individual subscriber's surname contained a retailer's name and the account was filed as trade rather than direct. Total revenue never moved, so no anchor objected. The channel split moved, and the split is the number the commercial team reads. The matching rule lived in code, so nobody outside the build could see which accounts it had classified or on what evidence, and no record existed of a person having agreed with any of it.

Why it passes a glance

Classification moves money between buckets without changing the total, so every reconciliation stays green. The page shows a channel split that adds to the right grand total. A glance cannot audit a rule it cannot see, and a rule buried in code is invisible to everyone who is not reading the build. A misfiled account looks exactly like a correctly filed one.

What addresses it

Doctrine principle 7, clean by relabelling, never by revaluing, permits classification precisely because it changes what a row is called rather than what it says, and holds it to that boundary: the anchor must still tie afterwards. The trust-the-upload skill supplies the mechanism, an override table held as reviewable configuration rather than a heuristic in code, with the ambiguous case put to a person and the human verdict recorded beside the row.

Check your own file in two minutes

1. Export the classification your build produced as a list of names against assigned categories, and read it.
2. Search that list for matches driven by a substring rather than by a whole name.
3. Check that the category totals still add to the same grand total as before classification; if they do not, something was revalued rather than relabelled.
4. Move every exception into a named override table with a person's verdict recorded against it.

What this does not catch

An override table makes classification reviewable, not correct. It cannot tell you an account has sat in the wrong channel since before the file existed, and a rule that misfiles a category nobody reads stays wrong until somebody reads the list.

Quick answers

Is classifying a row allowed at all?

Yes, classification changes what a row is called, which is relabelling, and the test is that the anchor still ties afterwards.

Why does a misfiled account pass every check?

Because moving a row between categories leaves the grand total untouched, and the grand total is what reconciliation checks.

Where should the exceptions live?

In a reviewable override table held as configuration, with the person who decided each one recorded beside it.

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.