Governed autonomous delivery.

Mission Control is the reference implementation of the Factory Development Lifecycle. It turns intent, execution, evidence, approval, and outcomes into durable operating records.

Not another coding agent. The system that decides what agents may do—and what evidence must return before work advances.

Mission Control / Command CenterDemo view
Mission Control command center showing ranked work requiring operator attention
Operator-first by design.Decisions, blockers, risk, owners, and proof sources—not a stream of agent activity.
License
Open source
Demo
Deterministic
Truth model
Capability-specific
01 / GovernBound authority before execution.
02 / VerifyRequire evidence for every transition.
03 / DecidePut human attention at consequential boundaries.

Follow one mission through the control plane.

Select a stage to see the governing question, the authority allowed to answer it, and the proof required before state can advance.

Governed delivery trace
Deterministic example · 01 mission
01 / 06

Mission + Mission Spec

Planning eligible

Decision boundary

What outcome is required—and what would prove success?

Intent becomes a versioned contract with scope, non-goals, constraints, and acceptance expectations before an agent receives authority.

Authority
Mission owner
Control
Specification readiness
Required proof
Immutable spec revision
Capture the mission

Every claim has an owner, lineage, and boundary.

Mission Control binds a qualified Factory composition to approved work, derives readiness from current evidence, and keeps production, verification, and consequential human authority separate.

  1. 01
    Factory Version

    An immutable, qualified composition of Agent Definitions, Harness Versions, Capability Implementations, Model Profiles, Runtime Artifacts, Sandbox Profiles, Work Graphs, verification requirements, and policy references. Qualification alone does not activate it.

  2. 02
    Execution Profile

    The governed composition that keeps Model, Agent, Harness, Work Graph, Runtime, Sandbox, Capability Implementation, and policy identities distinct for an Attempt.

  3. 03
    WorkOrder

    The canonical governed unit of approved work, bound to an exact revision and Factory Version.

  4. 04
    Readiness

    A derived determination that required identities, qualifications, authorities, resources, and policies are satisfied. It is never a manually asserted READY flag.

  5. 05
    Task

    A bounded executable portion of an admitted WorkOrder; completion does not accept the WorkOrder.

  6. 06
    Attempt

    One authoritative execution of a Task with durable identity, authority, runtime, evidence, and outcome lineage.

  7. 07
    Unpublished Candidate

    An exact producer output that has not received independent verification or publication authority.

  8. 08
    Verification Subject

    The frozen identity and verification contract describing exactly what a verifier evaluates.

  9. 09
    Verifier Attempt

    A separate canonical Attempt that independently evaluates a Verification Subject.

  10. 10
    Evidence

    Durable, attributable records of what was authorized, executed, observed, verified, or decided.

  11. 11
    Human Authority

    Explicit authority retained for consequential decisions such as acceptance, publication, release, restoration, or policy promotion.

Operate from exceptions, evidence, and decisions.

Explore three real views from the deterministic Software Factory demo. Each surface is designed around the next responsible action—not activity for activity’s sake.

Mission Control / Command CenterSoftware Factory Demo
Mission Control Command Center showing ranked work that needs operator attention

These screens demonstrate product structure and the documented one-repository V1 path. They are not a claim of fleet-scale autonomous production.

Intelligence can vary. Authority remains explicit.

The browser, agents, harnesses, and providers do not create their own permission to act or advance state. The control plane remains the source of identity, policy, state, and decisions.

01 / Operator surfaces
React + TypeScriptExceptions, decisions, Plans, WorkOrders, traces, and evidence
Human attention
02 / Authoritative control plane
ConvexState, policy, identity, admission, decisions, and immutable lineage
Source of authority
03 / Orchestration
Hono + worker runtimeSigned service commands, harness admission, leases, checkpoints, and recovery
Bounded coordination
04 / Execution
Codex + bounded backendsFrozen manifest, isolated worktree or Preview Remote Sandbox, exact candidate
Replaceable intelligence
05 / Verification + publication
Independent Attempt + GitHub AppEvidence receipts, currentness, Quality Gate, and permit-gated publication
Proof before promotion

Operating rule Allow intelligence to change. Never allow authority to become implicit.

Inspect what is real—and where it stops.

Status belongs to each capability, not the product slogan. Open any item to see the implemented behavior and its current boundary.

Available07 capabilities
Governed Missions, Plans, and WorkOrders

