Mission Control Capability, Workflow, and Admission Map
Evidence boundary: this assessment uses the tracked Mission Control files at checked out commit d902fae . The checkout was detached from a branch, and its local origin/main ref pointed to 4700573 . Untracked review artifacts were excluded.
A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Open the source exercise
Draw the five planes and the full delivery spine. Add the production admission chain as a precondition to Attempt claim. For every transition, name the actor, authoritative record, digest or version, hard policy check, emitted evidence, failure state, recovery path, and human-only authority. Circle every place where telemetry could be mistaken for evidence or registration for promotion.
3. The enduring principle
Map every builder outcome to an authoritative contract
The one-line value stream is:
Intent → Plan → Define Agent → Execute through Harness → Apply Skills → Evaluate → Improve → Deliver Software
The durable contract spine behind it is:
Builder Intent
→ Mission Spec revision
→ approved Plan version + Quality Contract
→ WorkOrder revision
→ Task
→ Factory Version + Agent/Skill bindings
→ frozen Execution Manifest
→ Attempt + Completion Report
→ immutable Candidate
→ independent Verification Run + Evidence
→ Quality Gate Decision
→ Publication Permit + Pull Request
→ Human Acceptance
→ Release + Production Outcome
→ Learning Signal + governed Improvement Candidate
Names can vary. The principle is that intent, authority, execution, evidence, decision, delivery, outcome, and learning remain independently attributable.
Use five cooperating planes
| Plane | Owns | Must not claim |
|---|---|---|
| Builder experience | Intent capture, plan review, exception triage, evidence review, and consequential decisions | Runtime or policy authority hidden in a client |
| Control plane | Identity, versions, policy, admission, lifecycle state, approvals, and audit | That execution succeeded merely because it was dispatched |
| Execution plane | Harness, model calls, tools, sandbox, repository mutation, checkpoints, and completion reports | Verification, publication, acceptance, or merge authority |
| Assurance and delivery plane | Independent evaluation, currentness, evidence, gates, publication, release, and production verification | That telemetry or a worker assertion is proof |
| Learning plane | Outcome signals, failure clusters, datasets, experiments, and improvement proposals | Silent mutation or promotion of active configuration |
Treat admission as a chain, not a boolean
Execution is eligible only when the exact combination of intent, repository, workflow, agent, model route, harness, sandbox, worker, policy, budget, and environment is current and permitted. Cost or historical quality may rank eligible candidates; it must never compensate for a failed hard constraint.
Preserve authorized action parity
Every builder outcome supported by a product surface should have a governed API or tool path that reaches the same authoritative state. Parity concerns outcomes, not a one-to-one mapping of buttons to tools. It also does not mean an agent inherits every human permission: identity, scope, approval, and evidence requirements still apply.
8. Notes and lessons learned
- The most production-minded result in the current admission work is the refusal to create plausible-looking production evidence when prerequisites are absent.
- Exact model and harness identity matters because a provider/model name alone does not describe the executable, adapter configuration, sandbox, or effective capabilities that produced an artifact.
- Skills are part of the factory configuration only when exact evaluated versions are bound to the Attempt; a registry by itself is not runtime proof.
- MCP standardizes an interoperability surface. It does not replace product authorization, tenant isolation, tool policy, evidence, or acceptance.
- Capability parity must be combined with authority parity. A shadow agent API that bypasses the UI's controls is not parity; it is a second control plane.
- Telemetry explains a run. Evidence supports or refutes a criterion. The same artifact may contribute to both only when its producer, subject, method, provenance, and policy meaning are explicit.
9. Interview and discussion questions
- Why is an exact model route more than a provider and model name?
- Which admission checks are hard constraints, and which signals may influence ranking after eligibility?
- Why can a locally qualified implementation remain legitimately blocked in production?
- What would prove that Skills are bound rather than merely discoverable?
- How does authorized action parity differ from giving an agent human powers?
- Why is an MCP Task not a substitute for a WorkOrder, Task, or Attempt?
- Which records must be reconciled after an ambiguous GitHub or sandbox side effect?
- What evidence would justify enabling Guarded Auto for one risk class?
Curriculum maturity is not implementation proof.
This case study records scoped implementation claims. Inspect the exact evidence, commit references, gaps, and verification boundaries in the source below.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence