# The Historian Ratchet

Essay 5.8 of 8 — The Always-On Digital Cortex.

Essay 5.7 built the substrate — the CLAUDE.md hierarchy with its four-footer protocol and altered-list gate. This part closes the essay with one example of what the always-on layer can do when its single-concern plugins compose. Three plugins, one ceremony, no plugin owning the whole thing.

For the architects in the audience.

Per-plugin living history

For the architects in the audience: the historian ratchet we sketched earlier is worth examining in detail, because it captures the discipline of the whole always-on layer. ⓘ

Every plugin has a file called evolution.md. It is a word-capped narrative (currently 2000 words) of how the plugin got to its current state — what was added, what was rejected, what was learned during which cycle. It is auto-injected into the agent’s context whenever the plugin is unlocked for editing. Think of it as the per-plugin counterpart to interaction_summary's durable conversation memory. interaction_summary carries the summary of the user-agent conversation across compactions; evolution.md carries the summary of the plugin’s own life across cycles. Where git log keeps the mechanical record, evolution.md keeps the narrative one. ⓘ

The naive version of this would be: "documentation that updates itself when the plugin changes."

The seed agent’s version is sharper.

The drift counter and the block

When the agent attempts to unlock a plugin for editing — by issuing a question with the prefix [PLUGIN-LOCK] <plugin_name> — the lock manager runs a small drift-check against the target plugin. The check is a single git command that counts how many commits have touched the plugin since the last time its evolution narrative was synced. The result is the drift count: the number of commits the plugin has accumulated since its history was last narrated. If that count meets or exceeds a configurable threshold (default ten), the unlock is blocked and the agent is told to dispatch the plugin’s historian subagent first. ⓘ

Each plugin has its own dedicated historian — historian-brain-guard, historian-phasic-system, historian-job-core, and so on (thirteen in the prototype, twelve of which live centrally inside plugin_integrity's own folder, with historian-question-discipline living alongside its own plugin) — so the narrative voice for each plugin stays consistent across its lifetime. The template that new plugins clone from when they are born lives in plugin_integrity/template/_historian.md. When dispatched, the plugin’s historian reads the drift log, synthesizes what changed since the last sync, and edits evolution.md under a 2000-word cap enforced by a dedicated hook that blocks any edit which would push the file past the cap. When the cap fires, the block does more than refuse — it coaches the historian to retry with a tighter narrative and to migrate any overflow into sibling documents (per-cycle deep-dives, a decisions log, technical appendices), with evolution.md becoming an executive summary that references those siblings rather than absorbing them. The historian’s last mandatory step is to commit. That commit touches evolution.md, which becomes the new sync point, which means the drift counter resets to zero — and the next set of edits will eventually push it back up, and the cycle repeats. ⓘ

This is the ratchet pattern. A plugin cannot be edited indefinitely without periodically forcing the historian to re-narrate its evolution. Three mechanisms enforce it together: the drift counter that measures elapsed commits, the block that refuses unlock at the threshold, and the historian’s own commit that resets the counter — without that reset, the next [PLUGIN-LOCK] deadlocks. ⓘ

The pattern is portable. Anywhere a system needs to enforce a discipline-that-must-be-done-eventually, the same shape works: a counter that climbs with normal work, a block that fires when the counter crosses a threshold, and a corrective action whose own completion resets the counter. The discipline becomes mechanically inescapable.

The lesson is small: read the work before changing it.

The mechanism makes the lesson non-negotiable. The agent is not suggested to re-read the plugin’s history before editing — a suggestion would be ignored under deadline pressure. The lock blocks. The historian runs. Only then can the work proceed.

Three plugins, one ceremony

The ratchet looks like one mechanism, but it is actually three plugins working together. Recall the three-plugin sketch from earlier — here it is in full.

The agent must be able to ask a [PLUGIN-LOCK] question. That depends on question_discipline recognizing the prefix and letting the question through; without that registration, the call is blocked before the user even sees it. The user’s answer must then be captured and routed to the lock manager. That depends on job_core's split pre-call/post-call pair, which validates the question, captures the approval, and hands the result over. Finally, the edit must close cleanly under test. That depends on plugin_integrity's own safe-lock cycle, which runs the plugin’s test suite when the lock closes and reverts the working tree if the tests fail. ⓘ

No single plugin enforces the historian ratchet. Three plugins compose to make it possible — question_discipline opens the asking surface, job_core carries the answer, plugin_integrity protects the edit. Each plugin owns its own narrow concern. The ceremony emerges from the way they fit together. Essay 7 takes plugin_integrity apart on its own terms — the lock-and-historian ceremony as a single plugin’s anatomy. ⓘ

Call this composed ceremony: narrow parts, structured interfaces, emergent rituals — the same shape as the /compact five-section template, the same shape as the ratchet itself. Narrow constraints composing into behaviors larger than any single constraint. ⓘ

The always-on layer is not a stack of independent guardrails sitting in parallel. It is a small, deliberate ring of single-concern guardrails composing into ceremonies none of them could enforce alone. Your fourth plugin will join the ring — and the ring’s shape, not its current membership, is what carries forward into your own seed. ⓘ

That’s the always-on layer in microcosm. Each plugin a small lesson. Each lesson backed by mechanical enforcement. Discipline the filesystem itself preserves.

The bus is just substrate

The bus we built up across the CLAUDE.md hierarchy is substrate. The hierarchy itself, the always-on layer, the durable knowledge directory — together they form the digital cortex the seed agent rests on. They keep state, enforce work structure, and discipline conversation, all without doing any of the actual cognitive work. ⓘ

The actual work happens in the phasic layer. Five phases. One cognitive organ called CONDENSE. Tools forbidden in each phase that force the agent to think before acting. ⓘ

The substrate is what makes the architecture teachable. A non-developer with enough high-level architectural understanding can customize a seed agent the way someone with the right training can author a complex artifact — without writing the underlying machinery. The destination this series carries you toward is an agent-developer-user triangle that collapses to agent-user, because the architecture is portable enough that the user can be the architect.

But a bus is just substrate. What USES it intelligently — that’s the phasic brain.

Next.

Essay 5.8 of 8 — The Always-On Digital Cortex — Hadosh Academy series on agent architecture.

Previous: Essay 5.7 — The CLAUDE.md Hierarchy — substrate, four-footer protocol, altered-list gate. Next: Essay 6 — The Markov Phasic Brain — five phases, one cognitive organ, and why forbidding tools is the pedagogy.