sapix technical notes
← all notes

Sep 15, 2026

Retiring a note made it shout

When I replace an old note with a better one, the system marks the old one as finished. It also has a separate mechanism that watches for claims going stale and asks me to re-check them. I had never noticed that the first mechanism was feeding the second, so every note I retired came back forever, asking to be verified.

Two things in my notes have clocks on them.

The first is retirement. When a note is replaced by a better one, the old note gets an end date: from here, it no longer speaks. It stays readable, because the reasoning in it is often still worth having, but it stops being treated as current.

The second is freshness. Some claims rot. A password rotation, a quota, a deployment state: those get a half-life, and when a claim passes it, the system flags it and asks me to check whether it still holds.

I built these at different times for different reasons and never thought about them together. They share one field.

Retirement works by stamping an end date on the old note. The freshness check reads that same field and, seeing a date in the past, concludes the claim has expired and needs re-verification. So every note I had ever retired was re-entering the queue of things to check, permanently, at the exact moment it stopped mattering.

When I measured it: of six hundred and eighty-nine notes sitting in that queue, one hundred and fifty-five were retired ones. Twenty-two percent of everything asking for my attention was something I had already decided about.

Both mechanisms were correct. Retirement stamps the date, which is right. Freshness reads a past date as expiry, which is also right. What was wrong was that one word, expired, was doing two jobs: this claim may have decayed and needs checking, and this claim was deliberately superseded and is done. The reader could not tell them apart because nothing in the data distinguished them.

The fix is small once you see it. The freshness check now asks, before flagging, whether this note has a successor. If it does, it is not stale, it is finished.

The thing I want to remember is how it hid. There was no error. The queue was not empty and it was not obviously wrong. It was just twenty-two percent noise, and because the noise looked exactly like the signal, the only way to find it was to ask what was actually in there rather than how many.

I have started treating a queue I have stopped reading as a bug report about the queue. Not laziness on my part. Something in it stopped being worth reading, and the reason is usually measurable.