Chapter 12 – Governance for High-Rate Automation
High-rate automation creates pressures that one guarded run does not: candidates overlap, bases move, exceptions accumulate, and evidence volume can exceed human review capacity. Governance must preserve exact per-candidate decisions while allowing adopted policy to compose and batch work.
A separate maintenance Mission for the same payments service has write authority only within that service’s directory. Its candidate diff stays inside that boundary, but the process also attempts an undeclared network call to an external package registry. 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 |
| Terminal result | All required findings and the rejected candidate | The run ends failed |
| Admission eligibility | failed; Run Record sealed; 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. At high volume, policy and evidence must preserve that distinction without turning human review into an unbounded fallback.
Policy Governs More Than Checks
Governance policy fixes the authority and effect rules, required checks, evaluators and data, routing, approvals, exceptions, and kill state used for a decision. The Mission pins the applicable bundle, and the runtime applies it outside candidate authority.
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 the applicable decision rule, including any exact-exception condition, is satisfied.
Chapter 10’s complete effect boundary remains in force. Policy composition adds decision rules; it does not weaken runtime effect enforcement.
Preserve Every Required Finding
Every required policy result remains present and binding. Security, architecture, scope, and product findings may all apply to one candidate. Priority may determine notification, ownership, or which repair to attempt first. It cannot erase a finding.
A non-overrideable required check must pass. An overrideable failure may advance only when current policy permits an exception and the exact authorization conditions below are satisfied.
When two policies require incompatible actions, the workflow has found an authority conflict, not a ranking problem. If current policy defines no applicable exception, the workflow stops. A lasting resolution requires a Governance Mission proposal to change that policy.
Exact Exceptions
An exception is an authorization artifact held outside candidate authority, 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 failure remains evidence and retains its status. For a rule declared overrideable, a valid exception satisfies a separate authorization condition; it does not make the check pass. A non-overrideable failure denies advancement.
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 policy requires a decision by an authority independent of the requester and candidate producer.
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 Record or calling the model again. Automatic Admission of a candidate backed by a supported proposal 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. The Mission pins the current bundle and target control surface, and the protected evaluation covers positive, negative, boundary, composition, and failure cases. Separate Adoption makes the exact supported proposal authoritative.
A proposed bundle may run in shadow mode before Adoption. It evaluates real candidates and records what it would have decided, but it does not control Admission. Shadow findings remain observational; the adopted bundle remains authoritative.
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 a sink protected from ordinary runner authority. Each record carries an ordered sequence identity and a verifiable reference to its predecessor. A typical implementation hashes the record contents together with the preceding record’s digest. The checkpoints and access controls used to verify the sequence and references also remain outside runner authority. Sensitive evidence may be exposed through role-scoped or redacted views without changing the protected record.
Stable identities and references bind the adopted-intent sources and exact activated Mission to the Run Record. They bind each candidate and attempted or applied effect to that record. External observations and required findings reference the artifacts and claims they evaluate. The record preserves the policy-bound basis for each decision and the terminal result. Later Admission or Adoption events reference the sealed Run Record without reopening it.
Inspection checks three kinds of consistency:
- Sequence and continuity: reject gaps, reordering, and predecessor references or protected checkpoints that fail verification.
- Lifecycle and evidence: reject incompatible terminal results, a summary that reports a failed check as passing, advancement over a non-overrideable failure, or advancement over an overrideable failure without matching exact authorization.
- Authority and binding: reject Admission without a
matching supported proposal and sealed
completeRun Record, or when an exception 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 conditional but useful. Under the stated trust assumptions, a later reader can reconstruct what was authorized, what happened, which evidence supported each governed decision, how the run ended, and which later authority event followed. Sequence identities, predecessor references, and protected checkpoints establish continuity and ordering. Recorded intent, identities, effects, observations, findings, decisions, transitions, and validation support causal reconstruction.
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, the workflow must stop creating new affected proposals or combine duplicate sensing results. It must keep dependent proposals ordered and route novel authority questions to named decision-makers. Summaries may support triage and navigation, but they cannot replace the underlying evidence or serve as the sole basis for Admission.
Batching may reduce duplicate sensing, and adopted policy may authorize transactional or batch Admission. The batch must preserve each candidate’s exact identity, eligibility, evidence, effects, and outcome so that every decision remains independently reconstructable. Its policy must state whether one candidate’s failure aborts the whole batch or denies only that candidate; aggregate success cannot conceal an individual denial.
Coordinate Shared Consequences
Concurrency begins with a declared independence assumption. Workflows may proceed separately only while current policy treats their effect surfaces as independent for every protected property at issue. Independence belongs to a property, not permanently to a repository, service, or team. Declared interfaces define cross-surface semantics.
Each Mission binds every required source and base identity. Its Run Record identifies the version or time of each external observation, and policy defines freshness and causal prerequisites. Later reads, events, and Sensors carry versioned observations of admitted Terrain and adopted Maps or policy. Under declared delivery and read-availability assumptions, dependent workflows eventually see relevant changes. This is a limited eventual-consistency analogy, not a claim of one global snapshot, replica convergence, or agreement among local goals.
Individual eligibility does not establish joint eligibility. Independence ends when one Admission can invalidate another candidate’s bound observation or effects are not established to commute for the protected property. It also ends when a candidate changes shared interface semantics, combined effects can violate a spanning invariant, or candidates consume limited shared capacity.
Current policy must then enforce the joint rule against current state at the protected Admission or effect boundary. The boundary may atomically reject and require revalidation, reserve capacity or enforce an aggregate budget, serialize effects, validate and admit a composite transaction, or stop and route the conflict to named authority. A routed resolution returns to the same boundary for an exact decision. A batch cannot infer compatibility from separate local passes.
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 support a later Map or policy proposal, or a draft Recovery Mission. Separate Adoption makes the former authoritative; separate Activation authorizes the latter to run. The observations cannot directly rewrite the authority under which the original work ran.
Recovery is a new transition from the current admitted state, which its Mission pins. The run carries its own authority, evidence, outcome, and Admission decision rather than rewriting the prior failed run.
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.