Mission Control / Open-source FDLC reference
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.

- License
- Open source
- Demo
- Deterministic
- Truth model
- Capability-specific
Interactive governed path
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.
Mission + Mission Spec
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
Canonical admission model
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.
- 01Factory 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.
- 02Execution Profile
The governed composition that keeps Model, Agent, Harness, Work Graph, Runtime, Sandbox, Capability Implementation, and policy identities distinct for an Attempt.
- 03WorkOrder
The canonical governed unit of approved work, bound to an exact revision and Factory Version.
- 04Readiness
A derived determination that required identities, qualifications, authorities, resources, and policies are satisfied. It is never a manually asserted READY flag.
- 05Task
A bounded executable portion of an admitted WorkOrder; completion does not accept the WorkOrder.
- 06Attempt
One authoritative execution of a Task with durable identity, authority, runtime, evidence, and outcome lineage.
- 07Unpublished Candidate
An exact producer output that has not received independent verification or publication authority.
- 08Verification Subject
The frozen identity and verification contract describing exactly what a verifier evaluates.
- 09Verifier Attempt
A separate canonical Attempt that independently evaluates a Verification Subject.
- 10Evidence
Durable, attributable records of what was authorized, executed, observed, verified, or decided.
- 11Human Authority
Explicit authority retained for consequential decisions such as acceptance, publication, release, restoration, or policy promotion.
Operator experience
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.

These screens demonstrate product structure and the documented one-repository V1 path. They are not a claim of fleet-scale autonomous production.
Implementation architecture
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.
Operating rule Allow intelligence to change. Never allow authority to become implicit.
Current capability
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.
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.
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.
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.
Development priorities / Proposed
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.
- 01
First / Make execution identity explicit
Separate Model, Agent, Harness, Runtime, Sandbox, and Work Graph recordsExtend 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.
- 02
First / Close the operating loop
Make one real outcome inspectable end to endConnect 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.
- 03
Next / Qualify capability decisions
Explain route eligibility and full outcome costExtend 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.
- 04
Next / Prove safe improvement
Turn observed failures into tested factory changesJoin 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.
- 05
Later / Expand from measured demand
Add fair scheduling and broader coordinationExtend 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.
Production operations / Required
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.
- 01Impact 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.
- 02Incident command and decision timeline
Bind severity, owners, hypotheses, decisions, commands, acknowledgements, observed enforcement, communications, handoffs, and evidence to one durable incident identity.
- 03Scoped 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.
- 04Saga 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.
- 05Known-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 →
Local quickstart
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:forceThen 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.
You + AI-FDE
Factory Definition
Describe the workflow, capabilities, authority, and evidence required.
Reviewable intentAccountable human FDE
Review and approve
Confirm the design and the authority being delegated.
Explicit approvalMission Control
Validate and qualify
Check the submitted intent and qualify the exact runtime composition.
Evidence gateMission Control
Factory Version
Identify the immutable qualified composition. Release and execution still require authorization.
Qualified runtime
What should I do next?
Use the reference implementation, then go deeper.
Build with the model
