Prove the alarm by setting it off
We wrote a check to catch a specific mistake, then made that exact mistake on purpose. The check stayed green. An untested safeguard is not a safeguard — it is a note saying one exists.
You know not to trust a smoke alarm you have never pressed the button on. Nobody extends the same suspicion to a checklist, a report or a till procedure, and they should, because the failure is identical: the thing exists, everybody believes it is working, and nothing has ever asked it to say no.
We got a clean demonstration of this last week, at our own expense.
The check that could not fail
We had found a class of mistake worth guarding against — an update that changes a record without confirming the record belongs where the request says it does. We wrote an automated check for it across every place that shape appears. It passed. Good.
Then, because the rule here is to never trust a check you have not seen refuse, we made the mistake on purpose: took one of those updates and removed the part that confirms ownership. Exactly the bug, in a real file, deliberately reintroduced.
The check stayed green.
The reason is almost funny. Our check asked whether the relevant field was mentioned anywhere in that piece of code. It was — a few lines below, the same code writes an audit entry, and the field's name appears in it. So the check was matching a log line and reporting it as a safety measure. It would have passed forever, through every future version of that bug, while looking in every report like protection.
What was actually wrong with it
Not the idea. The precision. "Is this word present" is a different question from "is this word doing the job". We rewrote it to require the field to be genuinely bound in the instruction — not merely nearby — and then ran the deliberate break again. This time it failed, and named the exact route.
We have made close relatives of this mistake before: a check that counted two things and compared the totals, which passed after a guard was deleted because the count also matched the guard's own definition. The pattern is always the same. The check measures something adjacent to the thing it cares about, and adjacent is fine right up until it is not.
The same trap, in a venue
This is not a software problem. It is a verification problem, and your building is full of them.
Allergen sign-off. Does the form refuse to save when a required field is blank, or does it just have a box for it? Try saving it empty. If it saves, the form is a record of intent, not a control.
Cash variance. Does your cash-up flag a short drawer, or does it only show you the number and leave the noticing to a tired human at midnight? Put a deliberate tenner out and see whether anything says so.
Temperature logs. A fridge log with no gaps either means nothing was ever missed, or means the gaps get filled in on Friday. Those look the same on paper and are not the same thing at all.
Stock counts. Count one line wrong on purpose and see whether the variance report surfaces it, or whether it disappears into a total nobody drills into.
The habit
For anything you rely on to catch a problem, create the problem once, on purpose, in a controlled way, and confirm the thing complains. Then put it back. It takes minutes, it is the only evidence that actually means anything, and it is the difference between having a control and having a note saying you have one.
A check nobody has seen fail is a rumour.