Registers: durable memory for unreliable narrators

Agent sessions end. Whatever a session learned — the assumption that turned out false, the plan a new fact just invalidated — dies with its context window unless it lands somewhere durable. So you make the agents write it down, and you inherit a harder problem: memory an agent wrote is memory an agent can falsify. A wiki edits silently and rots. A chat log remembers but cannot act. A fleet needs memory that outlives every session, that can reach into the work schedule, and that stays honest when its own writers may be wrong — or adversarial.

The registers are that memory: append-only logs, one markdown file per entry, retractions recorded as tombstones instead of performed as deletions, and a metering rule at the core. The rule is the whole design in one sentence: anyone may append, nothing may erase, and what an entry can force scales with the verification standing behind it. Our own findings register currently holds 23 entries, 15 of them unresolved — each one a standing alarm the schedule has to answer before the work it names can run again. The flagship introduction gave the registers one section; this is the deep version — the shape, the teeth, the gate on the teeth, and the hole the design missed.

one entry, one file, and nothing comes back out

Two registers sit in the tracking tree as plain directories: findings/ holds knowledge that invalidates existing plans, intake/ is the front door for raw ideas. An entry is a single markdown file with YAML frontmatter. Here is a real finding from our tree, lightly scrubbed for publication:

---
          id: F-alert-path-dead
          date: "2026-08-11"
          title: "The post-merge leak alerter cannot run — a red gate on main is invisible"
          affects: ["release-hardening/manifest"]
          ack: ""
          resolved: false
          ---
          The step whose whole job is to shout "a withheld token reached main" dies
          before it can escalate: it calls a CLI its runner does not ship, so it exits
          127 on the failure path — the only path it exists for. A red gate with a dead
          alerter is indistinguishable from a green one to anyone not watching raw logs…

Body prose carries what was found, the evidence, and the fix direction. References are typed IDs — release-hardening/manifest names a brief, the unit of work, and F-<slug> names a finding — never prose names, because a linter cannot follow prose.

Two structural decisions do most of the work. One file per entry means parallel authors never contend for the same lines of the same file — a fleet files findings concurrently, and a shared log with a counter would serialize them through merge conflicts. Append-only means an entry, once landed, is never edited away: the registers are the audit trail, and in the design document's own words, a silent edit "erases the record of why a decision was made." The familiar FINDINGS.md and INTAKE.md files still exist, but as generated views with a single writer — the trunk branch's CI, the same discipline as the status board — so a hand-edit lasts exactly one regeneration.

a finding pulls work off the schedule

A register that only remembered would be a diary. Findings act. When one lands, the validator flags every brief in its affects: list as stale-knowledge and excludes it from Next-up — the compiled work queue — until the finding resolves. No coordinator has to notice the entry, agree with it, or route it: the exclusion is derived, on every run, from the file being present and resolved: being false.

Resolution runs in the same direction. You do not close a finding by deciding it is annoying; you update the affected brief to reflect the new knowledge, then flip resolved: true, and the brief re-enters the queue on the next derivation pass. An unresolved finding is a standing alarm, and the schedule is the thing it rings.

a paragraph is not a verdict

Teeth create an attack surface, and this is where the metering rule earns its place in the opening. Filing a finding is unverified input: any identity, human or agent, can write a paragraph. If a paragraph could also force an in-flight brief backwards — demote work that is mid-implementation — then anyone could knock a rival brief out of the queue by filing one. The register would become a denial-of-service tool against the schedule it exists to protect.

So the effect of a finding is tiered by the verification behind it, and the ack: field is the switch:

The linter's own messages trace the ladder. Unacknowledged, the operator sees a notice: unresolved F-alert-path-dead awaits desk ack. Acknowledged — a coordinator has written a dated ack: into the entry, on the record, under review like any other change — the same finding against an in-progress brief becomes a hard failure: demote to todo (re-gate) or resolve the finding. The paragraph could always flag; only an accountable judgment can force. Pulling unclaimed work from a queue is cheap to undo, so unverified input may do it. Knocking live work backwards is expensive, so that takes a signature.

