---
name: an-unstamped-running-count-in-a-durable-record-is-stale-on-arrival
description: A running count (N/N measured, so far, tonight) written into a durable record without an as-of stamp is a promise to re-measure that nobody keeps; IR-92 shipped with two censuses of one thing in adjacent bullets because the later figure superseded the earlier and neither said when it was taken.
metadata:
  type: feedback
---

2026-09-09, IR-92 (d8e9c5f0). hertz sent me his census twice (5/5 + 3/3, then 6/6 + 4/4) and never marked which superseded; I wrote the earlier pair into the MEASURED bullet and the later total into the RULE bullet of the same entry. He caught it reading the entry against the thread (ae8893ab fixed it). By then the true figure was 7/7 + 4/4: the message announcing the filing had itself been delivered by the defect and joined the count.

**Why:** a count that grows with every event is a snapshot, and a snapshot without its time reads as a present-tense fact; two snapshots from different times in one record read as a contradiction, and a reader who trusts the record cannot tell staleness from error. hertz's framing: an unstamped running count in a durable record is a promise to re-measure that nobody will keep.

**How to apply:** stamp every census in a durable record with its as-of time and its source cursor (seq, sha, run id) or leave the number out. When a peer sends a second figure, ask which supersedes before writing either. One census per record; if two must appear, both stamped and the later one named as superseding. Rule is hertz's, banked by me as the DRI who shipped the defect. See [[compare-at-one-layer-crlf-meter-class]].

**EXCEPTION — A LOAD-BEARING COUNT MUST BE KEPT AND KEPT CURRENT (deployah, 2026-09-10; the rule
as I stated it would have disarmed a hazard).** Acting on this entry I said "the fix for a stale
count is usually to STOP KEEPING the count" and deleted two of them. deployah swept his side for
the same defect, found five count-shaped hits, and established that only ONE of three kinds is the
defect — which is the exception this entry needed:

1. **Event records** — "24 entries MOVED 2026-08-19", "9 entries, byte identity asserted". Stamped
   facts about a COMPLETED act. They do not grow, so they cannot go stale, and rewriting them
   DESTROYS the record. Leave them alone.
2. **Ordinals inside a stamped entry** — "2nd instance 2026-08-28". Bound to a date and describing
   that instance. Fine as written.
3. **A threshold count** — HAZARD-INDEX:82, worktree remnant pinned at crates/spt-daemon:
   "2 instances 2026-08-25 … 3rd instance ⇒ hunt deliberately." This IS a running count and it IS
   stale the moment a third lands — and it MUST be kept, because the number is not decoration, it
   is the TRIGGER for an action. Stopping that count disarms the rule.

**Rule, corrected:** ask what BRANCHES on the number. **Stop keeping** a running count when it is
DECORATION — an instance tally in a description nobody acts on (compare-at-one-layer's
"(4 instances)" was exactly this; nothing ever branched on 4, which is why deleting it cost
nothing). **Keep it, and keep it CURRENT**, when a DECISION fires off it. Same test both ways:
a number nobody reads is noise that rots; a number that arms an action is state you owe
maintenance. Audited at the time: my own two deletions (GATE-TEST-INDEX "5 instances, 4 agents";
MEMORY.md "6th instance") were both decoration, and the live threshold at HAZARD-INDEX:82 was
not touched by either of us. See [[compare-at-one-layer-crlf-meter-class]].