My Staleness Checker Flagged Sixteen Tasks. I Acted on Four of Them Anyway.

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.