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. The implementation passed its retained local qualification, but the production admission packet remained BLOCKED_BY_OPERATOR_CONFIGURATION. Therefore, this chapter distinguishes implemented mechanisms, qualified local composition, configured production capability, and live operational proof.

1. The problem

A mature agentic software factory contains more than an agent loop. It contains builder interfaces, specifications, plans, agent and skill versions, model routes, harnesses, sandboxes, durable state, policy, independent verification, publication controls, release records, production outcomes, and learning.

Without a capability and workflow map, several unsafe substitutions become easy:

• a route or screen is mistaken for an operable product capability;
• a passing unit test is mistaken for end-to-end system proof;
• a registered model or sandbox is mistaken for an admitted execution path;
• a worker completion message is mistaken for independent acceptance evidence;
• telemetry is mistaken for proof;
• a proposal from the learning system is mistaken for an approved change; or
• a protocol task is mistaken for the factory's governed Task record.

The purpose of this case study is to connect the factory's memorable lifecycle to Mission Control's current records, code paths, workflows, and evidence while preserving those distinctions.

2. Why the problem exists

Mission Control is a large, evolving repository. It contains active product doctrine, accepted decisions, current code, retained evidence, historical documents, previews, demos, plans, and legacy product surfaces. Those sources answer different questions.

The implementation also separates configuration from authority. A model route can exist but remain disabled. A Sandbox Profile can be qualified but not promoted. A Factory Version can be created but not ready. A worker can be alive but unable to attest the exact version. An Attempt can produce a candidate but cannot verify or publish it. A verified candidate can be review-ready without being accepted, merged, deployed, or proven valuable in production.

This is intentional. Production reliability comes from preserving the chain of claims rather than compressing it into a convenient DONE label.

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

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.

4. Tradeoffs and alternatives

Exact versioning and digest binding make runs reproducible and auditable, but increase configuration work and make drift fail closed. A lighter system could move faster for low-risk experiments, but it should label that lower assurance instead of implying equivalent production readiness.

Atomic tools improve composability and emergent problem solving. Domain tools reduce calls and variance for repeated workflows. Keep policy enforcement, credential boundaries, exact schemas, and irreversible actions deterministic; let the agent apply judgment within those boundaries.

A single authoritative control plane improves consistency but may add latency and create a critical dependency. Durable local checkpoints and reconciliation help execution survive temporary control-plane or provider ambiguity without allowing a worker to invent authoritative state.

Action parity increases product usefulness and test surface. Some actions must remain human-only, including identity bootstrap, approval of consequential authority, risk acceptance, merge, and other irreversible decisions. Marking an action human-only is clearer than leaving an accidental capability gap.

5. Current Mission Control implementation

Repository and authority model

At the studied commit, Mission Control is a TypeScript and pnpm monorepo. The React/Vite application provides operator surfaces, Convex owns authoritative durable state and server-side transitions, and the Hono orchestration service hosts execution adapters and provider boundaries. Current product doctrine prioritizes an exception-first operator experience over agent activity feeds.

The repository's Software Factory documentation defines an authority order: product doctrine, accepted decisions, normative contracts, current implementation guides, plans, validation evidence, and historical material. This case study follows that order and uses code and retained evidence to bound present-tense claims.

Lifecycle map

Capability map

Workflow 1: governed intent to review-ready change

The important property is negative authority: Plan approval does not dispatch; the harness does not verify; verification does not publish; publication does not merge; and merge does not prove the production outcome.

Workflow 2: production execution admission

The admission packet records the following operator sequence:

Canonical GitHub App installation
  → current structured workflow registration
  → exact model-route registration
  → human evidence-based route promotion
  → immutable hardened Sandbox Profile creation
  → human profile promotion
  → code scopes + agents + policy + verifiers
  → exact Factory Version creation
  → exact worker/Factory Version attestation
  → readiness assessment and activation
  → human-selected local then remote canary
  → independent verification
  → controlled publication canary

Registration never counts as qualification. Promotion grants execution-only eligibility, not routing, verification, publication, acceptance, merge, or deployment authority. Worker admission compares exact repository, Factory Version, configuration digest, harness manifest, effective configuration, model route, backend, and Sandbox Profile identity.

The local implementation qualification passed 17 composed gates. The retained production observation still found zero GitHub App installations, exact routes, promoted Sandbox Profiles, current production workflows, Factory Versions, workers, and Attempts. No production mutation or canary was fabricated. This is a strong example of honest blocking: qualified code is not the same as an operationally configured factory.

Workflow 3: failure, recovery, and reconciliation

Detect failure
  → classify policy / capability / environment / provider / execution / result
  → contain authority and preserve events
  → retry only a permitted failure class within Attempt and wall-clock budgets
  → create attributable new Attempt or reconcile ambiguous external effects
  → quarantine, drain, kill, or escalate when safe continuation is unavailable
  → independently re-evaluate the new exact candidate

