Chapter 12 – Governance for High-Rate Automation
A maintenance Mission is authorized to edit one service. Its candidate diff stays inside that directory, but the process also attempts an undeclared network call. A path-only check would pass.
The complete governance path produces three separate decisions:
| Boundary | Evidence considered | Consequence |
|---|---|---|
| Effect enforcement | Declared effects compared with the attempted network call | The runtime denies and records the call |
| Proposal closure | Complete findings and the rejected candidate | The run ends in evidenced failure |
| Admission eligibility | Sealed failed_with_evidence result; no supported
proposal |
No candidate is eligible for admission; any attempted admission is denied |
Under protected-sink and trust-root assumptions, the evidence record must preserve enough information to reconstruct those decisions and reject an account that conceals the attempted effect.
Chapter 10 protected the control plane. Chapter 11 used it for one refactor. This chapter asks how policy, exceptions, evidence integrity, and human authority compose when candidate production becomes frequent.
Policy Is a Protected Check Bundle
Governance policy determines which checks must run and which transitions their findings may permit. The exact rules, evaluator, policy data, and routing logic are fixed outside candidate authority for each decision.
The policy evaluation must also identify the Mission, base, candidate, runtime, and external observations it used. An unavailable dependency or uncaptured lookup produces an inconclusive result rather than an inferred pass. Probabilistic evaluation inherits Chapter 3’s protected protocol and uncertainty rules.
Checks may run in a cost-aware order, but ordering cannot remove obligations. The Judge may reject early. It cannot accept until every required result is complete and consistent.
Chapter 10’s complete effect boundary remains in force. Policy composition adds decision rules; it does not weaken runtime effect enforcement.
Every Required Finding Remains Binding
Every required policy check must pass. One policy cannot cancel another policy’s failure.
Security, architecture, scope, and product findings may all apply to one candidate. Priority may decide notification, ownership, or which repair to attempt first. It cannot erase evidence or turn a required failure into success.
When two policies require incompatible actions, the workflow has found an authority conflict, not a ranking problem. It stops for either an exact exception already permitted by current policy or a separately governed proposal to change that policy.
Exact Exceptions
An exception is a protected authorization artifact, not a warning or a general approval button:
| Binding | Required constraint |
|---|---|
| Mission and state | Exact Mission, base, and candidate |
| Policy | Exact policy bundle and explicitly overrideable rule |
| Effects | Only the specifically authorized effect surface |
| Purpose | Recorded reason tied to the exceptional condition |
| Authority | A valid authorizer independent of the requester and candidate producer |
| Expiry | First use or any material change to the base, candidate, policy, or condition |
The original failing finding remains evidence. For a rule declared overrideable, a valid exception satisfies a separate authorization condition; it does not rewrite failure as success. Non-overrideable rules remain denied.
The Mission Gate validates the binding again against the current admission state. Any changed base, candidate, policy, effect, authorizer, or expiry requires a new exception.
Humans define risk classes, adopt policy, approve rare exceptions, and resolve novel authority conflicts. They do not manufacture check output, delete contrary findings, approve their own request, or convert missing evidence into success. Routine settled policy can run automatically; changing the policy remains a human or independently governed decision.
Admission Revalidates Governance State
At admission, Chapter 10’s Mission Gate also revalidates the current policy bundle, exception bindings, approval requirements, and kill state.
A changed base or policy, missing record, or contradiction can deny admission without reopening the sealed run or calling the model again. Automatic admission executes an adopted delegation for an allowlisted low-risk class; it does not delegate authority to a probabilistic component.
Govern Policy as Authority
Ordinary Missions may report a policy defect but cannot alter the registry, evaluator, policy data, routing, approval rules, bypass list, or evidence sink that governs them.
A policy change follows Chapter 10’s Governance Mission path: fix the current bundle, produce a proposal in a separate workspace, evaluate it against protected positive, negative, boundary, composition, and failure cases, then require independent atomic adoption.
A proposed bundle may run in shadow mode: it evaluates real candidates and records what it would have decided, but it does not control admission. Shadow findings remain observational. The currently adopted bundle stays authoritative until the replacement is independently admitted.
A Ledger Is More Than a Log File
A Ledger is reconstructable decision evidence, not a file format. JSONL, a database row, or an object-store document may serialize records, but none is append-only or trustworthy by itself.
Writers append through a narrow interface to an independently protected sink. Each record carries an ordered sequence identity and an integrity link to the previous record. The checkpoints and access controls used to verify those links remain outside ordinary runner authority. Sensitive evidence may be exposed through role-scoped or redacted views without changing the protected record.
Inspection checks three kinds of consistency:
- Sequence and integrity: reject gaps, reordering, and broken integrity links.
- Lifecycle and evidence: reject incompatible terminal results or a summary that claims success despite required failures.
- Authority and binding: reject admission without a
matching sealed
completeresult or an exception whose binding does not match.
Contradiction resistance is a verification property under a protected sink and trust root. It is not absolute tamper resistance against every privileged actor. A privileged writer or storage administrator may still truncate, replace, or invent history unless stronger organizational and storage controls prevent it.
The guarantee is therefore conditional but useful: under the declared trust assumptions, a later reader can reconstruct the authority, candidate, observed effects, required findings, decision, sealed outcome, and separate admission event, and can reject internal contradictions among them.
Human Attention Is a Governed Resource
High candidate volume can turn human review into an unbounded fallback. When overlapping proposals, stale bases, or aggregate change exceed declared review capacity, stop creating new affected proposals or combine duplicate sensing results. Keep dependent proposals ordered, and route novel authority questions to named decision-makers. Do not approve from summaries or weaken evidence requirements.
Batching may reduce duplicate sensing. It must not batch authorization: each candidate keeps its own Mission, base, effects, findings, result, and admission decision.
Continuous Assurance and Recovery
Runtime Sensors may discover policy drift, invalid exceptions, bypass attempts, evidence corruption, or behavior that escaped pre-admission checks. Those observations can activate a later Map, policy, or Recovery Mission. They cannot directly rewrite the authority under which the original work ran.
Recovery is a new governed transition against the exact admitted state. It receives its own authority, evidence, outcome, and admission decision rather than rewriting the failed history.
At high rates, governance cannot depend on memory or ceremonial review. The protected path established in Chapter 10 must remain enforceable at operating speed; otherwise frequent workflows can bypass adopted authority and become effectively self-authorizing.