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
Durable record model
Every claim has an owner, lineage, and boundary.
Mission Control expands the FDLC Artifact Protocol with implementation records needed to dispatch, recover, verify, and audit real work.
- 01Mission
The governed outcome and scope. This is Mission Control’s concrete realization of FDLC Intent.
- 02Mission Spec
An immutable, attributable statement of requirements, non-goals, and acceptance expectations.
- 03Plan
A versioned artifact bound to exact Specification lineage and approved before WorkOrder release.
- 04WorkOrder
The governed delivery and acceptance contract for one bounded unit.
- 05Task
An operational unit inside a WorkOrder; never the acceptance authority.
- 06Attempt
One immutable execution or verification try against frozen inputs and a fenced lease.
- 07Evidence Envelope
Attributable proof bound to the exact candidate, criterion, Attempt, and policy.
- 08Quality Gate Decision
A fail-closed eligibility decision assembled from current verification evidence.
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.
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 and recorded routing decisions exist behind gates.
Current boundaryOutcome evidence and complete cost coverage remain limited.
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
SupportedThe architecture reserves a default-deny MCP authority boundary.
Current boundaryCurrent admitted harness manifests mark MCP unsupported.
Factory incident lifecycle
SupportedA canonical incident aggregate can unify existing alerts, events, evidence, and recovery.
Current boundaryThe end-to-end lifecycle is not implemented.
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.
Build with the model
