System 05 · Authority, accountability & assurance

The Governance System

The layer that determines who may decide, what evidence is required, when work may proceed, and how risk, exceptions, and disagreements are resolved.

Status · ExplorationVersion · 0.1Audience · Product, Architecture, Platform, Engineering, QAUpdated · August 7, 2026

Strategy

Defines intent.

Knowledge

Establishes what must be true.

Execution

Delivers and proves.

Platform

Preserves reusable capability.

Governance

Controls authority, risk, and progression.

01 · Responsibilities

Governance makes authority explicit

Strong control belongs at consequential boundaries. Inside approved boundaries, agents and engineers should operate autonomously.

1Who owns the outcome?

A named accountable human or role.

2Who may execute?

Authorized agents, engineers, and tools.

3Who may approve?

The authority for the applicable decision class.

4What is approved?

The exact artifact, version, commit, or release.

5What evidence is required?

A defined review and validation package.

6What risk is accepted?

Exposure, owner, duration, and mitigation.

7When must work stop?

Mandatory-review and escalation conditions.

8How are exceptions handled?

Explicit, narrow, time-bounded authorization.

9How are conflicts resolved?

An escalation path and final decision owner.

10How is history preserved?

Durable, versioned decision records.

11When does approval expire?

Material-change and revalidation rules.

12Is governance effective?

Risk reduction without excessive delay.

02 · Principles

Ten rules for minimum sufficient governance

The system protects consequential intent and risk without turning every engineering choice into a ceremony.

1Humans own consequential intent

AI can recommend, execute, and verify; humans approve meaning, risk, contracts, and releases.

2Authority follows impact

Local reversible choices need less oversight than strategic or compatibility decisions.

3Approval applies to an exact version

Artifact, commit, evidence, conditions, and approver are inseparable.

4Evidence precedes confidence

Plausible AI reasoning never substitutes for tests, measurements, or qualified review.

5Separate duties as risk rises

Critical work should not be authored, verified, and approved by one actor.

6Exceptions are temporary

A waiver cannot silently become the new standard.

7Govern at boundaries

Approved packages proceed until a defined stop condition occurs.

8Preserve decision history

New decisions supersede prior records; they do not erase them.

9Target hardware resolves uncertainty

Measured RP2350 behavior outranks simulation where the two conflict.

10Create flow, not ceremony

Remove controls that do not improve authority, evidence, traceability, or risk.

Governance does not replace engineering judgment. It defines the boundaries within which that judgment can be exercised.

03 · Scope

Concentrate control where consequences compound

Governance focuses on decisions that change intent, contracts, risk, support obligations, or the viability of the complete platform.

Product intentUser experiencePlatform boundariesPublic interfacesHardware behaviorSecurity & safetyPrivacy & licensingPerformance & memoryCompatibilityTechnical debtRelease readinessDeprecation & migrationStrategic investment

Routine implementation choices stay with the authorized executor when they remain inside the approved specification, risk tier, and work-package boundaries.

04 · Decision classes

Not every decision deserves the same process

Classification assigns the right authority and review depth. A decision may span several classes, so the highest applicable consequence governs.

Class	Examples	Typical authority
Strategic	Platform investment, market, product outcome	Product sponsor
Product	Game behavior, scoring, experience priorities	Product or creative owner
Architectural	Layer boundaries, shared interfaces, technology choices	Chief Architect
Platform	Capability promotion, compatibility, deprecation	Engine Steward
Engineering	Internal algorithms and implementation patterns	Assigned engineer or agent
Hardware	Board support, peripherals, electrical assumptions	Embedded owner
Quality	Thresholds, evidence sufficiency, release defects	QA lead
Operational	Build, integration, deployment, rollback	Execution owner
Risk	Security, safety, privacy, licensing, exposure	Designated human authority
Exception	Temporary deviation from an approved rule	Owner of the affected rule

05 · Authority model

Separate contribution from authorization

