System 03 · Controlled delivery & proof

The Execution System

The controlled delivery layer that converts approved knowledge into integrated, tested, reviewable changes—while preserving scope, platform boundaries, evidence, and resumability.

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

Strategy

Authorizes what is worth building—and why.

Knowledge

Defines what must be true.

Execution

Makes approved knowledge true—and proves it.

01 · Responsibilities

Ten questions every delivery run must answer

The output is not simply code. It is an integrated, validated change package traceable to approved intent.

1What is authorized?

Approved change and exact artifact versions.

2What work is required?

Bounded packages with explicit outputs.

3In what order?

Dependencies, critical path, parallel work.

4Who performs it?

Assigned agent, human, or tool.

5What may change?

File, subsystem, and authority boundaries.

6How is it verified?

Required tests, reviews, and evidence.

7What if reality conflicts?

Stop, report, controlled change path.

8How is it integrated?

Branch, interface, merge, compatibility policy.

9Can work resume?

Durable checkpoints and handoff state.

10When is it done?

Measurable completion and authorization.

02 · Artifacts

A connected Execution Package

Operational state is captured in reconstructable artifacts—not informal task lists or chat history.

Artifact	Purpose	Required content
Execution Plan	Defines delivery approach	Scope, sequence, milestones, dependencies, gates
Work Package	Authorizes bounded work	Inputs, outputs, files, constraints, acceptance criteria
Dependency Graph	Controls sequencing	Blocking relationships and parallel opportunities
Agent Assignment	Defines responsibility	Role, capabilities, permissions, escalation rules
Run Manifest	Records execution instance	Environment, versions, commit, configuration
Checkpoint	Supports safe continuation	Completed, remaining, current state, blockers, next action
Change Set	Captures implementation	Code, assets, configuration, documentation
Validation Plan	Defines required proof	Tests, hardware runs, repetitions, evidence format
Evidence Package	Demonstrates results	Logs, measurements, screenshots, reports
Exception Record	Documents deviation	Conflict, impact, disposition, approval
Integration Record	Captures merge readiness	Reviews, compatibility checks, unresolved risks
Execution Summary	Closes the run	Outputs, evidence, residual issues, learning delta

03 · Unit of execution

The bounded work package

One primary outcome, one accountable owner, explicit source specifications, modification boundaries, observable acceptance criteria, evidence, stop conditions, and a handoff destination.

Precise authorization

Implement the transition—not “the feature”

A work package must be small enough for one worker to complete and verify without redefining intent.

Source specifications and requirements
Allowed and prohibited paths
Required outputs and validation
Dependencies and stop conditions
Applicable human gates

Example: Implement Running → Paused in the lifecycle module without modifying input, audio, or game-specific scoring.

work_package_id: WP-LIFECYCLE-PAUSE-001
status: authorized
source_change: CHANGE-GAME-LIFECYCLE-001@0.4
owner: agent-gameplay-01
scope:
  allowed_paths:
    - platform/lifecycle/
    - tests/lifecycle/
  prohibited_paths:
    - platform/input/
    - platform/audio/
    - games/sock-rescue/scoring/
acceptance_criteria:
  - Pause before next simulation update
  - No simulation time while paused
  - Reject and log invalid transitions
validation:
  - host-unit-tests
  - target-board-test
stop_conditions:
  - approved interface must change
  - target timing cannot be met

04 · Lifecycle

Controlled progress, explicit rework

Blocked work remains valid but cannot proceed. Change Required means approved knowledge is incomplete, contradictory, or infeasible and must return through OpenSpec.

Authorized

Ready

Running

Validating

Blocked

Review

Integrated

Closed

Rework loop: Failed validation or requested changes return the package to Running. Specification conflict exits as Change Required.

05 · OpenSpec Apply

The controlled entry into delivery

Apply is not an unrestricted coding instruction. It turns an approved change into bounded, sequenced, assigned, independently validated work.

01–02

Load & confirm

Load approved change; confirm strategy and knowledge versions.

03–04

Decompose & sequence

Create work packages and construct the dependency graph.

05–06

Assign & bound

Choose workers; confirm authority and modification boundaries.

07–08

Execute & validate

Run eligible packages and prove each independently.

09–10

Integrate & learn

Integrate in dependency order; produce evidence and learning.

If decomposition exposes unresolved behavior, architectural ambiguity, or unaccepted assumptions, Apply stops and returns the issue to Knowledge.

06 · Orchestration

Codex coordinates; specialists execute

Every worker receives bounded responsibility. Agents may report infeasibility; they may not silently replace a requirement with something easier.

Execution core

Codex OrchestratorPlans, assigns, checkpoints, integrates, and maintains traceability.

Chief ArchitectReviews architecture and cross-system consequences.

Engine StewardProtects platform boundaries and reusable interfaces.

QA/Test EngineerDesigns validation and evaluates evidence.

Specialized delivery

Engineering AgentsGameplay, graphics, embedded, audio, tools, and integration.

Technical ArtistValidates assets and content-pipeline compliance.

Creative OwnerApproves experience, visual, and gameplay intent.

Product OwnerAccepts delivered behavior against product outcomes.

07 · Parallel delivery

Concurrency follows stable boundaries

Parallel work begins only after shared contracts are approved. No two agents modify the same unstable interface without an explicit coordination owner.

Lifecycle contract

Pause implementation

Pause overlay

Audio policy

System integration

Target-board validation

Implementation, overlay, and audio can proceed concurrently; integration waits for all three.

08 · Authority & stops

Agents execute and recommend. Humans approve.

Authority is explicit in each package, and any boundary conflict creates a structured exception record.