SupportedVersioned Plans can be reviewed and approved before releasing bounded WorkOrders.

Current boundaryQualified for the documented one-repository V1 golden path.

Attempts, leases, and recovery

SupportedExecution is admitted against frozen configuration, fenced by a lease, and retained as immutable Attempt lineage.

Current boundaryFleet-scale provider-failure operation is not claimed.

Independent verification and Quality Gates

SupportedExact candidates are checked by logically separate verifier Attempts and bound to evidence receipts.

Current boundaryVerification establishes eligibility; it does not accept, merge, or release.

GitHub App publication and currentness

SupportedPublication can be permit-gated and reconciled to the exact pull-request head and evidence lineage.

Current boundaryMerge remains human-owned.

Factory Memory and Context Packages

SupportedProvenance-backed context can be frozen to an exact Attempt and inspected.

Current boundaryAdvisory and phase-gated; cannot satisfy acceptance.

Observability, traces, and evals

SupportedRuns can produce traces, scores, datasets, and experiments for diagnostic comparison.

Current boundaryDiagnostic only; no acceptance authority.

Factory incident pause and restoration

SupportedIncident Command qualified pause and separately authorized restoration of dispatch admission for the Mission Control repository, with independently observed effects.

Current boundaryOne exact repository operation using a synthetic qualification incident; other controls, arbitrary repositories, customer incidents, and autonomous emergency authority remain unqualified.

Experimental08 capabilities
Spec-driven Mission intake

SupportedImmutable Mission Spec revisions and deterministic spec-quality checks are implemented.

Current boundaryDefault off; finalized means planning-ready, not approved.

Model and backend routing

SupportedPolicy-aware routing records capability selection against qualification and execution constraints.

Current boundaryAdvisory and gated; complete outcome economics and broader live fallback qualification remain incomplete.

Governed inference accounting

SupportedAggregate reservations, bounded dispatch allowance, immutable observations, settlement correction, and durable recovery are qualified offline.

Current boundaryDefault off. Live provider billing, comparison of two exact routes, and real accepted-workload economics remain unqualified.

Remote Sandbox

SupportedA bounded live cohort is qualified for production-pilot evaluation.

Current boundaryPreview only; provider-enforced egress and sustained real-work evidence remain open.

Factory Learning

SupportedEvidence can produce bounded learning signals and human-reviewed proposals.

Current boundaryNo automatic promotion; real production signals are limited.

Governed MCP runtime

SupportedOne exact Context7 query-docs read was qualified through versioned authority, brokered execution, durable receipts, and independent verification.

Current boundaryOne fixed public React query only; writes, arbitrary servers and operations, broad credentials, and harness-native MCP remain unsupported.

Canonical Factory admission

SupportedOne deterministic synthetic path qualified exact Factory Versions, derived WorkOrder readiness, producer and verifier Attempts, an unpublished candidate, and current verification evidence.

Current boundaryNo external model calls, publication, acceptance, or Production mutation occurred; live autonomous delivery remains unqualified.

Release and production feedback

SupportedRelease records and advisory learning provide foundations for connecting delivery to observed outcomes.

Current boundaryA complete real release, observation, rollback, and governed improvement loop remains unproven.

Planned01 capabilities
Broader containment controls

SupportedExtend qualified containment to additional capability versions, control actions, and targets as workload needs justify them.

Current boundaryEach control and target requires separate qualification and authority; the existing pause operation grants no broader permission.

Read the canonical capability maturity ledger ↗

Prove one complete operating loop, then expand.

