---
title: The Weekly Triage Pass
type: playbook
level: L1
status: live
revision: 1
updated: 2026-08-14
systemVersion: 4.2
tags: [governance, maintenance, playbook]
rating: 7.05
ratingAxes: useful 8 · evidence 6 · pull 6 · original 7 · form 9
ratingKind: derived
source: weekly triage, in production
---

# The Weekly Triage Pass

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

**TL;DR** — Any register an agent writes to will grow until it stops being read. A weekly pass with four verdicts — merge, keep, kill, promote — plus a hard cap that forces the pass when breached, keeps it usable. The rule that makes it survive: nothing is deleted without a reason and a pointer.

## Prerequisites

At least one register the agent appends to: patterns, findings, ideas, open questions. A cap on how many live entries it may hold.

If nothing appends automatically, this is premature — hand-written registers rarely reach the size where triage pays.

## Steps

**1. Set a hard cap first.** Ours is **30** live entries. The cap is not about storage; it is a **forcing function**. A register with no cap grows until reading it costs more than the value of any entry in it, and that point arrives without announcement.

**2. Run the pass on a fixed day.** Weekly, same slot, attached to something that already happens. A triage that has to be initiated will not be.

**3. Give every entry over 7 days one of 4 verdicts:**

> **merge** — duplicate of an existing entry, fold it in
> **keep** — still live, still relevant
> **kill** — no longer relevant, archive with a reason
> **promote** — act on it now; produces a task, not a note

**4. Cap promotions.** At most **3** per pass. An unlimited promote turns triage into a planning session, which is a different activity that will crowd it out entirely.

**5. Archive with a reason and a pointer.** Nothing is deleted outright:

> `killed 2026-07-27 — superseded by the build-level check; see [entry]`

The reason is what stops the same observation being re-added three months later by someone who cannot see why it was dropped.

**6. Add a tripwire.** A daily count of entries older than a threshold, with a flag if it exceeds a limit. Not new work — an alarm, so the cap is not the only thing standing between the register and neglect.

**7. Keep the archive searchable, not just present.** Killed entries go somewhere they can be found by the same search that covers live ones. The value of an archive is answering *did we already consider this* — and an archive nobody can search answers no better than deletion.

**8. Log the pass itself.** One line: date, entries reviewed, verdict counts. Two months of those lines show whether the register is stabilising or the cap is being defended by increasingly aggressive killing, which is a different and worse equilibrium than a register that has stopped growing.

## Verify

The register is healthy when the pass takes under 20 minutes and the count is stable rather than climbing. A pass that keeps taking longer means either the cap is too high or the entry gate is too loose.

Check the kill rate. **Zero kills over several passes means the pass is not doing its job** — a register where everything stays relevant is a register nobody is honest about.

## Troubleshooting

**The pass keeps getting skipped.** It has no executor. Attach it to an existing recurring task rather than relying on the day of the week.

**Everything gets kept.** Killing feels like losing information. The archive-with-reason step exists precisely to make it feel safe; if it is being skipped, the reluctance is rational.

**The register was falsely empty for weeks.** Check the tooling before congratulating anyone — a parser reading the wrong column produces a clean empty queue and no error at all. That specific failure ran 21 days here before anyone opened the file by hand.