One piece of small print is deliberate: a malformed ack on a resolved finding does not error. A resolved entry is history, and nobody should be forced to rewrite register history to make a checker pass.

tombstones, and the tamper-wire we traded away

Withdrawal is the same discipline pointed backwards. A finding filed in error, an intake idea that died — the file stays. You flip its resolution or disposition and let the body explain; the entry becomes a tombstone. Deleting the file is a lint failure by itself: register entry removed (tombstone-not-delete), with instructions to withdraw in place. Stated at its honest strength: a tombstone is an auditable record of a retraction, not proof of good faith. It cannot make a withdrawal honest; it makes the withdrawal — date, stated reason, author — permanently inspectable, so a quiet reversal becomes something a later reader can judge.

Deletion detection has a history worth telling, because the trade is the design posture in miniature. The first dialect numbered entries sequentially — F-01, F-02 — and the sequence was a tamper-wire: delete an entry and the gap accused you. But a counter is also a lock: concurrent authors contend for the same next number, precisely the write contention per-entry files exist to remove. So the current model uses slug IDs derived from titles, and the specification is blunt about the cost: slugs carry no contiguity guarantee, "there is no sequence to have a gap in," and a conforming linter is forbidden to claim gap detection. The replacement wire is a tombstone check against trunk history: any entry file that ever landed on trunk but is absent from the working tree is flagged by name — stronger for the case it covers, since it names the missing file instead of inferring a hole. Its limit appears below.

the front door, and the register that isn't built

Intake gets the same machinery with lower stakes. An idea arrives as one file; its disposition: field is the single authoritative word on whether it is live, parked, scoped into a stream, or rejected — the linter refuses to infer status from surrounding prose. An idea becomes work only by becoming a brief; rejection is a tombstone with a reason; only new counts as untriaged for the age alarm, so an answered question left labeled new is itself a defect — reported intake debt that does not exist.

Honesty requires a third admission: the design describes a RETRO register — a cadence retrospective whose inputs are generated numbers only, because "a retro that reads its own narrative measures the narrator, not the system" — and it is not implemented. No entry directory, no parser, no enforcement; the specification marks the section informative. The design intent is real and the tense matters: it is a shape we intend, not a thing we run.

what the register did not catch

The registers assume their own writers may be adversarial, and an adversarial review took the invitation. The guard above was built around one suppression model: deleting an entry file. It said nothing about mutating one. An agent whose brief had been demoted by an open finding could edit that finding's frontmatter — flip resolved: true, or quietly empty its affects: list — in an ordinary change, with no corroboration, and lint passed. Since affects: is what pins the brief, gutting it silently unblocked the demoted work: the exact self-serving move the register exists to prevent.

The hole was filed as a finding — against the register mechanism, in the register — sat on the record as a standing alarm, and was closed by extending the guard: the load-bearing fields of any entry already landed on trunk are now diffed against the landed version, and an unauthorized change to resolved, affects, or ack is a hard failure unless a named human's authorization resolves through the identity map. Removing an ack is named in the guard's own words for what it does: it "downgrades the hard re-gate problem to a notice."

Two limits stay open, stated as precisely as the powers. The tombstone check is a history comparison, so it is advisory: run where trunk history is unavailable, it silently finds nothing, and a clean result means "no deletion observed," never "no deletion occurred." And no part of any of this verifies that a finding is true. A well-formed entry full of falsehoods will flag its targets and sit unresolved until someone reads it and judges it. The meter bounds what a lie can cause — a flag, never a forced demotion — not whether one can be told. That bound is the design's honest claim, and its whole claim.

a memory you can install

Nothing here needs our tooling. Four decisions, on any forge, with markdown and a scripting language: make each memory entry its own append-only file with typed references; derive your queue so an unresolved entry excludes the work it names; require an attributed, on-the-record acknowledgment before any entry can force in-flight work backwards; retract by tombstone, with a lint that compares the entry directory against trunk history. Then treat every write to that memory as the registers do — unverified input from a narrator who may be wrong or adversarial. Anyone may append. Nothing may erase. What an entry can force scales with the verification standing behind it.

How the board is compiled from these files — and from the briefs and evidence logs beside them — is the flagship introduction's story: derived, linted, re-verified.