Mission Control Implementation Maturity and Evidence Map
Historical assessment: this map captures the repository states listed below. For the verification architecture at merged commit ff0524e , continue with the Verification First Software Factory case study. For the current checkout at d902fae
Historical assessment: this map captures the repository states listed below. For the verification architecture at merged commit
ff0524e, continue with the Verification-First Software Factory case study. For the current checkout atd902fae, use the Capability, Workflow, and Admission Map.
Purpose
This case study prevents the mastery guide from confusing four different evidence states:
- merged capability on GitHub
main; - committed and tested capability on an open branch;
- live or browser evidence with a known limitation; and
- uncommitted proposal or future vision.
It is a point-in-time assessment, not product documentation.
Source boundaries
| Source | State on 2026-08-11 | Permitted claim |
|---|---|---|
b31e275 on GitHub main | Merged | Current committed baseline |
9d5f8e3 on codex/sandbox | Open draft PR #64 | Tested branch implementation, not main |
PR #61 at commit 2fd0a5a | Open, all checks passing | One real GitHub App publication proof |
| Original mastery Golden Path 01 | Partial run against dirty 8014d5a worktree | Control-plane behavior and blockers only |
| Three remote-sandbox documents | Uncommitted local files | Design and blocked provider evidence only |
Capability map
| Capability | GitHub-main status | Newer evidence | Remaining boundary |
|---|---|---|---|
| Governed Mission and versioned Plan | Implemented | Browser control-plane path retained | Complete clean browser rerun |
| WorkOrder, Task, and Attempt hierarchy | Implemented | Stronger revision-bound Task authority on PR #64 | Merge and browser proof |
| Independent validation and evidence | Implemented mechanisms | Phase 0 canary independently verified before acceptance | Complete review package across real PR path |
| Factory Configuration and readiness | Implemented baseline | Agent bindings, code scopes, workflow contract, and manifest on PR #64 | Merge, policy/configuration for lab repo |
| Policy and risk approval | Partial but material | Active policy used for live PR proof | Canonical fail-closed policy across every tool boundary |
| Durable lease and heartbeat | Not on main | Implemented and tested on PR #64 | Merge and full late-event/cancel browser matrix |
| Real Codex-to-GitHub PR | Not on main | PR #61 proves one real bot-authored review-ready PR | Browser Mission path required direct mutations |
| Exact execution manifest | Not on main | Implemented and tested on PR #64 | Merge and retained end-to-end evidence |
| Structured workflow handoff | Partial | Six workflows hardened on PR #64 | Merge and representative real execution |
| GitHub App boundary | Connection contract on main | Real token, push, PR, and passing CI proof | Webhook evidence-ingestion defects and lab setup |
| Model routing | Implemented platform mechanisms | Operational thresholds documented | Outcome-normalized ranking and automatic canary control |
| Loop/Graph Engineering | Implemented bounded slices | Browser failure containment and human gate evidence | Live agent deliverables and complete evidence ingestion |
| Governed continuous learning | Substrate exists | Phase 0 operational canary passed on PR #64 | Scheduler off; source registry and ingestion not built |
| Release and production outcome | Partial records and policy | None establishes customer-value completion | Deployment reconciliation and production outcome loop |
| Remote sandbox | Not implemented | Local design and blocked provider doctor only | Capacity, lifecycle canaries, privilege, egress, and teardown proof |
| Trust Score and autonomy calibration | Doctrine | No canonical product proof | Outcome model, demotion, quarantine, and human promotion workflow |
What changed since the original golden-path assessment
The original 2026-08-08 run correctly reported no Task, Attempt, Evidence, or PR. Since then, PR #64 implemented much of todo 024’s deterministic runtime, and the local work log records a real GitHub App PR with exact lineage and passing checks. That is meaningful progress.
It does not retroactively make the original lab pass. The real recovery used direct control-plane mutations because the browser Mission path could not start the released Plan, preserve the implementation policy, or reconcile the receipt into the assertion. The accepted mastery lab still requires a clean, browser-initiated run through the supported path.
Documentation gaps closed by this review
This review added dedicated mastery chapters for:
- Factory Configuration, workflow contracts, and execution manifests;
- sandbox isolation and publication boundaries;
- model routing, evaluations, and capability selection;
- release, production feedback, and Factory SRE; and
- governed continuous learning and recursive improvement.
The source material was synthesized into enduring principles and versioned case study findings. Mission Control product documentation was not copied.
Recommended next evidence sequence
- Review and merge PR #64 or establish a different clean pinned baseline.
- Repair the browser Mission path and GitHub webhook evidence reconciliation.
- Configure the controlled
mission-control-factory-labrepository with the exact GitHub App, active Governance Policy, and passing Factory version. - Rerun Golden Path 01 from its pinned target baseline without direct database or script mutations.
- Retain Task, Attempt, lease, manifest, commit, PR, receipt, failure, recovery, and review-package evidence.
- Only then extend the proof into deployment and production outcome.
Review questions
- Which claims are safe to state in present tense?
- Which tests prove a mechanism but not an end-to-end capability?
- Why does PR #61 not satisfy the browser-only lab?
- What evidence would promote remote sandboxing from proposal to Preview?
- Which current mastery chapters must be reverified after PR #64 changes?
Versioned references
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