Essay 6.2 — The Markov Phasic Brain, Part 2 of 13.

Essay 6.1 established the load-bearing claim — phases force separation; separated kinds of thinking produce better thinking. This part draws the full picture: every transition the orchestrator allows, the tool-restriction discipline that makes each phase distinct, and a quick operational map of what each compartment produces before we open them one at a time.

The Full Transition Map

The rim of the cycle has more edges than Essay 5 needed to show. Here is the complete map the orchestrator enforces.

Forward edges fire automatically when the phase-commit script’s gate passes: ⓘ

  • idle → observe (start a new cycle)
  • observe → plan
  • plan → execute
  • execute → verify
  • verify → condense
  • condense → idle (close the cycle)

Backward edges are explicit — the agent chooses where to roll back to: ⓘ

  • observe → idle (bail — the cycle is preserved, no new cycle is consumed on re-entry)
  • plan → observe
  • execute → observe or execute → plan
  • verify → execute, verify → plan, or verify → observe (the multi-destination routing — minor fix, design flaw, or context gap, each pointing at a different prior phase)

No backward edge from condense. Once the cycle reaches CONDENSE, the only exit is forward to idle. The brain refuses to un-consolidate. We come back to why in the CONDENSE essay. ⓘ

The gmode side-channel — every phase, including idle, has one extra edge that loops back to itself through gmode. Gmode is short for generic mode. It is the freestyle phase: a deliberately unconstrained mode where none of the OPEVC tool-restriction guards apply, used for work that doesn’t fit the OPEVC ceremony. Why does a system built on constraint ship a way around its own constraints? Because a constraint with no sanctioned exit becomes a cage — and a caged agent invents unsanctioned workarounds; gmode is the one deliberate, friction-gated lane out, so the rare off-pattern job has somewhere to go that isn’t a hack. ⓘ

Entry is the same regardless of which phase the agent came from. The agent writes a [GMODE] prefixed question to the user with a substantive reason — a long-form justification of why the work needs to happen outside the current phase’s compartment (currently a roughly 100-word floor in the prototype). The orchestrator stashes the current phase, the agent enters gmode, and the per-phase guards step aside. ⓘ

Inside gmode the agent can do real work for as long as it needs. Fix a deadlock. Make a small plugin edit that doesn’t merit a full OPEVC cycle. Run a plugin-lock ceremony. The mode is intentionally unopinionated. Exit is explicit (the agent calls a small CLI to leave gmode) and requires a clean git working tree — the same discipline that gates every phase boundary. The home phase is restored atomically; the cycle counter does not advance. ⓘ

How gmode is used is a customization choice. The prototype was built running every job through OPEVC because the work was building the seed agent itself. Once the seed agent ships open-source, users will run their project work through OPEVC and may push routine plugin maintenance through gmode. Or define new phases. Or split phase plugins by job type. Gmode is the general-purpose escape hatch from the prototype’s current ceremony, and the seed-cultivator decides what flows through it. ⓘ

Taken together, the prototype’s full state set names the OPEVC phases (observe, plan, execute, verify, condense) plus idle (the meta-state between cycles) and gmode (the freestyle side-channel). The rest of this essay series opens the OPEVC compartments. Idle and gmode are the bookends. ⓘ

The Discipline Is the Tool Restrictions

A phase is not just a label. It is a different write scope.

OBSERVE and PLAN are read-only. The agent can read any file it likes, but the only files it can write are CLAUDE.md files. Code, scripts, configuration, project content — none of it is editable in those phases. ⓘ

EXECUTE has full write access, scoped to the set of directories OBSERVE and PLAN together declared by editing each one’s CLAUDE.md. ⓘ

VERIFY has scripts-only access. The agent can run tests, run scripts, run validators. It cannot edit code. It can write pass/fail results back into CLAUDE.md and into a designated plan file. ⓘ

CONDENSE has the most permissive but most restricted soft-brain scope: it can write .md files across the memory layer — any CLAUDE.md or knowledge file, not only inside .claude/ — plus voice.xml coaching surfaces, but it cannot touch project deliverable files or hard plugin code at all. ⓘ

Tool restriction is the pedagogy. The discipline doesn’t come from telling the agent what to do; it comes from making the wrong move impossible inside the current phase — each phase’s compartment forbids the moves that would skip the cognitive work the phase exists to enforce.

The read-only phases pair up. OBSERVE forces the agent to gather context before it can act — no escape into "let me just patch this real quick," because the patch tool isn’t available. PLAN extends the same lock through the design step: the plan must commit fully to a written contract before EXECUTE can begin, because the alternative isn’t there. ⓘ

