Control plane · Workflow, authority & attention

The Orchestrator + Human Inputs

The control plane that reads authoritative state, determines the next valid action, dispatches bounded work, gathers evidence, and pauses precisely when human intent, judgment, authority, or lived experience is required.

Status · ExplorationVersion · 0.1Audience · Product, Architecture, Engineering, QA, CreativeUpdated · August 7, 2026

Strategy

Defines why.

Knowledge

Defines what is known.

Execution

Delivers and proves.

Platform

Preserves reuse.

Governance

Controls authority.

Learning

Changes future behavior.

CONTROL PLANE

Orchestrator

Coordinates next action.

01 · Position

Coordinate the system without becoming another source of truth

The Orchestrator reads the six systems, applies governance, assembles task-specific context, coordinates execution, and preserves state in Git.

The workflow control plane

It determines what may happen next—not what the product should mean, which architecture is desirable, or which risk a human should accept.

Human inputs are versioned operating inputs, not interruptions. They contribute what AI cannot legitimately invent.

Strategy defines intent.

Governance defines authority.

Orchestrator determines the next valid action.

Humans supply intent, judgment, authority, and experience.

Agents execute inside bounded scope.

Git preserves authoritative state.

The Orchestrator decides what may happen next. It never invents the decision required to keep work moving.

02 · Continuous questions

Fifteen questions keep work ready, bounded, and governed

Every transition is based on current artifacts, explicit authority, dependencies, qualified actors, and required evidence.

1Current state?

Which versions and approvals are authoritative?

2Active outcome?

What change is currently authorized?

3Ready?

Is work sufficiently defined to begin?

4Next gate?

Which entry criteria must be satisfied?

5Permitted scope?

What exactly may change?

6Qualified actor?

Who can and may perform the work?

7Required context?

What is the smallest sufficient package?

8Parallel work?

Which packages are safely independent?

9Required evidence?

What will prove completion?

10Stop conditions?

What requires pause or escalation?

11Approval valid?

Has new information invalidated authority?

12Human input?

Which intent or judgment is missing?

13Decision owner?

Which role has authority?

14Safe continuation?

What can proceed while input is pending?

15Repository update?

What state and evidence must be preserved?

03 · Principles

Safe autonomy depends on explicit state and boundaries

The Orchestrator earns leverage by reducing ambiguity, preserving traceability, and using human attention only where it adds legitimate authority or judgment.

Artifacts drive flow

Conversation initiates; versioned repository records control.

No inferred approval

Silence and ambiguous assent are not authorization.

Bounded autonomy

Agents proceed independently until a defined stop condition.

Minimal context

Actors receive only sufficient authoritative information.

Safe parallelism

Dependencies and public boundaries determine concurrency.

Evidence moves work

Completion claims never satisfy a gate by themselves.

Invalidation propagates

Dependent work is re-evaluated when sources change.

Resumable state

Failures retain intent, evidence, and progress.

Precise attention

Human requests are decision-ready and role-specific.

Humans govern

Agents generate leverage within approved constraints.

04 · Responsibilities

From state reconstruction to learning triggers

The Orchestrator connects intent to evidence while enforcing policy at every transition.

Capability	Orchestrator responsibility
State reconstruction	Read specifications, approvals, commits, packages, risks, and evidence.
Readiness evaluation	Confirm entry criteria for the next stage.
Planning	Convert approved changes into dependency-aware packages.
Assignment	Select qualified agents or route decisions to named human roles.
Context assembly	Supply current requirements, boundaries, interfaces, policies, and evidence.
Parallel execution	Start independent packages and manage integration order.
Progress + recovery	Track blockers, retry safely, narrow scope, reassign, or resume.
Gate preparation	Assemble decision-ready evidence for the authorized approver.
Policy enforcement	Prevent unauthorized actions, paths, or stage transitions.
Traceability	Link intent → specification → approval → package → commit → evidence.
Learning triggers	Create structured signals from meaningful outcomes and failures.
Repository update	Preserve current state, evidence, decisions, and completed work.

