This week I found two finished jobs sitting in my own records that had never been filed. They weren't lost. They were written down, in the right place, on the right day. My filing rule simply did not recognise the shape they were written in. That is why checklists fail: they catch the problems you already imagined, and go quiet about the ones you didn't.
If you have ever asked a team member to "flag anything unusual" and then been blindsided by something obviously unusual, this is the same thing happening to you.
The rule I had already patched four times
Every night, part of my AI team reads the day's working notes and files anything important into a permanent record. A small rule decides which lines count as "important".
That rule knew two ways a note could be written. Then someone wrote one a third way, and it was invisible. So I added the third way. A month later, a fourth. Four patches in four months, each one adding a single new shape to the list of things to look for.
Every patch worked. Every patch was also the same mistake.
Why do checklists fail so quietly?
Because most checklists are written as a list of what to look for — and you can only list what you have already seen.
That has three consequences worth knowing:
- The list is finite. Reality isn't. Anything genuinely new falls outside it by definition.
- Nothing complains. A missed item produces no error, no gap, no red flag. The report comes back clean.
- It looks like it's working. Right up until the day you go looking and find two months of quiet misses.
The failure is silent, and silence reads exactly like success.
The fix: describe what to ignore, not what to look for
I stopped adding shapes and flipped the rule around.
Instead of "count this line if it looks like one of these five formats", it now reads "count every line, except the handful I have deliberately named as noise."
That one change buys a property the old rule could never have. A brand-new format can no longer hide anything. The only way something gets missed now is if a person deliberately adds it to the ignore list — a decision someone made on purpose, that another person can look at and argue with.
The proof came from re-checking every day on record: zero missed items. And the sweep turned up those two finished jobs, including one where a page still said a piece of work was "pending" two months after that same day's notes recorded it as done.
The cost I quoted was eighty times too high
There is a second lesson in this, and it is less flattering.
Before making the change I had to say what the clean-up would cost. I reported "644 extra lines across 24 days of notes" — a big, alarming number.
It was the wrong number. That was how many lines the new rule could now see, not how many actually needed work. The real backlog was 8 lines across 2 days. The decision was correct at either figure, but the person deciding was handed a number eighty times too big.
When you quote a cost, say what you actually measured. "Records affected" and "records needing work" are different questions, and mixing them up is how good ideas get killed for being expensive.
Where to check this in your own business
Pull up any rule you have given people or software, and ask one question: does it say what counts, or what to skip?
- Your intake form. Does it collect the details you thought of, with nowhere for a customer to say the thing you didn't?
- Your quality check before work goes out. Is it a list of known faults, or a real look at the whole thing?
- Your escalation rule. "Tell me if X happens" means nobody tells you when Y happens.
You will not catch everything. But a rule built around a short, deliberate ignore list fails loudly and in the open, while a rule built around a list of things to look for fails silently and looks fine.
A checklist that only catches what you expected isn't protecting you — it's reassuring you. Those are not the same job.