When the Notes Say Done and It Is Not

What was broken

I run my work on a large set of notes and small automated jobs. By August 2026 I had a feeling some of the notes were lying to me. Not on purpose. They were true when written, and nobody updated them when things moved on.

So I measured it. I ran a read-only scan over 813 note files, in two passes. It found 6,826 lines that stated a status, grouped them into 754 items, and checked which ones disagreed. 9 real contradictions survived. It also found 3,358 lines with dates. 477 were past due. After checking each one for a later fix, 20 promises were still open and late.

The surprise was the kind of fault. Nothing was lost. Nothing was hard to find. The files were well linked and wrong.

Some examples. Four fixes had been applied but still sat in the waiting folder. The notes around them said "not applied" for 52 to 72 days. My own dashboard said one helper was switched off for 74 days, while a card at the top of the same page said none were off. One job had run every week since early June, while its own instruction file said in capitals that it was not switched on. A future session reading that line could have stopped a working job.

The checks I already had caught none of it. One file-health job reported zero problems on 8 runs in a row. It was not broken. It just asked a question nobody needed answered. A weekly link report arrived every Sunday and had been acted on zero times in ten weeks. Four of its logs were byte for byte the same. And one date check had never fired in its whole life. It crashed on every date it found, and the crash was hidden.

What I built

I built a nightly drift watch. Its job is narrow. Find two files that disagree, or a promise that lapsed, and put each one in a queue.

It may fix things on its own only where there is one correct answer and an easy undo. I allowed four such cases, like a fix that is applied but still listed as waiting. Everything else it proposes to me, a few at a time, with its own recommendation.

If I ignore an item three nights running, it parks it and brings it back a month later. The queue started at 46 active items.

The first armed run failed. I had set it to run in a place that could not reach my files. It would have failed quietly every night. I moved it to my own machine, and the fifth run worked end to end.

I also fixed the date check that never fired. Its first working run raised 25 flags. One was a review I had set for myself that was already overdue.

What changed

By the eighth run, three days after arming, open items were down from 46 to 20. That number needs honesty. 6 of the drop were items parked after three nights with no decision from me. Parking is not solving.

The best speed-up was in how I decided. One night I was tired and had 11 open calls. I got them as one table: item, question, recommendation, one line of why. I replied "all yes except one". 10 of 11 were cleared in one message.

Checking also caught the checker. Of 20 broken-link flags, 12 were never real. In 8 of them, a note said "move this file here later". The tool read that future address as a broken link. An automatic fix would have rewritten those notes to say "move this file to itself".

And I got one badly wrong. The watch told me a weekly client update had never been sent, because the drafts were still sitting there. It had been sent every week, from my other mailbox, which no tool could see. The real finding was the blind spot. Nothing could confirm a send. Only that a draft existed.

What I would do differently

I would test every check once on something I know is broken. A check that has said zero for its whole life is a suspect, not a clean bill of health.

I would close the status in the same sitting as the work. Apply the fix, then update the note that says it is pending.

I would treat a missing record in the one place a tool can see as a lead, never a finding.

And I would not let a falling count fool me. I would ask how many items were decided and how many just timed out.