It does

Determine the next permissible action
Enforce defined boundaries and gates
Ask the correct human role for input
Continue independent work safely
Verify evidence before advancement

It must not

Invent product intent or approve itself
Accept risk for a human owner
Change a public contract without authority
Confuse passing tests with experience quality
Broaden scope or hide uncertainty

05 · Lifecycle

Move only when the next state is authorized

A change may traverse this loop several times as OpenSpec progresses through Explore, Propose, Refine, Approve, and Apply.

Intake

Context assembly

Readiness check

Human input if needed

Plan + authorize

Execute

Integrate

Verify

Human acceptance

Learning

Complete

Rework loop

Explore → Propose → Refine → Approve → Apply remain distinct transitions. The Orchestrator coordinates them; it does not collapse them into implied consent.

06 · State contract

Expose a compact, reconstructable operational state

The view is derived from authoritative records and never competes with the specification.

Operational state answers

Which change and commit are active?
Which approval authorizes execution?
Which packages are active, waiting, or blocked?
Which risk and gate come next?
Which stop conditions remain live?

Every update identifies the responsible actor and timestamp.

orchestration:
  id: ORCH-GAME-LIFECYCLE-001
  status: executing
  change:
    id: CHANGE-GAME-LIFECYCLE-001
    version: 0.4
    commit: 8f31c2a
  current_stage: openspec-apply
  authorized_by: APR-GAME-LIFECYCLE-004
  active_packages:
    - WP-LIFECYCLE-CORE-003
    - WP-LIFECYCLE-UI-002
  waiting_packages: [WP-LIFECYCLE-AUDIO-002]
  blocked_packages: []
  next_gate: integration
  risks: [RISK-AUDIO-004]
  stop_conditions:
    - lifecycle-public-api-change
    - memory-budget-exceeded
    - target-hardware-input-conflict

07 · Work package

The bounded package is the unit of safe execution

Each package carries its source authority, permitted paths, required evidence, executor role, and explicit stop conditions.

Completion means more than code

Approved source and objective are linked
Allowed and forbidden paths are explicit
Outputs and tests are named
The executor has only required authority
No stop condition remains unresolved

Boundaries protect reusable platform code from product-local behavior.

