Human authority model · RP2350 platform

Human Checkpoints as State-Transition Controls

Humans contribute intent, authority, qualitative judgment, specialized expertise, and ownership of risk. Agents prepare the decision; an authorized person advances an exact artifact, version, build, or operating state.

Status · ExplorationVersion · 0.1Example · Sock RescuePlatform · Feather RP2350 HSTXUpdated · August 7, 2026

Prepare evidence

Agents assemble a decision-ready package.

Ask precisely

One authority receives one consequential question.

Decide

Approve, condition, reject, or refine.

Advance selectively

Only affected work changes state.

Preserve authority

Record scope, conditions, expiry, and invalidation.

01 · Operating idea

A checkpoint is not a generic review moment

It is a durable authorization contract that controls a specific state transition. Routine execution remains autonomous; consequential decisions remain human-governed.

Agents prepare. Humans decide.

The agent gathers evidence, separates facts from assumptions, frames alternatives, recommends a path, and identifies exactly what is blocked.

The human supplies a form of legitimacy the agent cannot claim for itself: intent, experience judgment, platform commitment, risk ownership, or release authority.

Exact subject — artifact, version, commit, build, or state.

Exact authority — the role permitted to decide.

Exact decision — options and consequences.

Exact effect — work authorized, blocked, or allowed to continue.

Exact validity — conditions, expiry, and invalidating changes.

A human checkpoint authorizes an exact artifact, version, build, or operating state to advance under stated conditions.

02 · Three types

Use checkpoints only where human contribution is legitimate

The trigger determines whether the checkpoint is a mandatory gate, a qualitative judgment, or an exception raised by execution.

Mandatory

State cannot advance

Human authorization is structurally required.

Project charter
OpenSpec proposal
Public interface change
Platform promotion
Risk acceptance
Release authorization

Judgment

Evidence is not enough

A person must assess quality, coherence, fairness, or experience.

Pause feels immediate
Golden sock feels exciting
Dog is expressive and readable
Audio response is satisfying
Game feels fair

Exception

Execution crosses authority

A new condition invalidates the current path or requires a consequential choice.

Hardware contradicts spec
Public API must change
Memory exceeds budget
Requirements conflict
Asset unavailable
Correct build feels wrong

03 · Anatomy

Nine fields make a checkpoint decision-ready

The request reconstructs context for the authorized person and makes the downstream effect deterministic for the Orchestrator.

1Trigger

Why the checkpoint exists now.

2Subject

Exact artifact, version, commit, or build.

3Authority

Role authorized to decide.

4Question

Decision in outcome language.

5Evidence

Facts required for a sound choice.

6Options

Valid choices and consequences.

7Recommendation

Agent-prepared preferred path.

8Blocking scope

What waits—and what may continue.

9Invalidation

What would make the decision obsolete.

Too vague

“Please review this.”

Decision-ready

“Approve lifecycle specification 0.4 for implementation, reject it, or return it for refinement. Approval does not authorize changes to the public lifecycle API.”

04 · Authority map

Every checkpoint has a distinct human contribution

The owner is selected by the authority required—not by availability or seniority alone.

Checkpoint	Human contribution	Owner	Durable result
Vision	Intent and priorities	Product sponsor	Authorized charter
Specification	Behavioral authority	Product owner	Approved OpenSpec
Architecture	Technical judgment	Chief Architect	Approved system boundary
Platform	Long-term support commitment	Engine Steward	Promoted capability
Creative	Qualitative direction	Creative owner	Approved design package
Hardware	Physical expertise and observation	Embedded owner	Validated assumptions
Experience	Direct human judgment	Product owner / playtest lead	Accepted experience
Risk	Ownership of residual exposure	Designated risk owner	Accepted or rejected exception
Release	Distribution authority	Release owner	Authorized release
Learning	Judgment about generalization	Governance owner	Updated standard or playbook

05 · End-to-end path

The RP2350 checkpoint sequence

Mandatory, conditional, and judgment gates appear exactly where the system needs a human contribution; implementation runs between them.

Vision authorization

OpenSpec approval

Architecture boundary

Bounded implementation

Creative approval

Target validation

Experience acceptance

Risk decision

Platform promotion

Release authorization

Learning adoption

06 · Examples 1–4

From product intent to an integration-ready package

Each checkpoint authorizes a precise next state and explicitly names what it does not authorize.

Vision authorization

Should Sock Rescue proceed as a reusable RP2350 platform demonstration rather than a one-off game?

