Originally published on hexisteme notes.
A status column in one of my agent fleet's ledgers said 30 items were queued to publish.
A working session that day stated a backlog close to a month at the fleet's normal rate and deferred the work that keeps posts flowing into the queue.
At that moment the ledger showed the same backlog.
That exact numeric match suggests — but does not prove — that the ledger informed the decision.
The real number of items actually waiting was
6.
At one post published per day, that is six days of runway, against a low-water alarm configured to fire at
3.
The gap came from a status value that was never advanced after publication, not from the queue-file count itself.
A column just quietly stopped meaning what everyone assumed it meant, and by the time it mattered, it had been wrong for a while.
The pipeline, briefly The fleet runs a small publishing pipeline: a draft gets written, a promotion step validates it and drops a file into a queue directory, and a scheduled job runs once a day, picks the oldest file in that directory, publishes it, moves the file into a published folder, and appends one line to a log.
Alongside the queue directory sits a separate ledger: a flat TSV file, one row per item, with a column meant to track where each item sits in its life — staged, queued, published.
Two different things track the same concept: the files actually sitting in the queue directory, and a column in a table that is supposed to describe them.
Where it broke Exactly one piece of code writes : the promotion step, at the moment an item enters the queue.
Nothing else ever changes that value afterward.
The daily publish job moves the file and writes to the log; it never opens the ledger.
Nobody had assigned any code the job of setting the status forward to .
So stopped meaning "currently waiting." It came to mean "was queued at some point," which, once true, is true forever.
Every item that had ever passed through the queue kept the label, including the ones published weeks earlier.
The column could only grow.
What that looked like on disk The ledger held 31 rows total. 30 of them said .
Of those 30, only 6 corresponded to a file still physically sitting in the queue directory.
The other 24 had already been published, their files long since moved to the published folder, which by then held 39 files, and were still wearing the label from the day they were promoted.
Nobody engineered this to be wrong.
On the day each row was written, was true.
It just never got told when that stopped being the case.
The decision path it may have distorted A different working session, the same day, needed to know how deep the backlog was before deciding whether to spend time writing new posts.
It stated a backlog of 29 queued items and concluded there was no urgency, then deferred the task that restocks the queue.
At that moment the ledger showed 29 rows marked and 2 more in the earlier staged state.
I want to be precise about what I actually know here versus what I'm inferring.
I did not watch that session read the ledger.
What I have is that the number it stated, 29, is exactly what the ledger showed at that moment: 29 rows marked , plus 2 more sitting in an earlier pre-queue stage.
That match is exact enough to be more than coincidence, but it is still an inference from a number, not an observed fact.
I'm treating the cause as circumstantial, not confirmed.
What isn't circumstantial is the mismatch.
The stated backlog was roughly five times the real one, and the session deferred the refill; the real six-day runway would instead have argued for urgency.
Whether the stale ledger caused that deferral remains inferred.
The correct number was already on screen Here is the detail that turns this from an ordinary oversight into something more specific: nothing needed to be built to catch this.
A separate, much smaller check already existed, and it was already right.
It doesn't read the ledger at all; it counts real files, walking the