The Count That Drifted
A register capped at thirty said eighteen. It held twenty-four. The cap was never breached and nobody could have known.
A register with a hard cap of 30 entries reported 18 in its header while holding 24. Entries had been added without updating the count, for weeks. The cap was not breached, but nobody could have known that — the number everyone read was maintained by hand and had stopped tracking reality.
Symptom
A register with a hard cap of 30 entries showed 18/30 in its header. A recount found 24.
The cap had not been breached. But every decision about whether to add an entry had been made against a number that was wrong by 6, and there was no way to know which side of the line the register was actually on.
Root cause
The header was maintained by hand and updated whenever someone remembered. Entries were added by several different processes, none of which touched it.
Drift was therefore guaranteed and gradual — one entry at a time, never large enough to notice, until the accumulated gap was a third of the stated total.
There is a second, quieter contributor. The cap existed to force a triage pass when the register got full. A header that under-reports postpones the forcing function, so the mechanism designed to keep the register healthy was silently disabled by the same drift.
Cost
Low in itself. Notable for what it revealed: the same class of drift was found in two other registers in the same audit, one of them claiming 25 entries against 12 present.
Three independent counters, all hand-maintained, all wrong in the same direction — under-reporting, because adding is common and remembering to increment is not.
Fix
The recount was done with a mechanical count rather than by reading, and the method was written into the file beside the number:
26/30 (recounted 2026-08-04 by awk between § Records and § Archive)
That annotation does two things. It states how the number was obtained, so the next reader knows whether to trust it. And it dates it, so staleness is visible instead of invisible.
Prevention
Derive counts, or timestamp them. A number that cannot be derived at read time is an observation about a moment, and it should be labelled as one.
Never reconcile downward without evidence. Where a count is too high rather than too low, the tempting fix is to edit it to match — which silently asserts the missing entries never existed. If they did and were lost, that edit destroys the only remaining trace. Record both numbers and the fact that they cannot be reconciled.
Check whether a stale counter has disabled something. A cap, a threshold, an alarm — anything that reads the number is affected, and the failure is not the wrong number, it is the mechanism that quietly stopped firing.