By the end of this guide, an operator can read one Project, execute an action against its expected revision, and verify the persisted evidence and review state.
Mission Control state model
- A Project is the authority boundary for coordinated work.
- A work item records one intended result and its completion contract.
- An attempt records execution toward that item, including linked runs.
- Evidence freezes the change, validation, and required conditional proof used for review.
- Review admits evidence and records requested changes.
- Acceptance is the authorized final decision for the reviewed item.
Conversation text may explain this state, but it is not the authoritative project record.
Choose the owning authority
| Question | Owning surface |
|---|---|
| What work exists and what evidence supports it? | Mission Control Project |
| What is this run doing or waiting for? | Runtime operator control |
| May this evidence be reviewed or accepted? | Mission Control review authority |
| How is old project state imported? | Migration tooling |
Inspect a Project
Send mission_control.project.get through the authenticated runner control boundary:
{
"command": "mission_control.project.get",
"projectId": "11111111-1111-4111-8111-111111111111"
}The mission_control.project response includes the current revision and canonical Project document. Validate it before rendering. Present work items, attempts, linked runs, evidence, review, and acceptance as separate concepts.
Execute an action
All writes use mission_control.action.execute with the Project, action identity, expected revision, and typed action payload:
{
"id": "cmd-create-release-work-item",
"type": "mission_control.action.execute",
"payload": {
"action": {
"type": "item.create",
"projectId": "11111111-1111-4111-8111-111111111111",
"actionId": "22222222-2222-4222-8222-222222222222",
"actionTs": "2026-08-04T16:00:00.000Z",
"expectedRevision": 3,
"itemId": "33333333-3333-4333-8333-333333333333",
"title": "Verify the 0.8 package release",
"instructions": "Run every packed-package gate and record immutable evidence.",
"createdBy": "operator",
"order": 4
}
}
}Use the action contract from the exact 0.8 source and send it through the matching Protocol command envelope. Revision conflicts require a fresh read and an intentional retry; action identifiers make safe duplicate delivery observable.
Review and accept
Admission freezes the candidate, completion contract, change evidence, validation results, conditional proof, and linked runs. The authorized reviewer may then accept or request changes. Acceptance never follows from a status label alone.
Recover an attempt
Runtime recovery owns interrupted or blocked execution. Select the exact recovery option on the pending request, resume the same work, and let Mission Control record the resulting attempt/run evidence. Do not repair a run by directly editing the Project document.
Migrate legacy state
The 0.8 migration boundary may read older project records and bind them to a Mission Control Project. Current clients have no legacy write API. Keep legacy names in migration evidence only and do not create a side store that competes with Mission Control.
SDK and HTTP examples
At the HTTP boundary, send only the two protocol commands shown above through an authenticated, server-owned control route. In the SDK, use the exact 0.8 Mission Control command payload and response types; do not call project-snapshot update helpers removed by the 0.8 package line. Resolve actor, Project access, and review authority before dispatch.
Persist and replay
The Project store persists canonical state, idempotent action receipts, revision history, and external-effect outbox records. Replay restores that authoritative sequence. Transcripts and local UI caches are projections and must not become alternate write authorities.
Continue with operator control
Use Operator control workflows for active runs, Recovery for pending decisions, and Migrations for imported state.