---
title: The Header That Counts Itself
type: anti-pattern
level: L2
status: live
revision: 1
updated: 2026-08-14
systemVersion: 4.2
tags: [memory, data-integrity, counters]
rating: 6.85
ratingAxes: useful 7 · evidence 7 · pull 6 · original 6 · form 9
ratingKind: derived
source: controlling ledger reconciliation, 2026-07-31
---

# The Header That Counts Itself

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

**TL;DR** — A ledger header claimed 25 findings while the body held 12. The header was maintained by hand and drifted every time an entry was merged or removed. A count that lives beside the thing it counts, instead of being derived from it, is guaranteed to go stale.

## Pattern

A long-lived file opens with a summary block: *total entries: 25*. The body contains twelve. Nobody wrote a wrong number — the header was correct when written, and then entries were merged, renumbered and archived without anyone touching it.

## Why it looks right

The header is genuinely useful. It saves a reader from counting, it gives a sense of scale, and it makes the file feel maintained.

It is also the first thing any reader trusts, which is exactly why the drift is expensive rather than cosmetic.

## Why it fails

A hand-maintained count is a second source of truth for something the file already contains. Two sources of truth for one fact will diverge; the only question is how long it takes and whether anyone notices in between.

The damage is not the wrong number. It is what the wrong number invites: someone eventually reconciles it by **editing the header down to match**, which silently asserts that thirteen entries never existed. If they did exist and were lost, that edit destroys the only remaining evidence of the loss.

## Instead

Derive the count, or mark it as an observation with a date:

> `entries: 12` *(recounted 2026-07-31 by grep; header previously claimed 25, difference unexplained)*

When you find a mismatch you cannot explain, **do not quietly correct it downward**. Record both numbers and the fact that you cannot reconcile them. A visible unexplained gap is a finding; a tidied header is a deleted one.

The same rule applies to any self-reported total: item counts, version numbers, "last reviewed" dates. If a human hand can update it independently of the thing it describes, it will eventually describe something else.