Every governed artifact identifies responsibility for authorship, execution, verification, approval, and outcome ownership.

Accountable owner

Ultimately responsible for the outcome.

Author

Drafts the proposal or artifact.

Executor

Implements approved work.

Reviewer

Evaluates specialty correctness.

Verifier

Produces or evaluates evidence.

Approver

Authorizes intent, risk, or progression.

Informed parties

Receive the decision and consequences.

Veto authority

Blocks progression inside defined accountability.

ExploreProposeRecommendExecuteVerifyApproveVetoEscalate

AI agents normally receive Explore, Propose, Recommend, Execute, Verify, and Escalate. Approval and residual-risk acceptance remain human unless a narrow policy explicitly authorizes automation.

06 · Risk tiers

Governance intensity follows consequence and reversibility

Code size is a poor proxy for risk. A one-line timing, memory, or public-contract change can demand the strongest review.

Tier 0

Routine

Local, reversible, no contract impact. Automated checks; executor may complete.

Tier 1

Bounded

Approved package, limited subsystem impact. Peer or agent review and required tests.

Tier 2

Significant

Cross-component behavior or quality-budget impact. Domain owner and QA approval.

Tier 3

Critical

Public API, platform boundary, hardware, or compatibility. Architect, steward, specialist.

Tier 4

Restricted

Safety, security, privacy, legal, or irreversible release. Qualified human approval.

Use the highest applicable consequence—not the apparent implementation effort—to assign the tier.

07 · Artifacts

A durable governance package

Machine-readable enough for Codex to enforce; human-readable enough for an owner to approve confidently.

Artifact	Purpose	Required content
Governance Charter	Defines governance scope	Principles, roles, authority, escalation
Decision-Rights Matrix	Maps decisions to owners	Class, approver, reviewers, veto authority
Gate Policy	Defines progression rules	Entry criteria, evidence, approval, expiry
Approval Record	Authorizes an exact state	Versions, commit, evidence, conditions
Risk Register	Tracks material exposure	Probability, impact, owner, mitigation, status
Exception Record	Authorizes temporary deviation	Rule, reason, controls, scope, expiry
Decision Record	Preserves consequential choices	Context, options, decision, consequences
Conflict Record	Resolves contradictory direction	Parties, artifacts, final authority
Audit Trail	Reconstructs lifecycle events	Actor, action, timestamp, source, result
Release Authorization	Approves distribution	Build, targets, evidence, risks, rollback
Governance Review	Measures effectiveness	Delays, escapes, overrides, improvements

08 · Approval contract

Approval is a precise authorization

It is not a conversational impression. It identifies the exact subject, scope, evidence, conditions, accepted risk, human authority, and invalidation rules.

Minimum approval contract

A valid approval binds seven things together:

Decision and risk tier
Artifact version and commit
Authorized and excluded scope
Evidence reviewed
Conditions and accepted risks
Named human approvers
Invalidation triggers

approval_id: APR-GAME-LIFECYCLE-004
approval_type: knowledge-gate
decision: approved-with-conditions
risk_tier: 3

subject:
  artifact_id: CHANGE-GAME-LIFECYCLE-001
  version: 0.4
  repository_commit: 8f31c2a

scope:
  authorized_stage: openspec-apply
  authorized: [start, pause, resume]
  excluded: [save-to-storage, power-cycle-suspend]

conditions:
  - measure latency on Feather RP2350 HSTX
  - complete 100 pause-resume cycles
  - return if lifecycle API changes

accepted_risks:
  - id: RISK-AUDIO-004
    owner: audio-system-owner
    expires: platform-release-0.6.0

approved_by:
  - human-product-owner
  - human-architect
  - human-engine-steward

invalidated_by:
  - source-artifact-version-change
  - public-interface-change
  - unmet-approval-condition

09 · Operating-system gates

Each gate asks one consequential question