The other two cuts close the loop on the back half of the cycle. VERIFY’s scripts-only fence makes self-verification through "the code looks fine to me" impossible; only what the scripts say counts. CONDENSE’s memory-layer fence keeps project deliverable work structurally outside consolidation, so the agent can’t sneak a feature in under the cover of brain-tending. ⓘ

Enforcement is layered. A global guard, registered by the orchestrator plugin, fires on every productive tool call (file edits, reads, shell, web fetches). While the focused job is idle, the gate blocks essentially everything — reads, writes, web fetches, general shell — and unlocks only a small allowlist: the job-management CLI, the phase-advancement CLI, the always-on infrastructure scripts that need to keep running, and memory-file edits. Once a phase activates, the global gate exits silently and the per-phase guard for that phase takes over. ⓘ

Every phase publishes its own guard. Every guard is registered unconditionally and self-exits in milliseconds if the focused job’s phase doesn’t match its own; only the guard for the active phase does real work. Each guard inspects every write call against an allowlist, then consults a shared section-check library to ensure the edit doesn’t cross a phase-section boundary inside any CLAUDE.md. ⓘ

The footer anchors from the previous essay series — ---Ob---, ---Pl---, ---Ex---, ---Ve--- — are physical barriers. Each phase’s guard enforces one rule: writes must land strictly below that phase’s own anchor. The constraint is asymmetric — each phase can write only into its own footer block and the blocks that follow it in the cycle, never the blocks already closed upstream. As the cycle progresses, the editable region shrinks from above: OBSERVE writes anywhere below its anchor into all four blocks, PLAN into three, EXECUTE into two, VERIFY into just the last. Each completed phase becomes part of the locked upstream record. The body above all four anchors is reserved for CONDENSE; none of the four work-on-project phases can touch it. ⓘ

In practice each phase’s work lands in its own block, but the mechanical rule is the floor — "strictly below my anchor" — and that is what produces the forward-pressure. The anchors are not decoration; they are the structural manifestation of compartmentalization. The agent can lose the argument with the user, or with itself, but it can’t lose it with the guard. The guard is code.

The result: each phase produces its own kind of artifact. OBSERVE produces working memory. PLAN produces a plan document. EXECUTE produces code changes plus execution notes. VERIFY produces pass/fail results. CONDENSE produces a clean working memory and durable knowledge files. ⓘ

Every phase has its own plugin. The phasic plugins — one per phase, plus a separate orchestrator that tracks which phase is active for which job — are themselves single-concern packages, each one owning the rules for one mode of cognition. As with the always-on layer, the count is the prototype, not the architecture. A custom seed adding a new phase would add a new plugin alongside the orchestrator. The shape is what generalizes. Essay 7 deconstructs the plugin kit; Essay 7.9 walks through a worked example — a hypothetical phase_research plugin slotted between OBSERVE and PLAN, with the two-lock pattern that wires it in. ⓘ

The discipline runs forward through each phase, too

The tool fence is a wall around each phase. There is a second discipline that runs through the phase, start to finish — and it is just as load-bearing. Each phase moves through an operational-then-metacognitive flow, and the two halves are carried by the phase’s two voices. ⓘ

Each phase splits into two jobs: doing the work, then examining how the work went. The entry voice (the two-voice design is deep-dived in Essay 7.3) opens the operational work — it points the agent at the subagents that do the phase’s actual job: gather context, draft the plan, build the change. That is the half everyone expects. The exit voice does the part that is easy to skip and expensive to lose: before the phase may advance, it requires a round of reflection, and that reflection is what writes the phase’s slice of the cycle’s compaction file. Look at the asymmetry — the entry voice spends the agent on the task; the exit voice spends it on the post-mortem. ⓘ

Each phase carries its own reflection lens, matched to the kind of thinking the phase just did. OBSERVE ends with a blindspot-finder — what context did the gathering miss? PLAN ends with a premortem lens — assume the plan already failed; why? EXECUTE ends with a drift-auditor — what got built that the plan didn’t call for, and what did the plan call for that never got built? The back half of the cycle turns the lens inward: VERIFY runs a meta-audit asking what the checks themselves missed, and CONDENSE runs a promotion-scan for which of the cycle’s learnings deserve to become durable knowledge. Each lens turns the phase’s own work back on itself one last time before the boundary opens. ⓘ

