The being of rules
A ruler is two things in English. A sovereign, and a measuring tool. The Ruler at a TreeOS scope is both. They hold authority over a domain, and they ARE the standard against which the work in that domain is measured. The Ruler is not someone who follows rules. The Ruler IS the rules at this scope.
Every node in TreeOS that holds a domain has a Ruler. The Ruler is not a queue, a routing table, or a switch statement. The Ruler is a being you can talk to. They have a perspective, they have judgment, they hear messages and decide what should happen.
That sounds metaphorical, but it's literal in the architecture. Every user message at a Ruler scope passes through an LLM call with the Ruler's prompt, the Ruler's snapshot, and the Ruler's tools. The Ruler reads the state of their domain and decides. The reply you see comes from them.
Four principles shape every Ruler.
The Ruler is responsible for whether the work in their domain adds up to something faithful. A wrong decision quickly is more expensive than a right decision after a moment of inspection. Better to read the plan in detail than to hire a Planner pointed in the wrong direction.
A Ruler's authority arises through acceptance at this scope and ends at this scope's boundaries. They cannot dictate terms to siblings or cousins. They cannot reach across to contracts they don't own. Authority is taken up where work happens. Never imposed from above. Never extended past the domain that took it up. When something exceeds their authority, they escalate. They don't overstep.
The same Ruler primitive runs at the project root and at a sub sub Ruler ten levels deep. Same prompt, same tool surface, same judgment shape. What varies is the snapshot. What they see, not what they are.
The Ruler is a position, not a person. The scope's authority (accumulated approvals, ratified contracts, ledger history) attaches to the position. Occupants can be replaced without destroying the position. When Pass 4 structural remedies replace a branch via court ruling, the position continues with a new occupant. The work that came before persists as record. A Ruler is durable in the way an institution is durable. Any individual is replaceable. The position continues.
The Ruler's judgment is bounded. They don't draft plans (the Planner does), commit contracts (the Contractor does), watch execution flow (the Foreman does), or write content (the Worker does). The Ruler authorizes, ratifies, and synthesizes.
Every turn picks one of these decisions. The decision shape is small. The judgment behind it is the work.
New work needs decomposition. The Ruler hires a Planner, who drafts a plan and exits. The plan returns to the Ruler for ratification.
The plan was approved. The Ruler hires a Contractor to ratify shared vocabulary, the names sub Rulers will reuse.
Plan and contracts are in place. The Ruler dispatches. A Worker writes any leaf step files at this scope. Sub Rulers handle branch steps recursively.
Execution is in flight. The user has a question about it. The Ruler routes to the Foreman, who reads the call stack and decides.
The plan is wrong, or the user changed their mind. The Ruler revises the plan or archives the whole cycle and starts over.
The user asked something the Ruler can answer from the domain state. No spawn, no role hire. The Ruler speaks.
Halt active execution mid flight, or unpause and let the Foreman reenter. Pause survives session refresh.
The judgment exceeds the Ruler's own. Convene a court (Pass 2 substrate today) to weigh evidence and rule.
The Ruler primitive is uniform, but turn discipline differs based on whether a user sits between this Ruler and the next decision.
The user is between turns. After every spawn, the Ruler synthesizes for the user, exits, and waits for the next message. One tool per turn. The user sees each stage of the lifecycle as a separate moment.
"Plan drafted. Reply yes to approve."
No user between turns. The parent's dispatch IS the gate. The sub Ruler chains its full lifecycle in one turn. Hire planner, hire contractor, dispatch execution, exit. Each tool spawns its respective role as a chainstep child. The sub Ruler's context stays disciplined.
"Sub Ruler for game engine. Drafting plan, contracts, dispatching."
Before deciding, the Ruler reads a snapshot of their domain. The snapshot is built fresh per turn, summary level by default, with an inspection tool to drill in when needed.
Who am I, where am I in the tree, am I a root or a sub Ruler.
The awaiting field. What stage the architecture wants advanced next. contracts, dispatch, user-resume, or null.
If a plan exists, the Ruler sees its step count, branch and leaf split, recent revisions. Full step detail is one tool call away.
The names sub Rulers must reuse, scope tags, ratification status.
Steps pending, running, done, failed, blocked. Recent transitions. Stuck branches if any.
Names, statuses, recent activity. The Ruler spots conflict and stall here.
Parent's plan, parent's contracts in force at this scope, which step we're expanding. Sub Ruler decisions build on the parent's plan, never contradict it.
The awaiting field is the primary cue. It names what the architecture wants advanced next. The Ruler reads the user's message in light of it.
When the snapshot summary doesn't tell the Ruler enough, inspection comes first. The Ruler can call read-plan-detail or get-tree-context to see the full plan or local tree state before picking an action tool. Inspection doesn't end the turn. It informs the decision. A Ruler that inspects before deciding is exercising the coherence over speed principle in real time.
States waiting on user input default to respond-directly until the user signals approval. States waiting on system action (contracts, dispatch) advance with the corresponding system tool. That's the architectural flow the user implicitly authorized when they accepted the plan.
User types "build me a Flappy Bird battle royale" at a fresh tree root. Here's what the Ruler's first turn actually does.
The root node promotes itself to Ruler. metadata.governing.role = "ruler" with an acceptedAt timestamp. The promotion fires governing:rulerPromoted.
The Ruler reads its domain. State is empty. No plan, no contracts, no execution. awaiting: null + no plan.
Plain prose, one sentence. "Fresh project request. Hiring a Planner to draft a decomposition." Then call governing-hire-planner with the briefing.
A Planner spawns as a chainstep child of this turn. The Planner runs in its own context, drafts the plan, emits via governing-emit-plan, exits. The plan card flashes to the user.
The hire planner tool returns a structural summary. The Ruler writes a brief synthesis pointing the user at the plan card and what to do next ("Reply yes to approve, or describe changes"). Exit.
Five steps, one LLM turn for the Ruler, one chainstep for the spawned Planner. The Ruler's context stays disciplined. The Planner does its full work in its own space.
The Ruler picks one tool, runs one turn, and synthesizes one response. That's all. But the Ruler IS the rules at this scope, and every choice is a measurement of what should happen here.