Governance, Policy, and Risk-Proportional Approval

4. Tradeoffs and alternatives

Central policy versus local autonomy

Central policy improves consistency and auditability but can ignore repository context. Local policy improves relevance but can fragment controls. A layered model can resolve organization, workspace, repository, Factory version, Mission, and WorkOrder rules with explicit precedence. More-specific policy should not silently weaken a higher-level prohibition.

Fail closed versus operational continuity

Failing closed protects authority boundaries but can halt delivery when policy infrastructure is unavailable. Failing open preserves throughput but converts a governance outage into unauthorized execution. For irreversible, external, security-sensitive, or customer-impacting actions, the factory should fail closed. Low-risk advisory behavior can degrade safely if policy explicitly allows that mode.

Human gates versus automated policy

Human review brings context and accountability but is slow, inconsistent, and scarce. Automated policy is fast and repeatable but only as good as its inputs and rules. The useful boundary is not human versus automation. It is automated eligibility followed by human judgment only where policy identifies material risk or uncertainty.

Dual control versus small-team practicality

Two-person approval reduces unilateral risk for red actions. It may be impossible in a very small company. If roles must combine, the organization should narrow allowed actions, strengthen independent technical validation, retain immutable evidence, and require later review. Combining people does not justify combining records or allowing an executor to certify itself.

Numeric risk and trust versus explainable bands

Numeric values support computation, thresholds, and trends. They invite false precision when shown as authoritative judgments. Operators should see bands, drivers, recent changes, and the maximum authority policy permits. A score without reasons is not actionable governance.

Approval sampling

Sampling routine green work can detect drift while avoiding approval fatigue. Sampling is appropriate only after policy has established bounded scope, complete evidence, and a safe rollback path. It must not replace mandatory approval for material risk.

5. Current Mission Control Implementation

This assessment uses Mission Control commit 8014d5af427b43ff5c5a63cfdf82ec92742c208c, studied on 2026-08-08. Browser observations came from a dirty worktree at this HEAD and are therefore retained as run evidence, not reproducible proof of the commit alone.

What is implemented

Mission Control has concrete governance primitives:

• workspace permissions protect Factory viewing, automation management, and activation;
• roles and scoped role assignments provide tenant, project, and environment authorization structure;
• policy envelopes can be version-, project-, or tenant-scoped, prioritized, activated, and evaluated for a tool and Green, Yellow, or Red risk;
• policy decisions use ALLOW, DENY, or NEEDS_APPROVAL;
• approval records preserve action type, risk, rollback, justification, escalation, status, and decision metadata;
• the active approval path auto-approves low or Green actions, expires pending requests, and requires two distinct approvers for Red actions;
• a Factory Configuration version freezes repository, workflow, executor, policy envelope, environment, budget, verifier set, risk boundary, recovery controls, and a configuration digest;
• Factory readiness checks require an active Governance Policy, bounded budget, independent verifier, clean host binding, recovery controls, active workflow, approved executor, repository readiness, and a current least-privilege GitHub App connection; and
• Factory activation requires a current passing assessment for the exact configuration digest and an actor with Factory approval permission.

These mechanisms support the principle that policy and readiness precede execution. The configuration digest is particularly important: it binds the activation decision to one immutable set of operational boundaries.

What is partial or fragmented

The current implementation should not yet be described as a complete governance system.

The general policy-envelope evaluation query returns an ALLOW fallback when no applicable envelope produces a decision. That behavior is weaker than the North Star doctrine that missing authority should fail closed. The Factory readiness path independently blocks activation when an active policy is absent, but the stronger default has not been proven across every tool and execution boundary.

Approval data exists in both the operational approvals path and a newer approval-record model. The relationship is partially mirrored rather than demonstrated as one fully consolidated lifecycle. The operational path records deciders and implements distinct Red approvers, but the reviewed code does not prove that every material decision is restricted to a human identity.

Roles, permissions, policy envelopes, approval records, readiness checks, and evidence gates exist, but the complete decision-rights matrix described in this chapter is not yet one canonical, enforced model. Validator disagreement does not yet have a verified first-class Risk Review workflow.

Operational Autonomy Levels, the numeric Trust Score, trust bands, automatic demotion and quarantine, sustained-evidence promotion, and a Factory Governance Board workflow remain doctrine or future design. They must not be presented as current Mission Control capability.

Why the golden-path run stopped without a Governance Policy

The retained Golden Path 01 execution assessment proved Mission creation, versioned Plan approval, WorkOrder release, and the requirement for a separate Validator WorkOrder. It stopped before Task or Attempt creation.

The Factory Configuration form had workflows but no Governance Policy available for selection. As a result, Mission Control could not create and activate the immutable Factory boundary that combines workflow, executor, policy, budget, verifiers, risk boundary, and recovery controls. Dispatch remained unavailable.

This was not a cosmetic configuration omission. Without an active policy version, the control plane cannot establish which actions the executor may take or which approvals and evidence are required. Proceeding would have turned technical capability into accidental authority.

The run had two additional independent blockers. The Mission Control GitHub App was not configured or installed for the laboratory repository, so the system could not prove least-privilege repository authority, token issuance, branch and pull-request writes, or exact GitHub lineage. Mission Control todo 024—the real Codex-to-GitHub pull-request golden path—also remained incomplete. Its durable worker, leased Attempt, isolated worktree, bounded execution, path scope, idempotent PR creation, lineage, restart reconciliation, and browser proof must be completed before the lab is rerun.

The correct sequence is therefore:

1. complete and verify Mission Control todo 024;
2. configure and install the least-privilege GitHub App for the controlled lab repository;
3. create an active Governance Policy;
4. create, assess, and activate the exact Factory Configuration version;
5. rerun the unchanged golden-path acceptance contract from a clean, pinned Mission Control commit and target-repository baseline.

Documentation can continue while those implementation prerequisites are being completed. The lab result must remain partial until the runtime evidence exists.

Current authority flow

Passing readiness establishes configuration eligibility. It does not prove that todo 024's execution path can yet complete a real pull request.