Owner: Product sponsor
Evidence: Experience outcome, audience, MVP boundary, reusable opportunities, complexity, game-only alternative.
Choices: Platform-first · Game-only MVP · More evidence · Stop.
Produces: Authorized charter and constraints.

OpenSpec approval

Does lifecycle specification 0.4 define Start, Pause, and Resume precisely enough to implement?

Owners: Product Owner + Chief Architect.
Evidence: Transitions, state preservation, input/audio/visual behavior, acceptance criteria, ambiguity and version delta.
Effect: Authorizes work-package creation; not platform promotion or release.
Invalidation: A later spec changes Pause semantics.

Architecture boundary

How should the platform distinguish initial Start from Resume?

Trigger: Current public lifecycle API cannot express approved behavior.
Owners: Chief Architect, Engine Steward, Product Owner.
Options: Internal tracking · Add resume() · Revise requirement.
While waiting: Test-fixture preparation may continue.

Creative package approval

Is the Sock Rescue MVP visual package coherent, readable, expressive, and integration-ready?

Owner: Creative owner.
Evidence: Dog animations, socks, golden sock, pause overlay, score/combo, palette, HDMI screenshots, on-device preview, memory.
Judgment: Intent, contrast, delight, personality, target-distance legibility.
Example: Approve with golden-sock contrast and overlay-opacity conditions.

Specification approval record

The response binds product and architecture authority to one exact specification.

Conditions are explicit
Authorized work is bounded
Non-authorized transitions are named
A material spec revision invalidates approval

checkpoint_response:
  checkpoint: CP-SPEC-004
  subject:
    change: CHANGE-GAME-LIFECYCLE-001
    specification_version: 0.4
  product_decision: approve
  architecture_decision: approve-with-conditions
  conditions:
    - do not change the public lifecycle API
    - scoring state immutable while paused
    - resume from preserved frame state
  authorizes:
    - implementation planning
    - bounded work packages
  does_not_authorize:
    - platform promotion
    - release

07 · Examples 5–6

Physical evidence and human experience are different gates

Target validation establishes facts about the build and hardware. Experience acceptance determines whether the technically correct result feels right.

Target-hardware validation

Does the exact candidate behave reliably on the Feather RP2350 HSTX hardware profile?

Confirm board revision and stable HDMI
Observe controller response and audio sync
Measure power, memory, frame rate, and latency
Repeat after reboot and endurance run

Measure	Target	Result
Input → visible	≤ 50 ms	41 ms
Pause audio	≤ 20 ms	27 ms
Static RAM	≤ 480 KB	438 KB
Frame rate	60 fps	59.8 fps
30-minute run	No failure	Pass

Experience acceptance

Does the exact build feel clear, immediate, fair, and coherent when people play it?

Start a gameCatch 3 socksPause in motionWait 5 secondsResumeMeet golden sock

Did the game feel frozen rather than interrupted?
Did Resume preserve spatial and mental context?
Was the golden sock exciting or distracting?
Did losing the combo feel understandable and fair?

Example outcome: technical behavior accepted; combo-loss feedback returned for refinement.

Experience review

Technical success is not yet product acceptance. The review blocks only the states that depend on the rejected experience.

Five participants
Exact candidate build
Unbiased test protocol
Finding-level decisions
Independent work identified

experience_review:
  checkpoint: CP-EXPERIENCE-009
  build: rp2350-sock-rescue-0.5.0-rc2
  participants: 5
  findings:
    pause_clarity: accepted
    state_preservation: accepted
    resume_response: accepted
    golden_sock_readability: accepted
    combo_loss_feedback: rejected
  decision: return-for-refinement
  blocked: [product-acceptance, release]
  may_continue: [release-notes, endurance-test]

08 · Examples 7–8

Risk acceptance and platform promotion create obligations

One assigns ownership to a deviation. The other turns working code into a long-lived compatibility and maintenance commitment.

Risk acceptance

Accept 27 ms audio pause latency for MVP, delay release for optimization, or remove pause audio?

Correct now

Protect the target; add an implementation cycle.

Approve exception

Preserve schedule; track residual risk.

Remove audio

Meet latency by changing experience.

Bind to the measured build
Name owner, conditions, and expiry
Do not promote exception as platform standard
Invalidate when latency or audio architecture changes

Platform promotion

Should Start/Pause/Resume become a supported reusable RP2350 platform capability?

