Governance as a Control Plane

A governance control plane is the system that joins context, policy, evidence, authority, action, and feedback. Its unit of control is an immutable release identity, not a project nickname or mutable model alias. The control plane can decide whether a declared action is authorized, held, blocked, rolled back, or escalated. It should not sit on the inference path, invent policy, silently reinterpret law, or claim that a passing record proves a system safe in every context.

Policy text contains judgment, definitions, scope conditions, and sometimes legal obligations. The engineering contract should encode only the approved operational consequence: which controls apply to this system class, which evidence version and age are acceptable, who may decide, what actions exist, and when the decision expires. Store the source policy and interpretation alongside the compiled rule so reviewers can trace the executable condition back to its accountable authority.

1. 01Resolve applicabilityHave accountable policy, legal, risk, product, and domain owners determine system context, risk tier, affected stakeholders, jurisdictions, and required obligations; preserve their reasoning as a versioned input.
2. 02Name control intentFor each requirement, state the risk reduced, owner, implementation point, evidence producer, freshness window, threshold, failure action, and residual risk rather than copying a framework heading into a checkbox.
3. 03Bind exact evidenceJoin test, review, data, security, oversight, monitoring, and rollback records to the same system and release digests; reject evidence that belongs to another scope or mutable alias.
4. 04Authorize a bounded actionA decision should name the permitted environment, users, traffic, duration, safeguards, owner, monitoring, rollback trigger, expiry, and re-review events instead of returning an unqualified green light.

Separation of duties should match consequence. The team producing evidence should not be able to rewrite the policy or approve its own high-impact exception unnoticed. Emergency authority needs the same design rigor as normal authority: authenticated actor, narrow scope, reason, time limit, notification, compensating controls, immutable trace, and a forced retrospective. If the organization cannot say who can override a block, it has an undocumented override path rather than no override path.

The reference artifact reconstructs frozen governance records, verifies content digests and one six-part scope, checks exact required-control coverage, and distinguishes hard blocks from readiness holds. It rejects unknown controls, duplicate evidence, invalid waiver state, stale contract binding, booleans masquerading as counts, string subclasses, forged records, and tampered digests. All values are invented and the decision is deliberately local.

1def audit_governance(contract: GovernanceContract, evidence: GovernanceEvidence) -> GovernanceReport:
2    contract = validate_record(contract, GovernanceContract)
3    evidence = validate_record(evidence, GovernanceEvidence)
4    if evidence.scope != contract.scope or evidence.contract_content_id != contract.content_id:
5        raise ValueError("evidence belongs to another governance contract")
6 
7    # Every control is bound to this system and release. Hard policy failures
8    # block; stale, unenforced, exception, observation, and rollback gaps hold.

example=illustrative_only
decision=AUTHORIZE_BOUNDED_RELEASE
system=support-assistant;release=release-2026-09-27;risk=HIGH
controls=6/6
claim=LOCAL_GOVERNANCE_AUDIT_NOT_LEGAL_OR_PRODUCTION_APPROVAL

Governance becomes operational when the delivery system enforces the recorded scope and the running system emits evidence tied to it. Monitor the actual model, provider, prompt and tool policy, data path, user cohort, geography, fallback, and release revision. Join incidents, complaints, human overrides, drift, evaluation, access changes, and third-party notices to that identity. A change to intended use or affected population can invalidate a prior decision even if no model weight changed.

• Expire approvals and evidence on declared time, revision, context, provider, interface, data, or policy changes; do not rely on people remembering to reopen review.
• Record which enforcement point consumed a decision and whether observed state converged to the authorized scope before treating the release as controlled.
• Alert on inventory gaps, stale controls, orphaned owners, expiring waivers, unmonitored releases, failed rollback tests, and disagreement between policy and runtime state.
• Route operating harm and near misses back into impact mapping, evaluation coverage, policy, controls, training, and organizational ownership.
• Retain enough evidence and decision history to reproduce why a release was allowed without retaining sensitive data beyond its lawful and operational need.

A staff-level governance review should expose uncertainty rather than polish it away. State which harms were considered, which stakeholders were not represented, which evaluation proxies remain weak, which controls depend on provider assertions, which exceptions are open, and which operating signals can trigger suspension. Invite legal, security, privacy, safety, product, operations, and affected-domain expertise where applicable. The goal is a traceable decision under uncertainty, not the appearance that engineering eliminated uncertainty.