Agents move beyond code generation and participate across planning, design, implementation, testing, deployment, and maintenance.
FDLC Framework / 01
The lifecycle for the factory itself.
The Factory Development Lifecycle is the process for designing, assembling, governing, operating, measuring, and continuously improving an AI software factory.
Canonical definition
“The Factory Development Lifecycle is the process for designing, assembling, governing, operating, measuring, and continuously improving an AI software factory.”
SDLC manages the lifecycle of software.
FDLC manages the lifecycle of the factory that produces software.
It is the factory operating system: the disciplined layer around agents, models, tools, people, policies, evidence, and workflows.
Verified delivery, not merely generated code.
The category boundary
Two transitions, then a new discipline.
First, agents participate across the software lifecycle. Then those workflows become a persistent, governed production system. FDLC is the engineering discipline for that factory.
| Category | Traditional SDLC | AI-Native SDLC | FDLC |
|---|---|---|---|
| Primary object | Software | Software + AI-assisted workflow | The software factory |
| Question answered | How do we build software? | How does AI change software development? | How do we engineer the factory that performs autonomous software delivery? |
Individual agent workflows become persistent, orchestrated production systems that transform intent into verified software with decreasing human intervention.
FDLC is the engineering discipline for that factory.
Why FDLC exists
Code generation is no longer the bottleneck. Process is.
Organizations can give every developer a powerful coding agent. They then encounter a different class of operating, authority, evidence, and learning problems.
FDLC exists to answer these questions systematically:
- Who defines intent, and when is it complete?
- What agent may act, with what authority, tools, and blast radius?
- What evidence proves the work is correct?
- Can the producing agent certify its own output?
- When must a human intervene?
- How does the system improve without learning the wrong thing?
Six operating shifts
Four views of the system
Do not collapse these into one diagram.
Each view answers a different question. Keeping them separate is what makes the operating model precise.
How the factory evolves.
Discover, design, assemble, validate, deploy, operate, and improve.
View outer lifecycle ↓How software moves inside it.
One autonomous delivery loop from received intent to governed learning.
View inner lifecycle ↓What the factory contains.
Six capability areas that every implementation must address.
View architecture ↓What makes work durable.
Eleven semantic objects from Intent to Learning Signal.
View protocol ↓Model 01 / Factory lifecycle
How the factory evolves.
The outer lifecycle applies when creating a factory line and whenever validated evidence says the existing line should change. Its continuous controls span every stage.
01DiscoverExpand
Find work worth turning into a factory line and establish the baseline.
- Candidate workflows
- Cycle-time baseline
- Cost and human effort
- Defect and failure rates
02DesignExpand
Define the outcome, runtime flow, evidence contract, risk, and human control boundaries.
- Intended outcome
- Acceptance criteria
- Runtime lifecycle
- Autonomy and escalation
03AssembleExpand
Compose the capabilities and environment required to do the work.
- Agents and skills
- Tools and MCP
- Context services
- Models and evaluators
04ValidateExpand
Prove that the factory line can operate safely, reliably, and measurably before promotion.
- Capability evals
- Policy and security tests
- Failure and recovery drills
- End-to-end acceptance
05DeployExpand
Promote the exact validated factory version into its intended operating environment.
- Version promotion
- Environment binding
- Change approval
- Rollback readiness
06OperateExpand
Run the software-delivery lifecycle durably while managing exceptions and consequential decisions.
- Runtime orchestration
- State and recovery
- Evidence and decisions
- Human intervention
07ImproveExpand
Change the factory from validated outcomes, telemetry, incidents, and controlled experiments.
- Outcome signals
- Failure taxonomy
- Baseline comparison
- Governed promotion
Continuous controlsGovern Secure Observe Measure
Bound identity, delegated authority, policy, spend, approval, and accountability.
Protect data, secrets, tools, environments, and the capability supply chain.
Preserve state, traces, lineage, evidence, decisions, and incidents end to end.
Compare quality, cost, time, human effort, recovery, and risk with a baseline.
Model 02 / Runtime lifecycle
How software moves inside an operating factory.
The inner lifecycle transforms intent into independently verified software under explicit policy and human authority, then returns production outcomes as controlled learning signals.
- 01 / IntentReceive
Capture the desired outcome, constraints, owner, and initial risk.
- 02 / SpecificationSpecify
Define what must be true and what evidence will establish it.
- 03 / PlanPlan
Choose the governed path, decomposition, and verification strategy.
- 04 / Work Order · AttemptExecute
Run bounded, authorized work as attributable attempts.
- 05 / Evidence · VerificationVerify
Evaluate the exact candidate against the specification.
- 06 / ApprovalApprove
Apply policy and human authority at consequential boundaries.
- 07 / ReleaseRelease
Promote the exact accepted software artifact with rollback readiness.
- 08 / OutcomeObserve
Compare the production result with the intended outcome.
- 09 / Learning SignalLearn
Propose controlled changes to the factory from validated outcomes.
Model 03 / Architecture
What the factory requires.
The six areas are capability boundaries, not vendor product categories or deployment tiers.
01IntentDefine what should happen and how success will be judged.02HarnessMake execution durable, bounded, observable, and recoverable.03CapabilityPackage reusable ways for agents to act in a domain.04ModelMatch reasoning capability to the work without provider lock-in.05TrustDecide what may run, what can advance, and what requires judgment.06LearningImprove the factory from validated outcomes under change control.
Read the detailed architecture Model 04 / Artifact protocol
How one unit of work becomes durable and inspectable.
Lifecycle verbs describe what the factory does. Protocol nouns preserve what existed, ran, was observed, was decided, and may improve next.
01IntentExpand
What outcome matters?
Named outcome, constraints, owner, and risk02SpecificationExpand
What must be true?
Versioned requirements, boundaries, and acceptance criteria03PlanExpand
How will the factory achieve it?
Approved decomposition, sequence, risk, and verification strategy04Work OrderExpand
What bounded unit is authorized?
Scope, risk, authority, and verification contract05AttemptExpand
What exactly ran?
Identity, lease, versions, environment, and trace06EvidenceExpand
What was observed?
Attributable artifacts bound to the exact candidate07VerificationExpand
Does the evidence satisfy the specification?
Independent checks against exact criteria08ApprovalExpand
May this consequence proceed?
Authorized, attributable, reasoned decision09ReleaseExpand
What was promoted?
Exact artifact, current policy, and rollback readiness10OutcomeExpand
Did the intended result hold in reality?
Observed technical, operational, and user result11Learning SignalExpand
What should change in the factory?
Attributable outcome and a controlled improvement proposal
Governance
Ten principles hold the system together.
- 01
Intent must be explicit before execution begins.
- 02
The Plan is a governed artifact.
- 03
Every agent has an identity, sponsor, and bounded authority.
- 04
Execution must be isolated, observable, and recoverable.
- 05
Producers should not be their only verifier.
- 06
State transitions require evidence.
- 07
Autonomy must be earned through measured performance.
- 08
Human attention belongs at consequential boundaries.
- 09
Learning must come from validated outcomes, not merely model confidence.
- 10
The value of a factory is measured in verified outcomes, not generated tokens.
Measurement
The unit of value is a verified outcome.
Generation volume is operational telemetry. Factory value is accepted change with known quality, cost, effort, recovery, and risk.
Verified completion rate
The share of admitted work that satisfies its verification contract.
Cost per verified outcome
Model, compute, tooling, and human-attention cost divided by accepted outcomes.
Human review minutes
Judgment time required per accepted change.
Cycle time
Elapsed time from approved intent to accepted outcome.
First-pass verification rate
Candidates that satisfy required checks without corrective work.
Reopen rate
Accepted or closed work that must re-enter governed execution.
Rollback rate
Released outcomes that require reversal.
Escaped defect rate
Defects discovered after the governed release boundary.
How the pieces fit
One open discipline. Distinct ways to define, teach, demonstrate, and scale it.
The Framework remains the definition of FDLC. Specifications, teaching material, implementations, and commercial products support the discipline without becoming the category itself.
01 / Open methodology
FDLC Framework
The operating model and engineering discipline defined on this page.
Explore →02 / Proposed standardFDLC Specification
Formal definitions and invariants for portable artifacts and state transitions.
Explore →03 / Open field guideAI Software Factory Guide
The detailed methodology from first principles through production.
Explore →04 / Open-source referenceMission Control
The reference implementation that makes the FDLC protocol concrete.
Explore →05 / Proposed productFDLC Enterprise
The commercial control plane for operating proven factories at organizational scale.
Explore →Reference implementation
Mission Control makes the protocol concrete.
Inspect how one open-source control plane models governed Plans, WorkOrders, Attempts, evidence, verification, and human acceptance—with current limitations visible.
Start here
Choose the next depth you need.
01FDLC in 5 MinutesOne factory line end to end →02ArchitectureSix capability areas →03ManifestoTen governing principles →04Mission ControlReference implementation →05MaturityAssess what is true today →06GuideFull methodology →
Verified delivery, not merely generated code.