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, use the Capability, Workflow, and Admission Map.

Purpose

This case study prevents the mastery guide from confusing four different evidence states:

1. merged capability on GitHub main;
2. committed and tested capability on an open branch;
3. live or browser evidence with a known limitation; and
4. uncommitted proposal or future vision.

It is a point-in-time assessment, not product documentation.

Source boundaries

Capability map

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

1. Review and merge PR #64 or establish a different clean pinned baseline.
2. Repair the browser Mission path and GitHub webhook evidence reconciliation.
3. Configure the controlled mission-control-factory-lab repository with the exact GitHub App, active Governance Policy, and passing Factory version.
4. Rerun Golden Path 01 from its pinned target baseline without direct database or script mutations.
5. Retain Task, Attempt, lease, manifest, commit, PR, receipt, failure, recovery, and review-package evidence.
6. Only then extend the proof into deployment and production outcome.

Review questions

1. Which claims are safe to state in present tense?
2. Which tests prove a mechanism but not an end-to-end capability?
3. Why does PR #61 not satisfy the browser-only lab?
4. What evidence would promote remote sandboxing from proposal to Preview?
5. Which current mastery chapters must be reverified after PR #64 changes?

Status at af414acf

Added 2026-09-02 from the public README at commit af414acf (2026-08-31). The assessment above is left as written at b31e275; this section records where the project stood twenty days later, in the project's own words, so the two can be compared.

The README's honest current claim: Mission Control is a strong, human-governed production-pilot architecture with a qualified delivery kernel; it is not yet a fleet-scale autonomous software factory or a generally certified Remote Sandbox platform. Status is active V1 development; public client/backend runtime contract v34.

Proven, per the README. A browser-operated path from Mission and approved Plan through WorkOrder, Task, Attempt, evidence, pull request, and human acceptance; real GitHub App pull requests with exact repository, branch, commit, changed-file, check, Attempt, and Mission lineage; immutable cancellation, failure, retry, and recovery history; process restart and browser refresh without lost terminal state or duplicate pull requests; independent verification and exact-current evidence before acceptance; a deterministic V3 qualification of 15 accepted controlled workloads across bug fixes, features, refactors, security/policy changes, and migrations; seventeen deliberate failure injections that failed closed; a bounded 3/3 live Remote Sandbox cohort with Attempt-scoped credentials and verified cleanup. Several rows of the capability map above ("Durable lease and heartbeat: not on main", "Real Codex-to-GitHub PR: not on main", "Remote sandbox: not implemented") are therefore superseded.

Limitations, per the README. Real product pilot pending (V3 used disposable workload repositories; the real GitHub path was deliberately narrow). Remote Sandbox is production-pilot eligible and Preview, with egress not yet provider-enforced and an ephemeral Codex installation. Guarded Auto is disabled. Merge and deployment remain human decisions. Cost attribution is incomplete. Tool and MCP authority is incomplete, with the next proof named as one default-deny, read-only internal integration rather than a connector catalog. Incident response is fragmented. Enterprise tenancy is not fully qualified. Adoption is not production-proven.

Canonical source. The Capability Maturity Ledger is the authoritative record of each capability's status, evidence, limitation, owner, and next promotion gate. Architecture documents define intended contracts; plans describe proposed or historical work; evidence packages prove behavior at an exact revision; where a status claim disagrees, current source and retained evidence win and the ledger is corrected. This case study, including this section, is subordinate to it. The narrative treatment is in Chapter 42.

Versioned references

• Mission Control README at af414acf
• Mission Control main baseline
• Mission Control study commit
• Draft PR #64
• Real publication proof PR #61
• Original Golden Path 01 assessment