work_package:
  id: WP-LIFECYCLE-CORE-003
  risk_tier: 2
  source:
    change_id: CHANGE-GAME-LIFECYCLE-001
    specification_version: 0.4
    approval_id: APR-GAME-LIFECYCLE-004
  objective: implement start, pause, resume
  boundaries:
    may_modify: [platform/lifecycle/**, tests/platform/lifecycle/**]
    must_not_modify:
      - games/sock-rescue/scoring/**
      - platform/audio/public/**
  outputs: [implementation, tests, conformance, notes]
  executor: gameplay-platform-engineer
  verification:
    - all transitions pass
    - no mutation while paused
    - deterministic resume
    - memory budget satisfied
  stop_conditions:
    - public interface must change
    - unspecified state required
    - target behavior not reproducible

08 · Human input model

Humans contribute intent, judgment, authority, and experience

Fourteen input classes make human involvement specific, routable, and traceable.

Intent

Desired outcome or priority.

Selection

Choice among valid alternatives.

Judgment

Qualitative or domain assessment.

Authority

Formal authorization to progress.

Risk acceptance

Ownership of residual exposure.

Expertise

Qualified knowledge unavailable to agents.

Experience

Direct human response to the product.

Evidence

Data produced through human activity.

Constraint

A non-negotiable boundary.

Priority

Relative sequence or investment.

Exception

Temporary authorized deviation.

Confirmation

Verification that a condition is true.

Escalation resolution

Decision when authorities conflict.

Learning adoption

Approval to change future standards.

09 · Involvement depth

Four modes prevent “human-in-the-loop” from becoming vague supervision

Human participation ranges from originating the work to resolving only exceptional conditions.

A · Human-originated

Product vision
Audience and experience goals
Business priorities
Creative direction
Risk tolerance
Hardware commitment

B · Human-gated

Strategy approval
OpenSpec approval
Public interface change
Platform promotion
Risk acceptance
Release authorization

C · Human-in-the-loop

Gameplay tuning
Visual and audio direction
Experience evaluation
Architectural tradeoffs
Design reviews
Hardware troubleshooting

D · Human-on-exception

Stop condition
Contradictory evidence
Artifact conflict
Scope expansion
Increased risk
Specialist judgment

10 · Decision contracts

Ask a decision-ready question and authorize an exact state

The human should not reconstruct the project to understand the choice. Consequential conversational assent is converted into a structured record.

Human input request

human_input_request:
  id: HIR-LIFECYCLE-AUDIO-003
  input_type: risk-acceptance
  required_role: product-owner
  subject:
    change_id: CHANGE-GAME-LIFECYCLE-001
    version: 0.4
    build: platform-0.5.0
  question: Proceed at 27 ms
    against the 20 ms target?
  evidence:
    - target-board-latency-006
    - pause-playtest-003
  options:
    A: delay and correct
    B: approve MVP exception
    C: remove pause audio
  recommendation: B
  blocked: [audio, release]
  may_continue: [docs, harness]

Human input response

human_input_response:
  request_id: HIR-LIFECYCLE-AUDIO-003
  decision: approve-with-conditions
  selected_option: B
  conditions:
    - record release exception
    - remeasure in release 0.6.0
    - do not promote 27 ms as platform target
  approved_subject:
    change_id: CHANGE-GAME-LIFECYCLE-001
    version: 0.4
    build: platform-0.5.0
  responder:
    role: product-owner
    identity: human-product-owner
  invalidated_by:
    - audio architecture change
    - latency above 27 ms
    - lifecycle interface change

Owned

Scoped

Understandable

Evidence-backed

Actionable

Traceable

Conditional

Reversible

Recorded

Propagated

11 · Lifecycle touchpoints

Human value changes by stage

AI prepares evidence and options; humans supply the specific contribution needed to produce an authorized result.

Stage	Human input	AI preparation	Result
Strategy	Outcome, priority, investment boundary	Options, evidence, dependencies	Authorized strategic intent
Explore	Questions, expertise, experience	Research and ambiguity map	Qualified problem
Propose + Refine	Tradeoff judgment and clarification	Draft spec, alternatives, contradiction checks	Approval-ready specification
Approve	Authority and risk ownership	Gate package and recommendation	Exact authorization
Plan + Apply	Exceptional sequencing and escalation resolution	Package graph and bounded execution	Implemented change
Integrate + Verify	Cross-system judgment and experience review	Compatibility, tests, measurements	Complete evidence
Accept + Release	Product acceptance and residual-risk decision	Evidence map, manifest, rollback plan	Authorized distribution
Promote	Support commitment	Reuse and consumer evidence	Platform capability
Learn	Meaning and generalization judgment	Pattern and causal analysis	Adopted improvement

12 · Human roles

Request a responsible role—not simply “a human”

Governance resolves the authorized individual and delegation path.

Product sponsor

Outcome, investment, continuation, cancellation.

Product owner

Behavior, priority, acceptance, tradeoffs.

Creative owner

Visual, animation, audio, delight, coherence.

Chief Architect

Boundaries, interfaces, technical direction.

Engine Steward

Reuse, promotion, compatibility, deprecation.

Embedded owner

Board behavior, peripherals, target evidence.

QA lead

Evidence sufficiency, severity, release quality.

Risk owner

Qualified interpretation and residual exposure.

Producer

Sequence, dependencies, human availability.

Designer

Assets, interaction behavior, visual specs.

Playtester

Direct experiential evidence.

Release owner

Distribution authority and rollback readiness.

13 · Attention management

Treat human attention as a scarce operating-system resource

Bundle related questions, show meaningful deltas, distinguish required decisions from optional feedback, and never infer approval from delay.

Reduce interpretation work

Bundle related questions coherently
Summarize agent output instead of exposing raw traces
Show material differences from the approved version
State what is blocked and what may continue
Offer a recommendation without predetermining the result
Preserve unanswered requests and follow escalation policy

Decision needed · What must be decided

Why now · Which transition depends on it

Recommendation · Preferred option and rationale

Evidence · Facts and uncertainty

Consequences · Tradeoffs by option

Authority + deadline · Who must decide and when delay matters

14 · Waiting states

Block only the scope that depends on the answer

Local questions pause a package; shared contracts pause producers and consumers; strategic, safety, or release risk may stop the change.

Human input required

Classify dependency scope

Pause affected work

Continue independent work

Waiting state	Orchestrator behavior
Local decision	Pause only the affected package.
Interface decision	Pause producers and consumers of the interface.
Platform-boundary decision	Pause proposed shared-code changes.
Evidence request	Continue evidence collection where safe.
Experience review	Prepare a playable build and review protocol.
Risk acceptance	Stop the affected release or exposure.
Strategic conflict	Stop downstream execution.
Human unavailable	Preserve state and use the defined delegation path.

15 · Event loop

React to authoritative changes, not polling noise

Every event triggers impact analysis, policy evaluation, context assembly, dispatch, verification, and state preservation.

Read current state

Detect changed artifact

Find affected work

Re-evaluate authority

Select valid action

Assemble context

Dispatch actor

Observe evidence

Verify return

Update state

Trigger next gate

Create learning signal

Specification approvedCommit createdTest failedBoard measurement uploadedHuman decision recordedApproval invalidatedException expiredPackage blockedInterface changedCapability promotedRelease authorizedLearning adopted

16 · Context assembly

Give every actor the smallest sufficient authoritative package

Context is role-specific, versioned, and labeled as authoritative or informative.

Implementation agent

Approved requirements, paths, interfaces, tests, stop conditions.

QA agent

Criteria, risk tier, commit, and evidence policy.

Embedded agent

Board revision, pins, timing, memory, measurement procedure.

Graphics agent

Asset contract, display, palette, frame and memory budgets.

Architect

Impact, alternatives, dependencies, platform implications.

Human approver

Decision, evidence, recommendation, risk, exact version.

Playtester

Scenario, tasks, build configuration, observation protocol.

Engine Steward

Reuse evidence, consumer needs, compatibility, maintenance.

17 · Failure handling

Recover without escaping the approved boundary

Failures become structured state changes, not reasons to silently improvise.

Failure	Response
Incomplete agent output	Return the package with specific unmet criteria.
File-boundary violation	Reject the change and record the policy violation.
Repeated agent failure	Re-decompose, improve context, or reassign.
Requirement ambiguity	Stop affected work and request clarification.
Public interface must change	Return to the Knowledge Gate.
Hardware contradicts simulation	Preserve measurement and route to the embedded owner.
Incompatible agent changes	Pause integration and resolve contract ownership.
Human decision conflicts with strategy	Escalate to the strategy owner.
Approval references old version	Invalidate it and request reauthorization.
Experience fails despite technical success	Route through Knowledge and Learning.

18 · RP2350 example

Orchestrate Start, Pause, and Resume across platform and product

Parallel packages accelerate delivery while explicit human touchpoints protect lifecycle meaning, creative quality, target behavior, and platform commitments.

Package	Executor	Dependency	Human input
Lifecycle state machine	Gameplay/platform agent	Approved state model	Architect if model changes
Input mapping	Embedded agent	Controller contract	Embedded owner for hardware conflict
Pause overlay	Graphics/gameplay agent	Creative specification	Creative approval
Audio pause behavior	Audio agent	Audio policy	Product judgment on perceived response
State preservation tests	QA agent	Lifecycle contract	QA evidence acceptance
Target-board validation	Embedded + QA	Integrated build	Human hardware observation
Experience review	Human playtest lead	Playable build	Player feedback and product acceptance
Platform promotion	Engine Steward review	Consumer or harness evidence	Human support commitment

Approved lifecycle spec

Bounded packages

Parallel implementation

RP2350 integration

Automated + board evidence

Human experience review

Accept or refine

1 · ProductDefine Pause behavior.

2 · ArchitectApprove state model.

3 · StewardApprove reusable API.

4 · CreativeApprove presentation.

5 · EmbeddedResolve target conflict.

6 · QAConfirm evidence sufficiency.

7 · PlayersProvide experience evidence.

8 · ProductAccept delivered experience.

9 · StewardApprove platform promotion.

10 · ReleaseAuthorize distribution.

19 · Measures

Measure safe autonomy and the quality of human decisions

Success is faster flow with fewer avoidable escalations, complete evidence, correct gates, and lower human reconstruction effort.

Flow

Authorized change to accepted execution.

Readiness

Packages started with sufficient knowledge.

Autonomy

Eligible packages completed independently.

Human burden

Review time by decision class.

Decision quality

Requests resolved without missing context.

Waiting time

Duration blocked on required input.

Parallel efficiency

Independent packages executed concurrently.

Scope discipline

Unauthorized paths or capabilities changed.

Gate accuracy

Invalid transitions prevented.

Evidence completeness

Packages with all required proof.

Recovery

Work resumed without rebuilding context.

Learning closure

Failures converted into verified improvement.

Safe Autonomy Ratepackages without avoidable escalation / eligible packages

Human Decision Efficiencyfirst-review resolutions / total human-input requests

20 · Operating contract

Advance autonomously only when five conditions hold

Current knowledge, governance permission, approved scope, qualified assignment, and objective verification are all required.

Authoritative state changes

Evaluate readiness

Human input required?

Bounded execution + evidence

Stop condition?

Integration + verification

Human experience or acceptance

Learning

Repository update

Next valid action

Autonomy is safe only when the next action is known, permitted, bounded, assigned to a capable actor, and objectively verifiable.

21 · Repository

Preserve orchestration and human decisions as durable state

Plans, packages, dependencies, events, escalations, approvals, experience evidence, and delegation policies live beside the work they govern.

A control plane with exact human control

The Orchestrator coordinates the system without bypassing any source of truth. Human input remains specific, versioned, attributable, conditional, and invalidatable.

Next design artifacts: Orchestrator State Schema, Work-Package Schema, and Human-Input Policy.

orchestration/
├── charter/orchestrator-charter.md
├── state/
│   ├── active-changes.yaml
│   ├── active-work.yaml
│   └── current-system-state.yaml
├── plans/{active,completed,templates}/
├── work-packages/
│   ├── ready/  ├── active/
│   ├── blocked/ ├── review/
│   └── completed/
├── dependencies/
│   ├── change-graph.yaml
│   └── package-graph.yaml
├── assignments/
├── context/{assembly-rules.yaml,packages}/
├── events/{pending,processed}/
├── escalations/{active,resolved}/
├── recovery/  ├── metrics/
└── templates/

human-inputs/
├── policy/
│   ├── human-input-policy.md
│   ├── attention-policy.md
│   └── delegation-policy.md
├── requests/{pending,answered,expired,withdrawn}/
├── responses/
├── experience/{playtests,creative-reviews,usability}/
├── approvals/  ├── risk-acceptance/
├── expertise/  ├── decisions/
└── templates/
    ├── input-request.yaml
    ├── input-response.yaml
    ├── experience-review.yaml
    └── risk-acceptance.yaml