Written by JD Davenport, who still sells for a living. Updated 4 November 2026.
A broken instrument does not return an error. It returns a confident answer, in the right format, at the usual time, and you act on it.
That is what makes instrument failure different from every other kind. A crashed report tells you it crashed. A corrupted one tells you nothing at all, and keeps telling you nothing for as long as you keep running it.
Somebody opened a packaged set of audit instructions to check a reference case, and found that every dollar figure in it had been replaced by a meaningless slug.
The file on disk was perfect. The figures were being rewritten in the half second between the file being loaded and the instructions being read, and they had been doing it for as long as anyone had been running that playbook.
The cause was mundane. Arguments passed to a packaged instruction file are exposed to its body as positional variables, written as a dollar sign followed by a digit. Money written that way is indistinguishable from a variable reference, so the command layer substituted the arguments into the text at load time, silently, because from where it stood nothing had gone wrong.
The matching rule was greedy on digits. A four figure sum written with a comma matched. A two digit sum did not. One sum with cents survived a particular run only because eight arguments had been passed and the indices stopped at seven.
So which figures broke depended on how many arguments were passed that day. The same file invoked with three arguments corrupts a different subset.
There was no stable failure to learn. Nobody was ever going to catch this by noticing a pattern, because there was no pattern to notice. Every run was wrong in a different place.
Three of the corrupted values were not money. They were spreadsheet cell references inside formula guidance, where the reference is the thing being taught.
A slug where a dollar figure belongs is visibly absurd, and somebody catches it. A mangled cell reference is quietly plausible. Those three lines existed to prevent one specific formula error, and corrupted, the guidance had become a tutorial in the mistake.
The rule that falls out of that: the dangerous corruption is the one that still looks reasonable.
By holding both copies at once. The instruction text as it arrived in working memory, compared directly against the same file read from disk in the same session.
Neither half alone shows anything. The disk copy is clean. The loaded copy is corrupt. You only see it by comparing them, and nobody compares them unless they already suspect something.
"Stop passing arguments to that tool" is not a fix. It requires somebody to remember, every time, forever. A fix that depends on memory is not finished.
What was done instead: rewrite the text so the route does not exist, by writing money in a format where a dollar sign is never followed by a single digit and a separator. Then add a check that runs before the file saves and must return zero rows.
The rule says how to write it. The check proves it before the file saves. Nobody has to remember either one.
When a result looks wrong, the first hypothesis is not that the business is wrong. It is that the thing you measured with is wrong.
Critique your own instrument before you defend it. Ask whether the measurement is the problem, not just the result. A single threshold applied across every job size is usually the wrong instrument, and the answer is to band it by size rather than to argue about the number it produced.
Deciding [which of your jobs actually made money](/faq/which-jobs-made-money/) depends entirely on the instrument being sound, which is why this check comes first.
Adapted from The Audit, "The Thermometer Is The Thing That Is Broken". More in the books. Other notes on the notes page.