Chapter 10 – The Protected Control Plane

A run cannot widen its own authority, rewrite its required check, or admit or adopt its own candidate.

The organization that adopts policy, admits candidates, and applies effects remains accountable. Automatic admission does not transfer responsibility to a model; it executes delegation the organization approved in advance.

Authority Is Declared Per Property

Code, prose, and tests do not occupy one universal hierarchy. Authority depends on the property being decided.

An artifact may play different roles for different properties. A schema can define an API shape and be observed Terrain for a schema inventory. A candidate-supplied test may support a behavior claim without being the sole protected check authorized to decide it. CI enforces adopted decisions; it does not create the intent it enforces.

The control plane is therefore not a higher source of truth. It preserves the authority declared for each property while a candidate is produced and considered for Admission or Adoption.

Close the Trust Root

The trust root is the complete set of mechanisms that ordinary work must not be able to weaken. The practical test is simple: what must stay outside ordinary write authority? Common answers include:

• activated Missions, effect policy, routing, and approval rules;
• the runtime components that mediate effects, run required checks, route decisions, and seal Run Records;
• protected contracts, acceptance tests, policy checks, and output schemas;
• CI and admission configuration, ownership rules, and bypass lists;
• scheduler state, credentials, deployment permissions, and kill state;
• the protected audit sink and its retention policy.

Some controls live in the repository. Others live in source control, identity, CI, scheduling, or deployment systems. Repository protection cannot secure an off-repository bypass list. Observe those settings as Terrain and compare them with the governance Map.

Candidate code and documentation may change inside declared scope. Candidate-supplied tests remain supporting evidence. Protected contracts, checks, admission rules, credentials, and audit controls remain outside ordinary write authority.

Changing Protected Controls

The control plane must evolve without giving ordinary work a privileged mode.

An ordinary Mission receives a fixed work contract and bounded effects. Attempts to touch protected controls are denied during execution and rejected again at admission.

A Governance Mission has a bound contract that pins one named control surface and its base. Once separately activated, it produces a supported, content-addressed proposal in an isolated workspace under stronger approval and validation rules. Owners independent of the requester and candidate producer decide under adopted governance policy whether to authorize Adoption of that exact proposal.

The authoritative transition can use either of two implementation paths:

• Atomic application. During Adoption, the adopter revalidates the proposal identity, current control state, approvals, and required evidence, then atomically applies and selects the exact proposal on the authoritative control surface.
• Non-authoritative staging. A separately authorized mechanism may first install the exact proposal in an isolated or shadow slot. The staged control may produce evaluation evidence, but it cannot govern production decisions, issue authority, control Admission, or replace the currently adopted policy. Adoption later revalidates the staged identity and atomically selects it as authoritative.

In both paths, Adoption is the first event that gives the proposal authority. The Ledger records staging and Adoption as separate events. If Adoption fails, the previously adopted control remains authoritative. Any incomplete installed artifact remains isolated and non-authoritative while the declared recovery path removes or repairs it.

Non-authoritative describes the staged artifact’s production-governance role; it does not make staging consequence-free. Installation, resource use, data access, network traffic, and writes to shared staging state remain effects. Each must be declared and authorized at the boundary where it occurs.

Proposal closure is not Adoption. A Governance Mission may reach complete, producing a supported proposal and sealing its Run Record, while the authoritative protected control remains unchanged. A staged copy may exist, but it cannot govern production before Adoption.

Enforce the Complete Effect Boundary

Filesystem paths are only one effect surface. The implementation varies; the portable requirement is that ordinary work cannot perform or conceal an undeclared effect:

A read-only file permission is not a complete boundary if the worker owns the files, can remount them, can invoke a privileged helper, or can reach a host control socket. Enforce the boundary outside the worker’s authority. Depending on risk, that may require separate identities and namespaces, read-only mounts, dropped capabilities, system-call filtering, isolated networking, a virtual machine, or a microVM.

