Mission Control Capability, Workflow, and Admission Map

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.