Agents move beyond code generation and participate across planning, design, implementation, testing, deployment, and maintenance.
FDLC Framework / 01
The lifecycle for the factory itself.
FDLC is the Factory Development Lifecycle—the open operating model, engineering framework, and reference architecture for designing, building, governing, operating, measuring, and continuously improving AI software factories.
Canonical definition
“FDLC is the Factory Development Lifecycle—the open operating model, engineering framework, and reference architecture for designing, building, governing, operating, measuring, and continuously improving AI software factories.”
Traditional SDLC organizes software production.
FDLC engineers the factory that increasingly performs it.
It is the durable discipline around agents, models, tools, people, policies, evidence, and workflows.
Verified delivery, not merely generated code.
The category boundary
Three transitions, then a distinct engineering discipline.
Traditional software production becomes AI-native. Agentic workflows become a persistent software factory. FDLC is the lifecycle for engineering and evolving that factory—not another SDLC variant.
| Category | Traditional SDLC | AI-Native SDLC | AI Software Factory | FDLC |
|---|---|---|---|---|
| Primary object | Software | Software + AI-assisted workflow | Persistent software production system | The software factory |
| Question answered | How do we build software? | How does AI change software development? | How do agentic workflows become a governed production system? | 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.
Organizations apply an engineering lifecycle to design, build, govern, operate, measure, and continuously improve the factory itself.
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
Three abstraction levels
Three questions. Three exact sequences.
The levels relate, but they are not interchangeable. Keeping the factory lifecycle, software value stream, and governed artifact protocol distinct makes the operating model understandable and implementable.
How the factory evolves.
Discover → Design → Assemble → Validate → Deploy → Operate → Improve.
View the factory lifecycle ↓How software flows through it.
Intent → Plan → Define Agent → Execute through Harness → Apply Skills → Evaluate → Improve → Deliver Software.
View the Guide value stream ↓How one unit becomes proven.
Eleven durable artifacts from Intent through Specification, evidence, outcome, and Learning.
View the artifact protocol ↓Level 01 / Factory Development Lifecycle
How the factory itself is developed and evolved.
Discover, design, assemble, validate, deploy, operate, and improve a factory line. Governance, Security, Observability, Measurement, and Human Authority 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, execution flow, evidence contract, risk, and human control boundaries.
- Intended outcome
- Acceptance criteria
- Execution and artifact flow
- 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 controlsGovernance Security Observability Measurement Human Authority
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.
Keep accountable judgment at material, ambiguous, and irreversible boundaries.
Level 02 / Software factory value stream
How software work flows through the factory.
The Guide’s eight stages preserve the practical teaching sequence from intent through delivered software. This value stream explains the work performed by an operating factory, not how the factory itself evolves.
- 01 / Guide stageIntent
Establish the desired software outcome and its operating context.
- 02 / Guide stagePlan
Turn intent into a governed path, decomposition, and proof strategy.
- 03 / Guide stageDefine Agent
Bind the role, model, context, authority, and capabilities required for the work.
- 04 / Guide stageExecute through Harness
Run bounded work in a durable, observable, and recoverable execution system.
- 05 / Guide stageApply Skills
Use versioned domain procedures and governed tools to produce the candidate.
- 06 / Guide stageEvaluate
Collect evidence and independently evaluate the exact candidate.
- 07 / Guide stageImprove
Correct the work or propose a controlled factory change from validated evidence.
- 08 / Guide stageDeliver Software
Advance accepted software through the authorized delivery boundary.
Level 03 / Autonomous execution and artifact protocol
How one bounded unit of work becomes governed and proven.
Intent, Specification, Plan, Work Order, Attempt, Evidence, Verification, Approval, Release, Outcome, and Learning 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 result11LearningExpand
What should change in the factory?
Attributable outcome and a controlled improvement proposal
Structural view / Six architecture domains
What the factory requires.
Intent, Harness, Capability, Model, Trust, and Learning are capability boundaries, not a lifecycle, vendor taxonomy, or deployment tier.
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 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
Total cohort cost, including failed work and retries, divided by independently verified outcomes. Report cost coverage.
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.