The runtime’s enforcement of this declared effect envelope is the Scope Guard. It checks attempted effects before application and records attempted and applied effects separately. If an effect cannot be mediated, the Mission does not possess it.

Recompute the Candidate Independently

Admission must not trust a model-supplied path list or summary. A Sensor outside candidate authority computes the actual changeset from the pinned base and candidate using the version-control system’s structured diff.

The comparison must account for both endpoints of renames, file-mode and type changes, symlinks, and untracked outputs. It must normalize paths, enforce repository containment, and identify the policy used for the decision.

The same computation serves two lifecycle points. Before proposal closure, the runtime compares the independent changeset with its record of applied repository effects. A mismatch is contradictory evidence, so the run ends failed. After proposal closure, the Mission Gate recomputes the changeset from the sealed candidate and current base. A missing, ambiguous, or stale revision—or a mismatch with the sealed candidate evidence—denies Admission. The Ledger appends the linked Admission decision without rewriting the sealed Run Record.

One small, trusted admission-dispatch step handles every candidate. It computes the complete effect set, applies the already-bound control-plane policy, and invokes, from the Mission’s bound check set, the deeper checks that the bound policy requires for the observed change. Platform path filters and ownership features may optimize routing, but they are not the trust boundary.¹

The Mission Gate

The candidate-independent Admission check is the Mission Gate. It runs outside candidate-producer authority and verifies:

• the identities and versions of the activated Mission, base, candidate, policy, and required checks;
• the complete observed effects and diff against declared authority;
• every required check and declared output contract;
• required approvals and routing predicates;
• the absence of missing or contradictory evidence.

Proposal closure and Admission remain separate. Base drift after proposal closure produces this sequence:

The sealed Run Record remains unchanged. Its complete result says that the workflow produced a supported proposal under the evidence then available. The later gate denies admission because the current base no longer matches that evidence.

Humans need not approve every low-risk instance. Adopted policy may automatically admit candidates backed by supported proposals in a narrowly defined low-risk class with comparable evidence. The gate still applies organizational authority rather than model authority.

The practical consequence is that higher proposal throughput does not require a direct path from generation to production. Admission can scale by risk class while the rules that authorize production effects remain under separate organizational authority.

Emergency and Stop Controls

Break glass is an emergency Governance Mission, not an unbounded bypass. Its Mission contract must:

• bind the exact incident, target, effects, base, reason, and restoration plan;
• require approval from an identity independent of the requester and responder, plus expiring least privilege;
• write to an audit sink the responder cannot alter;
• restore ordinary controls automatically; and
• run the full protected checks afterward.

A complete kill mechanism has two separate enforcement jobs:

• Stop execution: prevent new work, cancel active work, and revoke credentials at systems that enforce the effects.
• Stop Admission: make an always-required external gate reject merge or deployment while authoritative kill state is active, missing, stale, or unreadable.

The worker cannot own the kill state or its reset authority. A cooperative environment variable may be a signal, but it cannot revoke credentials, stop direct external calls, or cover bypass roles by itself.

Enforcement Evidence

A denied ordinary effect and a later Governance Mission are separate histories. The first retains the attempted write to a protected control, the absence of an applied effect, the finding, a failed result, and a sealed Run Record. The second may retain a supported proposal whose Adoption is still pending.

The evidence contradicts itself if a protected surface changes after a claimed denial, a summary reports a failed check as passing, advancement occurs over a non-overrideable failure or without matching exact authorization for an overrideable failure, a staged proposal governs production, or a control-plane change becomes authoritative without separate Adoption. Under the protected-sink and trust-root assumptions developed in Chapter 12, verification must reject that account.

The Protected Control Plane keeps autonomy delegated rather than sovereign. It enforces the versioned change-process contract outside worker authority: the runtime denies undeclared effects, a separate Sensor recomputes the candidate, and changes to governing rules move onto a separate path. Chapter 11 uses that boundary to govern structural self-modification.