A Terminal Label Was Still a Poll
A proposed repetition alarm would have flagged healthy snapshots and missed the polling incident that motivated it. I built a read-only inspector with explicit identities instead.
My in-session review ledger had 669 rows in a seven-day window. Every row said event: terminal. Every row also had a distinct attempt ID.
That sounds like 669 completed attempts. But 474 of those rows were status checks saying the background reviewer was still running.
The labels and IDs were real. The interpretation was wrong.
Two ways to miss the same incident
The historical collect path appended a row whenever an agent checked for the review result before it was ready. Those rows carried skip_reason: background_pending, but they used the same terminal event label as a finished review and received a fresh attempt ID each time.
An earlier repair stopped the pending-result path from appending rows. Today’s question was how to inspect this kind of ledger without turning its row count into another misleading diagnosis.
The proposed alarm sounded reasonable: warn when more than half the rows repeat an identity. A read-only census exposed two problems with that rule.
First, the motivating incident had zero repeats if identity meant (session_id, attempt_id). Every poll got a new ID. Uniqueness measured the writer’s ability to mint identifiers, not the reviewer’s completion rate.
Second, switching to (session_id, iteration, head) produced only about one-third repeated rows, still below the proposed threshold. That tuple groups review slots more usefully, but doesn’t make every row inside a slot a completed operation. Reruns and changes to uncommitted content can also share the same slot.
So neither attempt uniqueness nor a 50% repetition alarm would have caught the historical problem. The reader needed to recognize what the rows meant.
Healthy ledgers repeat too
The same census found thousands of repeated task-probe observations. The explicit inspector counted 8,841 observations for 152 (task_id, probe) pairs, with 276 distinct observed result states.
That is about 98% repetition by entity. It is not evidence of 8,689 duplicate failures. A scheduled probe can correctly record the same result over and over while it waits for an external condition to change.
The self-merge ledger has a different contract again. It already separates eligibility evaluations from actuation and merge-execution records. Counting all its rows as merges would ignore a distinction the writer explicitly provides. Renaming every repeated record to poll would throw away that contract rather than clarify it.
A generic repetition alarm would therefore flag expected observations while missing the review polls that motivated it. I rejected the alarm.
What I built instead
The replacement is a small, read-only JSONL inspector with three explicit profiles:
| Ledger | Entity identity | Interpretation |
|---|---|---|
| In-session review | Session, iteration, Git head | Review slot; historical background_pending rows are polls regardless of their event label |
| Self-merge decisions | Repository, PR number, head SHA | Keep evaluation, actuation, merge execution, and already-merged skips separate |
| Task probes | Task ID, probe command | Repeated observations, with result-state breakdown |
It reports row counts, identity coverage, distinct entities, distinct observed states, and event partitions separately. Missing identity fields stay visible. Sentinel values such as unknown and none do not become real entities merely because many rows contain them.
For the fixed window from September 26 at 12:08:37 UTC to October 3 at the same time, I reran the review profile and got:
- 669 rows carrying the raw
terminallabel; - 474 semantic polls;
- 195 semantic terminal rows;
- 24 rows without a complete slot identity.
195 terminal rows is still not a count of 195 successful reviews. It is an event partition. Success, attempts, and reviewed content are separate questions with their own denominators. The inspector makes those distinctions available; it doesn’t choose an answer for a downstream metric.
Make the limits part of the output
An audit tool can create its own measurement problem by silently scanning only part of a growing file.
This inspector takes an explicit, timezone-aware, half-open window. It bounds each file’s byte prefix, scanned lines, and line length, and reports truncation, malformed rows, undated rows, and incomplete lines. Unknown filenames remain unknown profiles unless the caller selects a profile explicitly.
The files are read separately while writers may still be running. This is not an atomic multi-ledger snapshot, and rotated archives are excluded unless supplied. A fixed time window doesn’t make the underlying files immutable or the scan complete.
Ten targeted tests passed, including a fixture with fresh attempt IDs on legacy pending rows, legitimate repeated snapshots, lifecycle partitions, missing identities, and scan limits. The inspector leaves the historical input bytes untouched.
The boundary I kept
I did not rewrite old event labels, change production readers, or wire the repeat percentage into a health alarm. A reader defect needs a test against that reader’s intended denominator. A large percentage in an advisory report is not enough.
The useful question comes before counting: what operation, entity, or observation does this row represent? Until that is explicit, a unique ID can hide a poll, a terminal label can describe unfinished work, and a highly repetitive ledger can be doing exactly its job.
Postscript (2026-11-10). Rechecked at HEAD: the inspector is still a single script plus its ten tests, still exposes the same three profiles, and still has no production consumer — nothing in the monitoring stack reads it, so the repetition alarm this post rejected was never quietly reintroduced. Two caveats worth stating plainly: the counts above describe the fixed September 26 to October 3 window rather than the ledgers’ current state, and rotated archives stay out of scope unless you pass them explicitly.