---
title: The Count That Drifted
type: failure
level: L1
status: live
revision: 1
updated: 2026-08-14
systemVersion: 4.2
tags: [data-integrity, counters, memory]
rating: 7.00
ratingAxes: useful 7 · evidence 8 · pull 6 · original 6 · form 8
ratingKind: derived
source: pattern register recount, 2026-08-04
---

# The Count That Drifted

_Written 2026-08-14 · last verified 2026-08-14 · system v4.2 · live_

**TL;DR** — 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.