FDLC in 5 MinutesIllustrative
The Factory Development Lifecycle is the process for designing, assembling, governing, operating, measuring, and continuously improving an AI software factory.
This page walks one concrete factory line—dependency modernization—through the full system so you can see how FDLC turns intent into independently verified software.
This is not a product tour. It is a concrete walkthrough of the Factory Development Lifecycle applied to one bounded, high-value class of work.
01 / The factory line
Upgrade a defined set of approved libraries across a single repository while preserving build integrity, test results, and public API compatibility.
All existing contract and integration tests pass against the exact candidate.
No deprecated v3 imports or compatibility shims remain.
No public API, schema, or authorization behavior changes.
The release record includes rollback conditions and an accountable owner.
Elapsed time from admitted upgrade to accepted change
Compatibility, test-failure, and subtle-breakage review per accepted upgrade
Accepted work that must re-enter governed execution or be reversed
Compatibility failures found after the release boundary
Worked reference scenario. Illustrative records and targets—not a production case study or benchmark result.
The goal of the factory line is not “run an agent.” It is to produce verified, accepted upgrades at lower cost, lower risk, and with less scarce human attention—while preserving a complete evidence trail.
02 / Four system views
FDLC is not one diagram. The views connect, but they are not interchangeable. Collapsing them produces confusion; keeping them separate produces clarity.
How the production system itself is created, validated, operated, and improved.
Explore the full view →02How one unit of software work advances inside the operating factory.
Explore the full view →03The six capability areas the factory must make explicit.
Explore the full view →04The eleven durable records that make every transition auditable.
Explore the full view →03 / Factory lifecycle applied
Discover, design, assemble, validate, deploy, operate, and improve the line under continuous governance, security, observability, and measurement. Evidence from real outcomes may propose a new version; it cannot silently rewrite the active line.
Select dependency upgrades as a repeatable factory line and record the current manual baseline.
Output · Measured opportunityDefine eligible repositories, acceptance evidence, delegated authority, and escalation boundaries.
Output · Factory definitionBind the research, migration, test, repository, model, and verification capabilities.
Output · Runnable factory lineRun policy, recovery, and representative upgrade evals before the factory may operate.
Output · Validated factory versionPromote dependency-modernization@1.0 with an environment binding and rollback plan.
Output · Active factory lineReceive eligible upgrade intent and execute the governed runtime lifecycle below.
Output · Verified software outcomesCompare observed outcomes with baseline and propose a versioned factory change.
Output · Governed improvementDesigned once. Run many times. Each run produces evidence that can improve the next run—under change control. The active factory version remains fixed until validated evidence justifies a governed improvement.
04 / Runtime lifecycle
Optimistic status labels are not sufficient. Runtime verbs move the work; artifact links point to the durable records that make every transition attributable and reviewable.
Record the desired SDK upgrade, owner, repository, constraints, and risk class.
Freeze behavioral boundaries and the evidence required for each acceptance criterion.
Choose the migration sequence, candidate strategy, rollback path, and verifier contract.
Release one bounded Work Order and retain each leased execution Attempt.
Bind test, type, lint, dependency, and diff evidence to the exact candidate.
A named human accepts or rejects the exact verified candidate and rationale.
Promote only the accepted candidate with current evidence and rollback readiness.
Watch the defined production window for behavioral regression and rollback signals.
Turn attributable friction or failure into a reviewed factory-improvement proposal.
05 / Eleven artifacts
These are representative semantic records, not a finalized wire format. Tasks, candidates, pull requests, and evidence envelopes may expand an implementation, but they cannot collapse the eleven canonical authority and evidence boundaries.
Outcome, owner, repository, constraints, and risk.
What outcome matters?Behavioral boundaries and criterion-level proof requirements.
What must be true?Approved migration sequence, dependencies, verification, and rollback strategy.
How will the factory achieve it?The bounded repository change authorized for execution.
What bounded unit is authorized?Identity, lease, environment, model, capabilities, and exact execution trace.
What exactly ran?Test receipts, typecheck, lint, dependency scan, and candidate diff.
What was observed?Independent judgment against the frozen Specification and exact candidate.
Does the evidence satisfy the specification?Named human decision, rationale, subject, and time.
May this consequence proceed?Promoted artifact, policy currentness, owner, and rollback conditions.
What was promoted?Observed production behavior during the declared measurement window.
Did the intended result hold in reality?Attributable improvement proposal without self-authorizing promotion.
What should change in the factory?06 / Architecture participation
No single agent owns the outcome. Each architectural area contributes a distinct responsibility and maps to concrete Mission Control records or decisions.
Mission, Mission Spec, acceptance criteria, owner, repository, and risk class.
Durable Work Order state, isolated Attempts, leases, checkpoints, and recovery.
Repository research, SDK migration skill, test runners, and source-control tools.
A policy-admitted reasoning profile selected for the bounded migration class.
Authority policy, exact-subject evidence, independent verification, and human acceptance.
Observed outcome, reviewer friction, failure taxonomy, and controlled promotion proposal.
Trust constrains every area. Learning captures validated outcomes and failures, but it never writes directly to production.
Implementation status remains capability-specific. Inspect the current Mission Control maturity ledger →
07 / Mission Control in the loop
These reference-implementation views show where governed work, evidence, and decisions become inspectable. They demonstrate the operating model; they do not claim fleet-scale production certification.
In Mission Control: Attempt completion → Quality Gate Decision → Human Acceptance → Release → Outcome. No single actor can advance more than one boundary without the required evidence and authority.
09 / How we know the factory improved
The first run does not get to claim improvement. Baseline the manual path, observe accepted outcomes, and protect quality with explicit guardrails.
accepted dependency upgrades ÷ eligible dependency-upgrade missionsShare of admitted Work Orders that satisfy their verification contract.
Model, compute, tooling, and human-attention cost divided by accepted upgrades.
Judgment time required per accepted change.
Elapsed time from approved intent to accepted outcome.
Candidates that satisfy required checks without corrective rework.
Accepted or released work that must re-enter governed execution or be reversed.
Improvement is measured against the original baseline, not against model confidence scores.