Owner: Engine Steward.
Evidence: Stable contract, conformance tests, resource cost, docs, reference implementation, second consumer, upgrade/deprecation plan, named owner.
Outcomes: Stable · Experimental · Game-private · More consumers · Reject abstraction.
Meaning: A maintenance commitment—not merely code sharing.

Bounded risk exception

The risk owner accepts a known deviation for one precise scope and timeframe.

Exact measurement preserved
Release note required
Platform precedent prohibited
Re-measurement scheduled
Invalidation conditions explicit

risk_acceptance:
  checkpoint: CP-RISK-AUDIO-003
  decision: approve-exception
  build: rp2350-sock-rescue-0.5.0-rc2
  accepted_measurement:
    audio_pause_latency_ms: 27
  conditions:
    - document in release notes
    - do not promote as platform standard
    - repeat for release 0.6.0
  expires: 0.6.0
  invalidated_by:
    - latency above 27 ms
    - audio architecture change
    - candidate change affecting audio

09 · Examples 9–10

Authorize release; then deliberately adopt learning

The release gate binds prior decisions to an exact candidate. Post-release learning becomes a standard only through explicit governance.

Release authorization

May this exact firmware artifact be distributed to its intended target?

Bind version, commit, digest, and hardware profile
Confirm spec, tests, target, experience, budgets, rollback
Reference every valid exception
Collect product, technical, and release approvals
Re-evaluate if the artifact digest changes

Learning adoption

Players use Start to resume. Is this education, game interaction, platform convention, controller labeling, or a new design standard?

Owner: Governance owner.
Evidence: Observed behavior across participants, builds, games, and controller contexts.
Example: Same control pauses and resumes by default unless a game has an approved exception.
Why human: The choice changes future specifications and agent behavior.

Exact-candidate release

“Basically the same build” is not a controlled release state. Every approval points to one immutable candidate identity.

All evidence matches the candidate
Every exception remains valid
Three authorities sign
Rebuilds trigger re-evaluation

release_checkpoint:
  checkpoint: CP-RELEASE-012
  candidate:
    version: 0.5.0
    commit: 6e08a4c
    artifact_digest: sha256:abc123
    hardware: feather-rp2350-hstx-rev-b-non-psram
  evidence:
    specification: satisfied
    automated_tests: pass
    target_validation: pass
    experience_review: accepted
    rollback_plan: ready
  approved_exceptions: [EXC-AUDIO-003]
  decisions:
    product_owner: approve
    technical_owner: approve
    release_owner: approve
  result: authorized-for-release

10 · Selective blocking

A checkpoint should block only what depends on its decision

The Orchestrator traces the affected dependency boundary so safe, independent work continues without bypassing human authority.

Examples of blocked work

Creative decision → affected asset integration
API decision → producers and consumers of that interface
Hardware discrepancy → target acceptance
Risk decision → affected release
Strategic conflict → all downstream work

Examples of work that may continue

Lifecycle unit tests while art is reviewed
Test-fixture preparation while API is decided
Documentation while target validation is blocked
Endurance testing while experience feedback is refined
Game release with private code while platform promotion waits

11 · State model

Use explicit states the Orchestrator can interpret

“Reviewed” is not sufficient: it does not say what was authorized, whether conditions apply, or whether the decision is still valid.

not-requiredanticipatedpreparing-evidenceready-for-decisionawaiting-authorityapprovedapproved-with-conditionsrejectedreturned-for-refinementexpiredinvalidatedsupersededwithdrawn

12 · Design principles

Optimize human attention for decisions—not supervision

A well-designed checkpoint is precise enough for the person to judge quickly and for the system to act correctly afterward.

Route to the authorized role.

Identify exact version or build.

Show material delta since approval.

Recommend with alternatives.

Separate facts and judgment.

Name the blocking scope.

Continue independent work.

Record conditions and expiry.

Define invalidating changes.

Preserve a durable artifact.

13 · Implement first

Start with five mandatory checkpoint contracts

These establish product intent, implementation authority, human experience quality, platform commitments, and exact-candidate release control. Conditional architecture, creative, hardware, and risk checkpoints can then plug into the same contract.

01Charter Authorization

Approve the outcome, investment boundary, and constraints.

02OpenSpec Approval

Authorize precise behavior for bounded implementation.

03Experience Acceptance

Confirm that the exact build feels right to humans.

04Platform Promotion

Accept reusable compatibility and maintenance obligations.

05Release Authorization

Permit distribution of one evidence-bound candidate.

Humans spend attention defining intent, making consequential judgments, accepting risk, and authorizing state transitions—not reconstructing context or supervising routine execution.