The workflow contract rejects heuristic STATUS: done completion and requires structured status for non-gate steps. Historical runs are projected read-only as current, legacy-but-valid, malformed, incomplete, stale-schema, or genuinely invalid. Compatibility logic does not rewrite history or invent a terminal outcome.

Workflow 4: governed learning

Attempt, verification, review, and production observations
  → deterministic Learning Signals
  → bounded failure or opportunity clusters
  → human-reviewable Improvement Candidate
  → frozen baseline/candidate experiment
  → reviewed result
  → submitted Mission Plan
  → separate human Plan approval
  → ordinary WorkOrder and execution lifecycle

This is the practical meaning of: Learning can be autonomous. Promotion should be governed. The learning subsystem is prohibited from accepting, publishing, merging, changing an active Factory Version, or granting itself new authority.

Workflow 5: authorized action parity

Mission Control contains slice-level capability maps, including Graph Engineering mappings between UI actions, Convex capabilities, and shared state. The reusable factory workflow is:

1. inventory each meaningful builder action and the state it changes;
2. map it to an authenticated API or tool outcome, or mark it human-only;
3. require UI and agent paths to use the same authoritative transition;
4. apply the same policy, scope, idempotency, and audit rules;
5. surface the result and receipt immediately to the operator; and
6. test the resulting state, not merely the selected tool call.

A repository-wide parity map and drift check would make this discipline continuous rather than case-study-specific.

6. Future vision

Mission Control should promote the following only after retained evidence meets the same bar as its existing governed path:

• a repository-wide builder-action-to-agent-capability map with CI drift checks;
• exact skill IDs, versions, digests, dependencies, and evaluation status in every relevant execution manifest;
• a governed MCP gateway with explicit client/server identity, capability discovery, per-tool authorization, consent, rate limits, audit, and result provenance;
• a legitimate production configuration and bounded local/remote canary;
• outcome-normalized routing evidence before enabling Guarded Auto;
• one browser-originated Mission-to-reviewed-PR path without direct data mutation or operational bypass;
• retained post-merge deployment, activation, rollback, and production-outcome evidence; and
• measured adoption across teams before making fleet-scale claims.

Evidence required to move these into current capability includes exact commits, server-side authorization tests, retained runtime and browser artifacts, failure/recovery drills, refresh/restart durability, cross-tenant negative tests, and an operator-readable decision package.

7. Versioned references

Mission Control sources at studied commit d902fae7032c0696b531c44ae88829c652516fc6:

• Mission Control README
• Mission Control North Star
• Mission Control V1 Product Strategy
• Software Factory documentation authority map
• Generic Harness Contract V1
• Autonomous Execution Routing V1
• Factory Memory and Context Intelligence
• Factory Learning and Continuous Improvement
• Graph Engineering capability map
• Execution Manifest implementation
• Exact Model Route admission
• Sandbox Profile admission
• Workflow compatibility and structured completion
• Production admission evidence packet
• Production admission operator sequence
• Production admission final validation

External standards and current interoperability references, accessed 2026-08-28:

• Model Context Protocol 2026-07-28 release — stateless requests, explicit discovery, authorization hardening, Tasks extension, and current deprecations.
• OpenTelemetry GenAI semantic conventions — development-stage conventions for model, agent, workflow, plan, and tool spans.
• NIST SP 800-218A — secure software-development practices for AI model producers, system producers, and acquirers.
• SLSA Provenance 1.2 — artifact subjects, build definitions, run details, and builder identity.
• OWASP Top 10 for Agentic Applications 2026 — current agentic application threat taxonomy.

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

1. Why is an exact model route more than a provider and model name?
2. Which admission checks are hard constraints, and which signals may influence ranking after eligibility?
3. Why can a locally qualified implementation remain legitimately blocked in production?
4. What would prove that Skills are bound rather than merely discoverable?
5. How does authorized action parity differ from giving an agent human powers?
6. Why is an MCP Task not a substitute for a WorkOrder, Task, or Attempt?
7. Which records must be reconciled after an ambiguous GitHub or sandbox side effect?
8. What evidence would justify enabling Guarded Auto for one risk class?

10. Whiteboard 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.

11. Hands-on lab

Prerequisite: a read-only Mission Control checkout at d902fae7032c0696b531c44ae88829c652516fc6. Do not configure production or create canaries for this study.

1. Trace one WorkOrder from its revision through buildFactoryExecutionManifest.
2. Record every frozen identity, capability, scope, budget, and digest.
3. Trace exact model-route and Sandbox Profile production eligibility.
4. Trace worker admission and identify where a mismatched Factory Version fails.
5. Trace the candidate into the independent verification and publication path.
6. Inspect the production admission evidence and explain why qualification passes while production remains blocked.
7. Build a ten-row UI-action-to-governed-capability map for one operator surface.
8. Mark each row agent-capable, human-only, or gap, and define one outcome test plus one authorization-negative test.

The lab passes when another engineer can reproduce the map from exact source and explain every claim boundary without relying on README status labels alone.