A phase does not advance on volume. The condition that opens the boundary is an exit gate with three families: enough reflection ran, enough new notes were left in the working memory for CONDENSE to harvest later (a soft nudge, not a hard block), and at least one of the phase’s reflection subagents actually ran and left a receipt. The rhythm from Essay 6.8 keeps pacing the work inside the phase, action by action — read before you write, synthesize before you read more. The door itself opens on reflection: the agent crosses the boundary by showing it examined its own work, never by accumulating volume. ⓘ

CONDENSE is the most-gated phase of all — and the most fitting, because it is the brain’s learning phase. It clears the exit gate and keeps its own deflation target from the CONDENSE essay: it has to compress the working memory back down AND prove it reflected on how well it did the compressing. ⓘ

Two kinds of commit

The tool fence governs what the agent can touch inside a phase. A second discipline governs how a phase ends.

The agent commits as often as it wants inside a phase. Most of those are ordinary saves — a <phase>-commit.sh call without --force to checkpoint a working draft, split a messy change into reviewable chunks, or bank a recovery point before a risky edit. These are intermediate commits, and they pass through untouched: no gate fires, no count is checked, nothing blocks. They are bookkeeping, and bookkeeping should be cheap. ⓘ

Exactly one commit per phase is different: the one that advances the phase. To cross a boundary — OBSERVE handing off to PLAN, EXECUTE handing off to VERIFY — the agent runs the phase’s force-advance commit (<phase>-commit.sh --force). That commit is the only one the orchestrator gates. It checks the phase’s commit shape, it checks the three-family exit gate from Essay 6.8, it checks the phase’s custom requirements, and only if all of them clear does the cycle move forward. The design intent is plain: spend the agent’s care where the decision actually matters — at the boundary where one mode of thinking hands its work to the next — not on every routine save in between. ⓘ

The shape each boundary will demand

There is a third discipline layered onto that boundary commit. It is the sibling of the question shape from the always-on series: a commit shape, enforced by each phase’s commit script.

Each phase’s force-advance commit must carry a required structure of named ## sections in its body, checked before the boundary opens — so the commit is not free prose but a small filled-in form. The form differs by phase, because each phase produces a different kind of evidence. OBSERVE records what it observed, the sources it consulted, and what it resolved. PLAN records the plan for this cycle, the acceptance criteria, the risks, and how VERIFY will test it. EXECUTE records what it implemented, the evidence, and which plan item each change addressed. VERIFY records the criteria it checked, the pass-or-fail verdict on each, and the evidence. CONDENSE records the waterfall steps it completed, the knowledge it routed, and the markers it consumed. And every form ends the same way: a required ## Outstanding Items heading that must be present — and empty. Anything written under it blocks the advance; an understanding gap gets resolved or routed before the phase exits, never carried silently across the boundary. ⓘ

On top of that shape, each phase’s boundary also enforces its own one-off check — the custom gate named per phase in the operational map just below. OBSERVE’s first cycle must expand the job’s objective before it can advance; PLAN’s first cycle must record its plan-file decision; EXECUTE’s first cycle of a multi-cycle job must confirm the plan file actually exists; VERIFY must show an empty outstanding-items list and a plan file it did not quietly edit; CONDENSE must hit its deflation target and clear its markers. ⓘ

The point of all this is cumulative. Each boundary deposits a small, machine-readable record of what the phase actually did. By the time a long job reaches its final cycle, that trail already says, commit by commit, that the work was observed, planned, built, and verified — so the closing [JOB-COMPLETE] question is a thin reference to evidence that already exists, not the one place the whole job’s quality is decided. The shape is canonical and the catalog is fixed; each phase’s commit script enforces it. ⓘ

The phase write matrix. Each phase's write authority broken down across five axes that distinguish the phases from one another
Image 6.1. The phase write matrix. Each phase writes only at or below its own footer anchor — observe can leave forward notes in all four, plan in three, execute in two, verify in just the last; CONDENSE owns soft-brain consolidation.

The transition map is the what; the tool restrictions are the how. Together they are the rules — every edge the orchestrator allows, every tool a phase locks, every gate that guards a boundary, all in service of one payoff: the agent can no longer skip the thinking a phase was built to force.

The rules are drawn. Before we open each compartment one at a time, it helps to walk the whole set at a glance — what each phase is, and what it is on the hook to produce. The next essay is that quick tour: a phase-by-phase map you can hold in your head before the per-phase deep-dives begin.

Essay 6.2 — The Markov Phasic Brain, Part 2 of 13.

Previous: Essay 6.1 — Phasic Foundation — the load-bearing claim and the cycle’s outer Markov shape. Next: Essay 6.2b — The Phase Map — a quick tour of every phase at a glance before the per-phase deep-dives.