A gate is a decision point, not a meeting. It can be asynchronous when evidence and authority are explicit.

01Strategy Gate

Is this outcome worth pursuing?

→ Knowledge development

02Knowledge Gate

Is the change defined and testable?

→ OpenSpec Apply

03Execution Readiness

Can bounded work begin safely?

→ Work-package execution

04Integration Gate

Are completed packages compatible?

→ Integrated change

05Execution Acceptance

Was the approved change delivered and proved?

→ Platform review or release

06Platform Promotion

Should this become supported capability?

→ Supported platform release

07Release Gate

Is the build ready for intended users?

→ Distribution

08Learning Adoption

Should discovery change standards?

→ Updated operating model

10 · Gate lifecycle

Approval is stateful—and revocable

Review status communicates whether work is authorized, awaiting evidence, conditionally allowed, expired, rejected, or invalidated by change.

Pending

In Review

Approved

Approved + Conditions

Satisfied

Closed

More Evidence → In Review

Rejected → Closed

Conditional → Expired

Invalidation rule: approval returns to review when a material source artifact, public contract, risk assumption, evidence set, or target changes.

11 · Human–AI boundary

AI expands execution; humans retain consequence

Agents can do substantial autonomous work within authorization. Humans decide intended meaning, public commitments, experiential quality, residual risk, and release.

AI agents

Detect ambiguity and contradictions
Analyze alternatives and consequences
Recommend risk tier
Draft specifications and work packages
Implement within approved scope
Run tests and collect evidence
Review code and policy compliance
Propose platform promotion
Prepare reproducible releases
Stop and escalate when boundaries break

Human authorities

Resolve intended product meaning
Choose consequential direction
Confirm material risk
Approve authoritative specifications
Review experiential and qualified evidence
Accept residual risk
Approve public contracts and support obligations
Authorize distribution
Resolve cross-authority conflict
Own the outcome

AI must never infer human approval from silence, an older version, or a general instruction to “proceed.”

12 · Governance vs orchestration

Codex can route governance without becoming the governor

The distinction prevents workflow automation from silently acquiring approval authority.

Governance

Defines who may decide
Establishes gates
Sets policies and boundaries
Determines required evidence
Defines escalation authority
Accepts risk
Authorizes progression

Orchestration

Routes work to the correct actor
Evaluates gate readiness
Enforces policies during execution
Collects and links evidence
Initiates escalation
Presents risk for acceptance
Advances after authorization

13 · Exceptions

Permit a deviation without rewriting the rule

Every exception is narrow, owned, controlled, expiring, and linked to a resolution path.

Exception contract

A waiver is valid only when its impact is understood and its temporary nature can be enforced.

Narrow scopeNamed ownerCompensating controlsExpiry date or eventResolution actionQualified approval

exception_id: EXC-AUDIO-LATENCY-002
status: approved
risk_tier: 2
scope:
  product: sock-rescue
  build: 0.5.0
  target: feather-rp2350-hstx
deviation:
  required_maximum_ms: 20
  observed_maximum_ms: 27
controls:
  - monitor resume failures during soak
  - do not promote latency to stable contract
owner: audio-system-owner
expires:
  event: platform-release-0.6.0
  latest_date: 2026-10-01
resolution: optimize or amend requirement

14 · Conflict & escalation

Resolve disagreement through authority, not velocity

The agent or contributor who acts first does not win. The type of conflict identifies the final decision owner.

Conflict	Final decision owner
Product behavior vs implementation preference	Product owner
Product request vs platform boundary	Product owner + Engine Steward; sponsor if unresolved
Architecture vs short-term schedule	Chief Architect + delivery owner
Test evidence vs implementation claim	QA lead
Simulation vs target hardware	Embedded owner using measured evidence
Platform reuse vs abstraction cost	Engine Steward
Risk acceptance vs delivery pressure	Designated risk authority
Two approved artifacts contradict	Owner of the higher-authority source
Strategy conflicts with specification	Strategy owner; execution stops

