PROVISIONAL — awaiting manual review of every flagged row; corrections ship in public, with receipts

A weekly census of zombie beliefs

How long does a retracted rule survive unnoticed? We started counting.

11 of 38
scored repos carry a revived dead rule (provisional until manual review) this week
2026-W30 · 38 of 56 tracked repos scored · method sha256:f747fe9f1f6f… · Not measured: see the Method.27 CLEAR11 WALKING

A zombie belief is a rule your team retracted — on the record, in your own git history — that later crept back into the file your agent reads. The agent sees only today's text; it cannot see the retraction. This index keeps the record.

Context rot is what happens in the window. Belief rot is what happens in the store.

Check my repo — one command, runs entirely on your machine:
uvx sagrada-linter scan-history .
Or see who consented to be looked at:
Browse the index

How a belief rots

How well does your agent follow its rules? Step through it — nine steps, one sheet.

  1. 1 · Everything arrives through the window — You on one side, the model on the other. Everything the model knows about your project arrives through this window — and lives exactly one session.
  2. 2 · The sources feed it — as copies — From the far side: your rule file, line by line, beside other context that arrives unmarked — you don't see its source, and neither does the model. The window holds copies, not sources.
  3. 3 · The record keeps every version — Zoomed out, the pieces become the system. Beside the file sits the record — every version, every date, kept.
  4. 4 · You change your mind — The old rule is struck out, dated, on the record. Today's file simply no longer carries the line — and next session, the window reflects today's file.
  5. 5 · A merge restores the old text — Same bytes, back in the file. The window receives copies; it has no memory. Nothing in it can flag the line.
  6. 6 · The model takes today's file at its word — Your agent follows its rules perfectly — including the one you killed months ago. A retracted rule, obeyed again: a zombie belief. The window sits between you and the sources; the model sees only today's file.
  7. 7 · The books catch it — The books scan the record and find the shape: born, retracted, re-added. The finding lands with a receipt whose hash recomputes on your machine.
  8. 8 · Supersession, done right — The fix is bookkeeping: the revived rule is retired with a dated entry — ○ laid to rest — and the dead line settles toward the paper. A changed mind, recorded.
  9. 9 · The system, settled — The sheet remains. Copies still flow, the books still read, and the record keeps every death and every return.

Everything an agent carries between sessions — rule files, memory files, the always-X and never-Y — persists. A retraction has nowhere durable to live: removed in one commit, restored by a merge, obeyed the next morning. Execution traces record what an agent did. Nothing records what it believed — which rules were alive, which were dead, and when the deaths happened.

2026-W29 → 2026-W30+0 laid to rest/1 new undead/census 27%→28.9%
laid to rest = a revived rule was re-buried this weeknew undead = a retracted rule reappearedcensus = share of scored repos carrying ≥1 zombie

Named rows appear only with consent. Every other tracked repo lives unnamed inside the aggregate census — that is the whole of its presence here.