On 20 July I served myself two dead tasks as if they were live. One told me to chase a contact at a
deal that had closed months earlier. The other told me to stay quiet and wait for a call that had
already happened, and gone nowhere. Both came out of the same file: a running list of open threads
that my operations run against.
So that afternoon I wrote a checker. Every open line in that file has to carry a tag naming the
project note it comes from and the date it was last reconciled. The script compares that date
against the modification time of the note itself. If the note changed after the line was last
checked, the line is stale: the decision moved on and the reminder did not. It also catches lines
with no tag at all, and lines pointing at a note that no longer exists.
It works. I ran it this morning. Fifty-eight open lines, sixteen flagged.
Then I acted on one of the flagged lines anyway. And then three more.
The check was never the problem
Read the script and there is nothing to fix. It parses correctly. It classifies into three states
that are genuinely different from each other. It prints the offending line with its note and both
dates, so you can see exactly why it fired.
It even exits with status 1 when anything is unreconciled, and 0 when the file is clean. That is the
oldest convention in computing for "do not proceed."
Nothing reads that exit code.
I went looking today. Nothing calls the script. No scheduled job, no wrapper, no step that runs it
and stops if it fails. The only two places on the machine that mention it at all are the script
itself and a paragraph inside the very file it polices, which says that it must be run first and
that flagged lines must not be surfaced as actions.
So the enforcement mechanism was a sentence, sitting next to the thing it governed, asking whoever
came past to behave.
What that cost, in one morning
I run my operations through an AI agent with a persistent memory of the business. It read that
paragraph. It ran the checker. It received sixteen flags. It then surfaced four of them to me as
work to do.
The first was a supplier setting I had changed the previous evening and confirmed on screen.
The second was an account item that had been closed four days earlier, where the correct standing
instruction in my own notes was to wait, and where a note explicitly recorded that chasing had
already been stopped once for exactly this reason.
The third was a message to my accountant that I had already sent twice, on two separate days, and
had explicitly closed with "nothing urgent, we'll sort it when you're back."
The fourth is the one that matters. It was a drafted email to a government directorate, ready to
send, telling them I could not find a document on their site. Five days earlier I had written to the
same people saying I had downloaded that document and read it in full. Both of my follow-up
questions had been answered the same day.
I caught all four. Not because the checker stopped anything, but because I happened to remember. The
fourth one I caught with the draft already written and one click from going out.
The shape of this failure
I published something last week about a counter in a different system that merged two opposite facts
into one comforting number. This is the same bug wearing different clothes.
There, a metric reassured me while a feature was dead. Here, a checker produced a correct verdict and
nothing was obliged to consume it. In both cases the machinery was right and the wiring was absent.
In both cases the output felt like protection, and protection is exactly what it was not.
A check that reports is documentation. A check that blocks is a control. I had built the first and
believed I had built the second, and the belief is the expensive part, because it stops you looking
for the real one.
The fix is not a better checker
There is nothing to improve in the script. The three things worth doing are all about who is forced
to listen.
Make the flagged lines unreadable rather than merely labelled. If a line cannot be reconciled, the
process that reads the file should not receive it at all. Filtering at the source beats a warning at
the destination, because a warning depends on the reader's discipline and a filter does not.
Give the exit code a consumer. A non-zero status that nothing checks is a refusal shouted into an
empty room. Either something branches on it or it should not be there, because its presence implies
a contract that does not exist.
And stop writing enforcement as prose. The instruction "run this first and do not surface flagged
lines" was in the right place, correctly worded, and read by the thing it was aimed at. It still did
not hold. Rules that live next to the work are advice. Rules that gate the work are rules.
What I would take from this
If you have a linter nothing fails on, an alert nobody is paged for, a policy document, or a review
step that can be skipped when the day is busy, you have what I had. It will pass every test you give
it, because it does its job perfectly. Its job simply is not the job you think you assigned.
The question worth asking about any safeguard is not whether it detects the thing. Mine detected it,
sixteen times, in clear language, on the correct morning. The question is what physically cannot
happen while it is unhappy.
If the answer is nothing, you do not have a safeguard. You have a very reliable narrator.
Originally published on devaland.com: My Staleness Checker Flagged Sixteen Tasks. I Acted on Four of Them Anyway.
Top comments (0)