Stop means stop the affected work—not abandon the system

Codex preserves state, creates an exception or change record, identifies the correct authority, and resumes unaffected packages where dependencies permit.

15 · Change control

Material change invalidates the affected approval

Approval is durable only while its subject, evidence, assumptions, risk, and target remain materially unchanged.

Intended user behavior changes

Public interface changes

New platform dependency appears

Game policy moves into shared code

Hardware assumptions change

Memory or timing budgets are exceeded

Required validation is unavailable

Security, safety, privacy, or licensing issue appears

Implementation diverges from approved design

Accepted risk increases

Approval condition cannot be satisfied

Target or evidence set materially changes

Internal implementation changes can stay inside Execution when they do not alter the contract, risk tier, evidence requirement, quality budget, or approved scope.

16 · Git governance

Git is the authoritative record of governed engineering state

Pull requests connect code to the specification, authorization, evidence, exceptions, and release decision—but do not replace them.

Protected branches

Main and release paths require policy checks.

Traceable changes

PRs link approved change and work-package IDs.

Risk-based checks

Requirements scale with the assigned tier.

Code ownership

Platform and hardware boundaries route specialist review.

Attributable approvals

Records identify the exact human authority.

Immutable releases

Tags bind commits, toolchains, targets, and evidence.

No critical self-approval

Separation of duties is enforced for high consequence.

Path enforcement

Unauthorized file changes fail automatically.

Explicit supersession

Decisions remain in history when replaced.

Required traceability: requirement → approved specification → work package → commit → test evidence → gate decision → release.

17 · Policy-as-code

Automate objective governance rules

Codex and CI should enforce what can be evaluated mechanically, reserving human attention for judgment, experience, and consequential tradeoffs.

Examples of enforceable policy

Approved OpenSpec ID existsFiles stay within package boundariesPlatform paths require steward reviewPublic headers trigger compatibility testsHardware changes attach board evidenceCritical packages cannot self-approveExceptions include owner and expiryManifest names commit and toolchainTests link to evidenceApproval references current versions

Keep subjective decisions human: gameplay quality, visual character, experiential tradeoffs, and strategic value.