Execute

Implement within approved specification and boundaries.

Approve

Authorize changes to intent, risk, interface, or platform boundary.

Requirement is contradictory or materially ambiguous

Approved interface must change

Platform capability would become game-specific

Hardware invalidates an approved assumption

Acceptance criteria cannot be met

Work exceeds permitted paths or subsystems

Safety, privacy, licensing, or security concern appears

Required evidence or human gate is unavailable

09 · Resumability

Execution survives the agent session

Durable checkpoints let a different agent resume without reconstructing decisions from prior conversations.

A complete continuation contract

Each checkpoint records the current commit, status, completed and remaining work, findings, blockers, environment, next owner, and exact next action.

Workflow pause/resume is distinct from the game platform’s pause/resume capability.

checkpoint_id: CP-WP-LIFECYCLE-PAUSE-004
work_package: WP-LIFECYCLE-PAUSE-001
status: validating
repository_commit: 8f31c2a
completed:
  - state transition implemented
  - host unit tests passing
remaining:
  - target-board timing test
  - evidence package
next_action:
  owner: embedded-test-agent
  instruction: run HIL-LC-002
environment:
  toolchain: pico-sdk-2.x
  target: feather-rp2350-hstx

10 · Validation

A ladder of proof

Passing an earlier level never substitutes for a required later level. Evidence identifies the exact commit, specification, board, configuration, method, and result.

01Static checks

02Unit tests

03Component contracts

04Integration tests

05Host simulation

06Target hardware

07Human experience

08Release acceptance

Target-board authority for RP2350

Frame timingMemory useInput latencyAudio stabilityHDMI behaviorPeripheral compatibilityPower & thermalRepeated lifecycle transitions

11 · Discoveries

Execution learns without rewriting its own authority

Implementation findings are classified and routed to the correct system.

Implementation defect

Behavior fails an approved requirement.

Fix in package

Missing edge case

Material behavior was never specified.

Return to Knowledge

Incorrect assumption

Evidence contradicts accepted knowledge.

Knowledge delta

Interface limitation

Current boundary cannot support the behavior.

Architecture proposal

Hardware variance

Target behavior differs by condition or board.

Evidence & reassess

Reusable capability

Implementation has a demonstrated second consumer.

Platform promotion

Better technique

A repeatable delivery improvement emerges.

Learning / playbook

Strategic conflict

Execution no longer serves approved outcomes.

Strategy amendment

12 · Definition of done

Code complete is not change complete

A package closes only when outputs, proof, boundaries, reviews, handoff state, and learning are complete.

Work package complete

All required outputs exist

Acceptance criteria and required tests pass

Target-hardware validation passes where applicable

Evidence links to the specification and commit

No unauthorized paths or interfaces changed

Human reviews and documentation are complete

Change complete

Every package is integrated or explicitly waived

Change-level acceptance and regressions pass

Residual risks have named owners

Checkpoint and handoff state are complete

Knowledge and platform deltas are captured

Execution summary is reproducible

Release authorization

Execution Gate

Release and platform promotion remain blocked until the integrated change matches approved knowledge and its evidence is complete.

Executed change matches approved OpenSpec version

All packages closed or explicitly waived

Requirements link to implementation and evidence

Integration and regression tests pass

Target-hardware proof is complete

Platform and experiential reviews are complete

Exceptions and risks have named owners

Documentation and reusable playbooks updated

gate: execution-acceptance
decision: approved
authorized_next_stage:
  platform-and-learning-review
change: CHANGE-GAME-LIFECYCLE-001@0.4
implementation:
  commit: 8f31c2a
  build: rp2350-platform-0.5.0
validation:
  automated_tests: passed
  target_board_tests: passed
  pause_resume_cycles: 100
  unresolved_failures: 0
platform_review:
  decision: reusable
  promoted: [game-lifecycle-api]

13 · Reference case

RP2350 start, pause & resume

The approved lifecycle change becomes eight bounded packages, one integrated proof, and a reusable platform capability.

GameplayLifecycle state machineValidated states and transitions

EmbeddedInput-event mappingStable Start, Pause, Resume events

GraphicsPause presentationOverlay and paused rendering

AudioAudio-state handlingApproved lifecycle policy

QAState-integrity testsDeterministic comparisons

Embedded + QAHardware timingFrame and latency measurements

GameplayGame integrationSock Rescue adopts platform API

Engine StewardReuse harnessSecond independent consumer

Integrated acceptance proof

Ready → Running on Start
Pause before next simulation update
State unchanged while paused
Resume from same simulation boundary
No duplicated input
Approved audio behavior
Invalid transitions rejected and logged
100 cycles without corruption

Platform proof: lifecycle works through a test harness independent of Sock Rescue.

14 · Repository

Durable operational state in Git

Specifications remain in Knowledge; reusable runtime capabilities remain in Platform; Execution holds the traceable state that transforms one into the other.

Separate truth, work, and proof

Plans, assignments, checkpoints, exceptions, and summaries preserve delivery state. Validation stores the proof. Playbooks turn repeated execution patterns into reusable operating capability.

Next design step: define the work-package schema and orchestration policy.

execution/
├── plans/
├── work-packages/
│   ├── authorized/
│   ├── active/
│   └── completed/
├── dependencies/
├── assignments/
├── runs/run-manifests/
├── checkpoints/
├── exceptions/
├── integration/
├── summaries/
└── templates/

validation/
├── plans/
├── automated/
├── hardware-in-the-loop/
├── human-review/
└── evidence/

playbooks/
├── implement-component/
├── validate-on-target/
├── integrate-change/
├── resume-execution/
└── close-change/