These are enhancement priorities, not availability claims or new execution authority. Build on the existing control plane, capability records, inference accounting, incident controls, and advisory learning.

  1. 01

    First / Make execution identity explicit

    Separate Model, Agent, Harness, Runtime, Sandbox, and Work Graph records

    Extend the Execution Profile and Attempt manifest with distinct immutable references for Model Profile, Agent Definition, Harness Version, Capability Implementations, Runtime Artifact, Sandbox Profile, Work Graph Version, Orchestrator policy, and Control Plane policy bundle. Show the same boundary map in admission, run inspection, evidence, and incident views.

    Proof before expansion: A failed Attempt can be attributed to one boundary without reconstructing identity from logs. Replacing one component changes only its reference, requires current qualification, and never silently widens authority.

  2. 02

    First / Close the operating loop

    Make one real outcome inspectable end to end

    Connect the existing Plan, readiness, Attempts, evidence, human decision, release, and observation records. Present missing proof, unresolved cost, and the next responsible owner in one decision brief.

    Proof before expansion: A controlled workload can be reconstructed after refresh and restart, including failure and recovery. Verification, acceptance, release, and observed value remain distinct.

  3. 03

    Next / Qualify capability decisions

    Explain route eligibility and full outcome cost

    Extend the existing routing and inference accounting work with current qualification, rejection reasons, budget reservations, provider reconciliation, and accepted-outcome cost coverage. Reuse the existing capability and Attempt identities.

    Proof before expansion: A separately authorized real cohort proves attributable costs and a qualified fallback. Missing billing stays unknown and an outage cannot trigger an unauthorized substitute.

  4. 04

    Next / Prove safe improvement

    Turn observed failures into tested factory changes

    Join production observations and incident records to advisory learning proposals, regression cases, version comparison, and human promotion. Extend containment one control and target at a time.

    Proof before expansion: One observed failure yields a reproducible regression, an evaluated candidate version, an explicit decision, and a separately proven restoration path.

  5. 05

    Later / Expand from measured demand

    Add fair scheduling and broader coordination

    Extend bounded scheduling, parent/child budget conservation, integration verification, and tenant isolation when the initial operating loop proves the need. Keep one shared control plane and reuse qualified capabilities.

    Proof before expansion: Representative contention, cancellation, stale-worker, cross-scope denial, and partial-success drills pass before increasing concurrency or repository scope.

Read the engineering playbook and readiness questions →

Make failures inspectable, containable, and recoverable.

These controls fit inside the existing roadmap. They extend current records and the narrowly qualified pause and restoration path; they are requirements, not availability claims.

  1. 01
    Impact graph and blast-radius query

    Traverse Factory Versions, Execution Profiles, capabilities, WorkOrders, Attempts, effects, evidence, approvals, releases, environments, and outcomes with currentness and explicit unknown states.

  2. 02
    Incident command and decision timeline

    Bind severity, owners, hypotheses, decisions, commands, acknowledgements, observed enforcement, communications, handoffs, and evidence to one durable incident identity.

  3. 03
    Scoped containment and degraded modes

    Extend the qualified pause path one subject and control at a time. Reserve capacity for cancellation and reconciliation, require step-up authority, and keep restoration separately authorized.

  4. 04
    Saga recovery and effect reconciliation

    Show partial dependency-graph state, operation receipts, unknown effects, orphaned work, compensation choices, and the exact safe boundary for a replacement Attempt.

  5. 05
    Known-good restoration and verified closure

    Bind recovery candidates to exact artifacts and configuration, then require independent recovery evidence, residual risk, backlog disposition, and governed corrective actions before closure.

Read the production reliability and incident operations playbook →

Run the deterministic factory demo.

Requires Node 20, pnpm 9, Git, and a Convex development deployment. Live providers are not required for the demo.

git clone https://github.com/jaydubya818/MissionControl.git
cd MissionControl
corepack enable && pnpm install
cp .env.example .env.local
pnpm exec convex dev --once

# Terminal 1
pnpm run dev:demo

# Terminal 2
pnpm run convex:seed:demo:force

Then open http://localhost:5199/v2/command-center and select Software Factory Demo. The seeded path runs without live model providers.

A definition is intent. A version is a qualified runtime.

This design-to-qualification handoff sits within FDLC’s governing lifecycle. It produces a qualified factory composition; software delivery still follows intent → planning → execution → evidence → verification → approval → release → outcomes → learning.

  1. You + AI-FDE

    Factory Definition

    Describe the workflow, capabilities, authority, and evidence required.

    Reviewable intent
  2. Accountable human FDE

    Review and approve

    Confirm the design and the authority being delegated.

    Explicit approval
  3. Mission Control

    Validate and qualify

    Check the submitted intent and qualify the exact runtime composition.

    Evidence gate
  4. Mission Control

    Factory Version

    Identify the immutable qualified composition. Release and execution still require authorization.

    Qualified runtime

Use the reference implementation, then go deeper.

Read the living case study →Inspect the architecture →Build a Factory Definition →

Inspect it, then define your own factory line.

Contribute on GitHub ↗Build a Factory Definition →Preview the Specification →