# Illustrative policy contract
if: modified_path matches platform/**
require:
  - engine-steward-review
  - compatibility-tests

if: risk_tier >= 3
prohibit:
  - author-equals-sole-approver

if: hardware_behavior_changed
require:
  - target-board-evidence
  - embedded-owner-review

if: exception.status == active
require:
  - owner
  - expiry
  - compensating-controls

18 · RP2350 example

Govern Start, Pause, and Resume by decision type

The lifecycle feature proceeds autonomously within its approved contract, then stops only when evidence or implementation crosses a material boundary.

Product intent approved

Knowledge Gate

Bounded execution

Validation + acceptance

Platform promotion or game release

Decision	Owner	Required approval
Player can pause and resume	Product owner	Product approval
Lifecycle state model	Chief Architect	Architecture approval
Reusable lifecycle API	Engine Steward	Platform-boundary approval
Pause input mapping	Embedded owner	Hardware/interface review
Pause presentation	Creative owner	Experience approval
Audio pause policy	Audio + product owners	Policy approval
One-frame transition target	Architect + QA	Quality approval
100-cycle validation	QA lead	Evidence acceptance
Promotion into platform	Engine Steward	Platform Gate
MVP with audio exception	Product owner + QA	Residual-risk acceptance

Mandatory stop conditions

Lifecycle API must change
Pause cannot meet one-frame target
Hardware input contradicts the contract
Audio cannot preserve approved behavior
A game-specific lifecycle state is proposed
Memory or timing budgets are exceeded
Required evidence cannot be produced

Authorized autonomous work

Implement approved state transitions
Map input through the defined abstraction
Build pause presentation to the approved policy
Run unit, integration, and target tests
Collect cycle, latency, memory, and timing evidence
Fix implementation defects inside scope
Prepare the gate evidence package

Complete change authorization

Release Gate

The approved build, hardware target, evidence, platform capability, exception, conditions, approvers, and rollback triggers resolve to one reproducible record.

Approved change version and commit match

Automated and target-board tests pass

100 pause-resume cycles pass

Reference harness passes

Human experience review passes

Audio exception remains explicit

Rollback path and triggers are defined

gate: release-authorization
decision: approved-with-exception
risk_tier: 3

change:
  id: CHANGE-GAME-LIFECYCLE-001
  version: 0.4
implementation:
  commit: 8f31c2a
  build: rp2350-game-platform-0.5.0
approved_scope:
  product: [sock-rescue]
  capability: [CAP-GAME-LIFECYCLE@1.0.0]
  hardware: [feather-rp2350-hstx-rev-a]
evidence:
  automated_tests: passed
  target_board_tests: passed
  pause_resume_cycles: 100
  reference_harness: passed
  human_review: passed
exceptions: [EXC-AUDIO-LATENCY-002]
rollback:
  previous_release: 0.4.2
  trigger: [state-corruption, input-duplication, display-instability]

19 · Governance health

Measure assurance and flow together

Healthy governance reduces late surprises while increasing safe autonomy.

Decision clarity

Artifacts with named accountable owners.

Traceability

Requirements linked to implementation and evidence.

Gate quality

Defects discovered after approval.

Approval speed

Ready-for-review to decision time.

Rework

Changes returned for missing knowledge.

Exception health

Open, expired, and repeatedly renewed waivers.

Safe autonomy

Packages completed without unnecessary escalation.

Platform integrity

Unauthorized boundary changes.

Reproducibility

Releases rebuilt from manifests.

Human burden

Review time by decision tier.

AI reliability

Agent actions outside authorized scope.

Risk control

Accepted risks with active mitigation.

Outcome: fewer late surprises + more bounded autonomy

20 · Flow safeguards

Prevent governance from becoming bureaucracy

Every control must earn its place by protecting a consequential boundary or improving evidence and accountability.

Automate Tier 0 approval

Review evidence packages, not status meetings

Reuse standing policies for recurring decisions

Approve only at material boundaries

Allow objective conditional approval

Maintain one authoritative record

Inherit unchanged approvals where policy permits

Invalidate only the affected package portion

Measure approval delay and remove low-value controls

Escalate by consequence, not seniority alone

Minimum sufficient governance
The least control that reliably protects intent, platform integrity, safety, quality, and accountability.

21 · Repository

Decision rights need a durable home

Policies, gates, approvals, risks, exceptions, conflicts, audits, and health reviews remain versioned beside—but distinct from—the artifacts they govern.

Governance is an operating contract

The repository makes authority inspectable by humans and enforceable by Codex and CI. Records are superseded rather than erased.

Next design step: define the Decision-Rights Matrix and Risk-Tiering Policy.

governance/
├── charter/
│   └── governance-charter.md
├── authority/
│   ├── decision-rights.yaml
│   ├── role-definitions.yaml
│   └── separation-of-duties.yaml
├── policies/
│   ├── risk-tiering.md
│   ├── approval-policy.md
│   ├── evidence-policy.md
│   ├── ai-authority-policy.md
│   ├── exception-policy.md
│   └── release-policy.md
├── gates/
│   ├── strategy/
│   ├── knowledge/
│   ├── execution-readiness/
│   ├── execution-acceptance/
│   ├── platform-promotion/
│   └── release/
├── decisions/
│   ├── product/
│   ├── architecture/
│   ├── platform/
│   └── operational/
├── risks/
├── exceptions/
│   ├── active/
│   ├── expired/
│   └── resolved/
├── approvals/
│   ├── active/
│   ├── invalidated/
│   └── templates/
├── conflicts/
├── audits/
└── reviews/governance-health/