---
title: Build A Repeat-Mistake Counter
type: playbook
level: L1
status: live
revision: 1
updated: 2026-08-14
systemVersion: 4.2
tags: [governance, quality, playbook]
rating: 7.95
ratingAxes: useful 9 · evidence 7 · pull 7 · original 8 · form 9
ratingKind: derived
source: in production since 2026-05-04
---

# Build A Repeat-Mistake Counter

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

**TL;DR** — Notes about an agent's mistakes are nearly useless without a count, because the fifth repeat looks exactly like the first. This is the ledger format, the 4-step escalation ladder, and the habit that keeps it alive: log the count in the same action as the correction, never later.

## Prerequisites

A place to write files the agent can read and edit. A person who corrects the agent often enough that repetition is possible. Nothing else — no database, no tooling.

If corrections are rare, skip this: a counter with 3 entries is overhead.

## Steps

**1. Create the ledger as one table.** One row per distinct mistake, not per occurrence. Columns: identifier, short description, category, count, last occurrence, state, fix or escalation.

The description carries the *class* of error, not the incident. `Concluded absence from a single spelling of a proper name` is reusable. `Did not find the supplier` is not.

**2. Fix the escalation ladder before the first entry.** Deciding thresholds while looking at a specific mistake guarantees the threshold gets set to whatever excuses that mistake.

| Count | State | Action |
|---|---|---|
| 1 | log | entry written, nothing else |
| 2 | warning | propose a dedicated rule |
| 3 | systemic | write the rule, assign an enforcement level |
| 5 | critical | hard failure in review |

**3. Make logging atomic with the correction.** This is the step everything depends on. When a correction happens, the counter entry is written in the *same* action — not at the end of the session, not in a review pass.

Deferred logging fails for a structural reason: the moment you notice a mistake is the only moment you have full context on it, and it is also the moment you most want to move on.

**4. Assign an enforcement level at the third occurrence.** Writing a rule is not the fix. Text does not stop repetition on its own. At count 3, name *how* the rule is enforced:

> L0 prompt text · L1 checklist in a skill · L2 build or hook check · L3 hard gate that fails

**5. Link related classes.** When a new entry resembles an existing one, say so in the row. Two mistakes that share a root cause should escalate together, and the resemblance is only visible while both are fresh.

**6. Review on a fixed rhythm, not on impulse.** Once a week, read only the rows whose count rose. That is a two-minute pass and it is the only moment the ladder actually gets applied — an escalation threshold that nobody evaluates is a number in a table.

The review also catches the opposite error. A row at count 4 whose last occurrence was three months ago is not an active problem; it is history, and leaving it in the live table inflates the sense of how much is broken. Archive it with its final count intact.

## Verify

The counter works when you can answer, without reading the whole file: *what is the most frequent class of mistake this month, and what enforcement level does it have?*

Two health checks worth running monthly. **Entries with count 1 and no recent date** are probably one-offs — either merge them into a class or archive them. **Entries at count 3 or more with enforcement level L0** are the real finding: a rule was written, nothing enforces it, and the count is still rising.

## Troubleshooting

**The ledger stops being written.** The usual cause is that logging was separated from correcting. Re-couple them; a counter maintained in a weekly pass will be abandoned within a month.

**Every entry is unique, nothing ever reaches 2.** Descriptions are too specific. Rewrite them one level up — from the incident to the class.

**The count rises and nothing changes.** The ladder exists but has no executor. Escalation at count 3 has to be triggered by something other than goodwill, or the ledger becomes a diary of failures nobody acts on.