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

Essay 5.7 built the working-memory form — the CLAUDE.md hierarchy with its four-footer protocol and altered-list gate. This part closes the essay’s deep-dive set with one example of what the always-on layer can do when its single-concern plugins compose. Single-concern plugins composing into 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 (the prototype caps it at a few thousand words; your seed can tune the cap) 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 (currently ten in the prototype), 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 — so the narrative voice for each plugin stays consistent across its lifetime. The narrators live centrally inside plugin_integrity's own folder, with one architectural exception — historian-question-discipline ships inside question_discipline/agents/ instead. ⓘ

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 the word cap enforced by a dedicated hook that blocks any edit which would push the file past it. 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. Several 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. A consulting practice could install the same ratchet on client-deliverable templates: a counter climbs with every template edit, blocks the next checkout at a threshold, and only the practice lead’s narrative re-sync (what changed, why, what’s still open) resets it. 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. The operator can still bypass via GMODE — but only by writing a long [GMODE] justification (the prototype sets a word floor; your seed can tune it) that names what they’re maintaining and why ordinary cycles won’t do; the bypass route is named, not silent, and itself friction-bound. ⓘ

Plugin_integrity's historian ratchet: drift counter climbs with commits, blocks at threshold, historian subagent re-narrates, counter resets
Image 5.8.1. Drift climbs with every commit, blocks the next unlock at the threshold, and resets only when the historian re-narrates the plugin’s evolution.

Composed ceremony from single-concern plugins

The ratchet looks like one mechanism, but it is actually a small ring of single-concern plugins working together. Recall the 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. Single-concern 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. The Essay 7 series takes plugin_integrity apart on its own terms — the lock-and-historian ceremony as a single plugin’s anatomy. ⓘ

Three single-concern plugins fitting together into the historian-ratchet ceremony, each contributing its own narrow concern
Image 5.8.2. No single plugin enforces the ratchet — three single-concern plugins compose the ceremony, each contributing what it owns.

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 next always-on 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 one form of substrate

The bus we built up across the CLAUDE.md hierarchy is one form within .claude/ — the working-memory form, the one the phasic layer writes through. The hierarchy itself, the always-on layer, the durable knowledge directory, the per-plugin hidden state, the voice files, the subagent definitions — together they form the multi-form 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. Compartmentalized phases (currently five in the prototype). 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 — The Always-On Digital Cortex, Part 8 of 9.

Previous: Essay 5.7 — The CLAUDE.md Hierarchy — substrate, four-footer protocol, altered-list gate. Next: Essay 5.9 — The Customization Guardrail — the gate that decides when substrate edits are admitted at all.