The Authoritative Delivery Hierarchy
Preserve intent, authority, causality, evidence, and acceptance across every delivery record.
A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Jump to validation criteriaOpen the source exercise
Draw the complete hierarchy from memory. For every object, write one phrase for what it owns and one phrase for what it cannot authorize. Then trace these three paths:
- a normal change from Company to production verification;
- a failed validator result that creates corrective work and fresh Evidence;
- a material Plan or WorkOrder revision that invalidates prior authority.
The exercise fails if any lower-level status automatically accepts a parent or if evidence cannot be traced to an exact Attempt and artifact.
4. Tradeoffs and alternatives
The hierarchy creates more records and transitions than a task tracker. That is real cost. Small, low-risk work may feel slower when every concept becomes a form or approval. The correct response is not to collapse the model. It is to automate routine record creation, inherit safe defaults, and scale required human attention with risk.
Some systems may combine Task and WorkOrder when a unit is both operationally atomic and independently acceptable. That choice is safe only if the combined record still preserves authority, acceptance, revision, and evidence boundaries.
Attempt may also be called ExecutionRun. The name matters less than the invariant: each try is immutable and distinguishable from the logical Task.
Pull Request and Release may remain external system objects rather than copied records. The factory still needs durable references, exact versions, provider events, and its own governed interpretation of their state.
5. Current Mission Control Implementation
This assessment uses Mission Control commit
8014d5af427b43ff5c5a63cfdf82ec92742c208c,
studied on 2026-08-07.
| Concept | Current representation | Assessment |
|---|---|---|
| Company | tenants | Implemented as the multi-tenant boundary. Product language uses Company while the schema retains tenant. |
| Workspace | projects | Implemented with Company linkage, identity, repository compatibility fields, and policy defaults. Product language uses Workspace while the schema retains project. |
| Repository | workspaceRepositories | Implemented as a one-to-many Workspace relationship with GitHub identity, status, branch, webhook state, and policy overrides. |
| Factory Configuration | factoryDefinitions and immutable factoryDefinitionVersions | Implemented with configuration digests, workflow, executor, policy, environment, budget, verifiers, risk, recovery, readiness assessment, and controlled activation. |
| Mission | missions | Implemented with an explicit lifecycle, serial mutation policy, budget, corrective limits, stop condition, plan linkage, and human-attention fields. |
| Plan | missionPlans | Implemented as revisions containing assertions and WorkOrder blueprints. Submission, approval, rejection, and idempotent release are represented. |
| WorkOrder | workOrders plus governance tables | Implemented as the unit of desired outcome, risk, scope, acceptance, approval, revision, reopen, supersession, and audit. |
| Task | tasks and WorkOrder/task linkage | Present, with legacy and operational responsibilities still coexisting. The target model positions Task beneath WorkOrder. |
| Attempt | workflowRuns, runEvents, and runArtifacts | Implemented under the name ExecutionRun or WorkflowRun. The records retain version, runtime, isolation, steps, events, artifacts, and failure detail. |
| Evidence | validationAssertions and verificationReceipts | Implemented with criterion status, verifier run linkage, methods, artifacts, validity, waiver, and invalidation. |
| Pull Request | harnessPrChecks, GitHub webhook records, run artifacts, and related commands | Implemented across integration and evaluation records rather than one canonical pullRequests table. Head-SHA-specific evidence and merge data exist. |
| Release | deployment and release-gate records | Partial for the software-delivery hierarchy. Deployment governance exists, but the complete Mission-to-production-value path remains a V1 target. |
Mission Control's current naming reveals an important migration reality. Product
terms and schema terms do not always match. Company maps to tenant, Workspace
maps to project, and Attempt maps most closely to workflowRun. The guide uses
the conceptual vocabulary while citing the implementation vocabulary explicitly.
The current schema includes many required records, but schema presence is not proof of one coherent product journey. A complete browser-operated demonstration must still show that the records are created through supported paths, governed server-side, recoverable, and understandable to an operator.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence