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 FDLC governing lifecycle
Follow the work. Inspect the controls.
Select a stage to see what enters, what leaves, and what permits the work to move forward.
Stage 01 / 09
Intent
State the desired outcome, constraints, and accountable owner.
- Input
- A problem worth solving
- Output
- Intent contract
Control at this stage
Agree on scope, acceptance criteria, risk, and ownership before delegating work.
Example · dependency upgrade
Upgrade a vulnerable dependency. Preserve the public API and existing service behavior.
Learning closes the loop. Improvements return through verification and approval. This explorer illustrates the lifecycle; it does not execute work or grant authority.
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.02HarnessTurn model intelligence into bounded, observable agent operation.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
Interactive explorer
Inspect one unit of work through the runtime.
Start at Verify. Move across stages, inspect participating capabilities, and open the matching records from the worked example.
Interactive factory explorer
Follow one unit of workChoose a stage. Then inspect the capabilities it activates.Swipe the lifecycle
05 / 09
Stage 05 / Evidence · Verification
Does the exact candidate satisfy the specification?
Evaluate the produced candidate independently and bind every finding to the exact subject.
State earnedCandidate verified
- Durable record
- Evidence · Verification
- Evidence required
- Current, attributable evidence plus independent checks against each acceptance and policy criterion.
- Factory coordination
- Collect evidence, run independent checks, preserve lineage, and fail closed on missing proof.
Factory capabilities
9 of 10 participate at VerifyParticipates at Verify
Evals
Test the exact candidate against acceptance, quality, security, and policy criteria.
Explore the Trust areaGovernance
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 / Preview productAI-FDE
The evidence-driven product for turning reviewed enterprise reality into an approved Factory Definition, led by an accountable human Factory Deployed Engineer.
Explore →06 / Proposed productFDLC Enterprise
The commercial control plane for operating proven factories at organizational scale.
Explore →What is real today
Framework, product, runtime, and experiments stay distinct.
These labels describe current public status. They are not certification and they do not invent availability.
- Framework
FDLC
AvailableOpen operating model and engineering discipline.
- Book
Guide
AvailableThe field guide that teaches how to implement FDLC.
- Runtime
Mission Control
AvailableOpen-source control plane with capability-specific evidence and limits.
- Product
AI-FDE
PreviewInternal alpha with a synthetic demo. Discovers and designs a Factory Definition; a Factory Deployed Engineer remains the accountable human.
- Executor
Fab
ExperimentalLocal factory agent builder. No live model qualification yet.
- Platform
Enterprise
ProposedCommercial multi-factory control plane. Not generally available.
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.
What should I do next?