FDLC in 5 MinutesIllustrative
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.
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 / Three abstraction levels
The levels connect, but they are not interchangeable. The six-domain architecture is a structural view across them, not a fourth lifecycle.
How the production system itself is created, validated, operated, and improved.
Explore the full view →02How software work flows through the operating factory from intent to delivery.
Explore the full view →03How one bounded unit becomes governed, durable, and proven.
Explore the full view →03 / Level 01 · Factory Development Lifecycle
Discover, design, assemble, validate, deploy, operate, and improve the line under continuous Governance, Security, Observability, Measurement, and Human Authority. 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 run the governed execution path 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 / Level 02 · Software factory value stream
Intent, Plan, Define Agent, Execute through Harness, Apply Skills, Evaluate, Improve, and Deliver Software explain how work moves through the factory. They do not replace the lifecycle used to engineer the factory.
Establish the desired software outcome and its operating context.
Turn intent into a governed path, decomposition, and proof strategy.
Bind the role, model, context, authority, and capabilities required for the work.
Run bounded work in a durable, observable, and recoverable execution system.
Use versioned domain procedures and governed tools to produce the candidate.
Collect evidence and independently evaluate the exact candidate.
Correct the work or propose a controlled factory change from validated evidence.
Advance accepted software through the authorized delivery boundary.
Record the desired SDK upgrade, then freeze its owner, constraints, behavioral boundaries, and evidence contract.
Approve the migration sequence, rollback path, verifier contract, and one bounded Work Order.
Run and retain each leased execution Attempt against the frozen inputs.
Bind current evidence and independent verification to the exact candidate before a named human decides whether it may proceed.
Promote only the accepted candidate, then observe the declared production window for regression and rollback signals.
Turn attributable friction or failure into a reviewed factory-improvement proposal.
05 / Level 03 · Autonomous execution and artifact protocol
Intent, Specification, Plan, Work Order, Attempt, Evidence, Verification, Approval, Release, Outcome, and Learning are representative semantic records, not a finalized wire format. Implementations may add records without collapsing these 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 / Structural view · Six architecture domains
Intent, Harness, Capability, Model, Trust, and Learning describe what the factory contains. No single agent owns the outcome, and the domains are not a fourth lifecycle.
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 through human acceptance and permit-gated pull-request publication. They do not prove generalized release, production learning, or fleet-scale operation.
In the qualified Mission Control path: Attempt completion → independent verification → Quality Gate eligibility → Human Acceptance → permit-gated pull-request publication. Merge, generalized release, and production outcome remain outside the qualified V1 boundary.
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.
Total cohort cost, including failed upgrades and retries, divided by independently verified upgrades; report missing cost coverage.
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.