One platform. Many verified outcomes.

Centralize the enterprise infrastructure that should be shared. Compose factories only for materially different governed outcomes. Reuse qualified agents, harnesses, tools, model routes, context, and execution profiles across the portfolio.

Architecture
Shared platform
Operating units
Composable factories
Pricing
Contact FDLC Enterprise

Centralize infrastructure. Specialize outcomes.

The architecture separates a singular enterprise platform from outcome-specific factories and reusable execution capabilities. Scale increases capacity and concurrency without requiring a factory per team or repository.

FDLC / Reference architecture · 01

One platform. Many outcomes.

One platform.
Many outcomes.

Centralize the infrastructure.
Compose the work.
Reuse qualified capabilities.

1

Shared Enterprise AI Software Factory Platform

Common services for every factory. One governed control plane.

Mission Control
Plan · route · coordinate
Identity / Access
Principals · permissions
Capability Registry
Versions · qualification
Model Gateway
Approved inference
Context / Knowledge
Authorized retrieval
Execution Environments
Runtime · sandbox · limits
Observability
Traces · quality · cost
Policy / Security
Controls outside the model
Evidence / Audit
Proof · provenance · decisions

Mission Control is the meta-factory control plane. It owns Objective intake, decomposition, WorkOrder coordination, state, recovery, policy, approvals, evidence, release gates and outcome tracking. Providers and infrastructure may vary within qualification and policy.

Shared services support every factory
2

Factory Portfolio

Outcome-specific operating units. Start with a broad default.

Software Delivery Factory
Broad default
  • Features, bug fixes, refactoring
  • Tests and dependency updates
  • Security fixes and releases
Modernization Factory
When justified
  • Framework / language migrations
  • Platform and repository upgrades
  • Compatibility and migration waves
Security Remediation Factory
When justified
  • CVE / dependency remediation
  • Affected asset discovery
  • Verification, exceptions, reporting

Additional factories only when justified: materially different outcome semantics, ownership, qualification, governance, authority, verification or risk.

Factories compose these shared capabilities — a dependency, not a process step
3

Reusable Capabilities

Build once. Qualify. Govern. Reuse within the approved scope.

Agents
Planning, coding, testing, review
Harnesses
Context, tools, state, bounded loops
Tools / Skills
Builds, scanners, APIs, reusable guidance
Models / Inference
Qualified logical model routes
Execution Profiles
Runtime, sandbox, network and resource limits
4

Enterprise Delivery Flow

How the architecture produces a verified outcome.

  1. 01Intent
  2. 02Plan
  3. 03Route
  4. 04Execute
  5. 05Verify
  6. 06Release
  7. 07Learn

Release requires approval of the exact Candidate. Learning proposes improvements; it does not silently change the live composition.

THE PRODUCTVerified outcome

Quality · security · reliability · cost per verified outcome · human effort

Read diagram description

One enterprise platform supplies nine shared services, including Mission Control as the meta-factory control plane. A portfolio starts with Software Delivery and adds Modernization, Security Remediation or other factories only when their governed contracts differ. Factories compose shared Agents, Harnesses, Tools and Skills, Models and Execution Profiles. These architectural layers are dependencies, not sequential runtime steps. The separate delivery flow is Intent, Plan, Route, Execute, Verify, Release and Learn. Approval controls release; the product is a verified outcome.

Reference architecture · Availability and implementation require qualification.

One platform. Many outcomes. — full-size
One platform.
Many outcomes.

Centralize the infrastructure.
Compose the work.
Reuse qualified capabilities.

1

Shared Enterprise AI Software Factory Platform

Common services for every factory. One governed control plane.

Mission Control
Plan · route · coordinate
Identity / Access
Principals · permissions
Capability Registry
Versions · qualification
Model Gateway
Approved inference
Context / Knowledge
Authorized retrieval
Execution Environments
Runtime · sandbox · limits
Observability
Traces · quality · cost
Policy / Security
Controls outside the model
Evidence / Audit
Proof · provenance · decisions

Mission Control is the meta-factory control plane. It owns Objective intake, decomposition, WorkOrder coordination, state, recovery, policy, approvals, evidence, release gates and outcome tracking. Providers and infrastructure may vary within qualification and policy.

Shared services support every factory
2

Factory Portfolio

Outcome-specific operating units. Start with a broad default.

Software Delivery Factory
Broad default
  • Features, bug fixes, refactoring
  • Tests and dependency updates
  • Security fixes and releases
Modernization Factory
When justified
  • Framework / language migrations
  • Platform and repository upgrades
  • Compatibility and migration waves
Security Remediation Factory
When justified
  • CVE / dependency remediation
  • Affected asset discovery
  • Verification, exceptions, reporting

Additional factories only when justified: materially different outcome semantics, ownership, qualification, governance, authority, verification or risk.

Factories compose these shared capabilities — a dependency, not a process step
3

Reusable Capabilities

Build once. Qualify. Govern. Reuse within the approved scope.

Agents
Planning, coding, testing, review
Harnesses
Context, tools, state, bounded loops
Tools / Skills
Builds, scanners, APIs, reusable guidance
Models / Inference
Qualified logical model routes
Execution Profiles
Runtime, sandbox, network and resource limits
4

Enterprise Delivery Flow

How the architecture produces a verified outcome.

  1. 01Intent
  2. 02Plan
  3. 03Route
  4. 04Execute
  5. 05Verify
  6. 06Release
  7. 07Learn

Release requires approval of the exact Candidate. Learning proposes improvements; it does not silently change the live composition.

THE PRODUCTVerified outcome

Quality · security · reliability · cost per verified outcome · human effort

One enterprise platform supplies nine shared services, including Mission Control as the meta-factory control plane. A portfolio starts with Software Delivery and adds Modernization, Security Remediation or other factories only when their governed contracts differ. Factories compose shared Agents, Harnesses, Tools and Skills, Models and Execution Profiles. These architectural layers are dependencies, not sequential runtime steps. The separate delivery flow is Intent, Plan, Route, Execute, Verify, Release and Learn. Approval controls release; the product is a verified outcome.

Original reference illustration ↗ · Its scale figures are illustrative, not a capacity benchmark.

One platform.Composable factories.Reusable capabilities.

Organizational scale and factory count are different dimensions. Builder scale is primarily a scheduling, quota, and concurrency problem. Repository scale is primarily a context, policy, ownership, and configuration problem. Workload scale is handled through WorkOrders, Tasks, Attempts, queues, sandboxes, and horizontal execution. Create another Factory Definition only when the governed outcome contract materially changes.

Builder scale

Scheduling, quotas, tenant fairness, concurrency, and backpressure

Repository scale

Repository intelligence, ownership, policy, language, toolchain, and Execution Profiles

Workload scale

Durable WorkOrders, Tasks, Attempts, queues, sandbox capacity, and horizontal execution

From builder intent to a verified outcome.

The builder states the result. Mission Control materializes and coordinates the durable execution contract. Factories perform bounded work; evidence and authority govern what advances.

FDLC / Reference architecture · 03

From intent to a verified outcome.

Mission Control coordinates the ObjectivePlan · decomposition · routing · state · evidence · authority · outcomes
  1. 01IntentObjective / desired outcome
  2. 02PlanWorkOrders / Tasks
  3. 03RouteQualified Factory + capabilities
  4. 04ExecuteGoverned Attempts
  5. 05VerifyIndependent proof
  6. 06ReleaseApproved Candidate
  7. 07LearnOutcome signals / improvements
Execution boundary
Agents and harnesses run bounded Attempts inside governed runtime / sandbox environments.
Approval remains explicit
Before Release, the accountable authority approves the exact Candidate, environment and rollout scope.
Observe the required production and business criteria
BEYOND GENERATED CODEVerified outcome

Accepted behavior, attributable evidence and observed results.

Learning returns through qualification. Outcome signals inform evaluated improvements, not automatic production mutation.

Four views, different responsibilities
Factory Development Lifecycle
Design, qualify, govern, operate and improve the factory itself.
Enterprise delivery flow
The seven-step summary shown here; the Guide’s value stream is another teaching view.
Execution / runtime lifecycle
WorkOrders contain Tasks; Attempts can run, block, retry, recover or stop.
Evidence / verification / approval protocol
Proof establishes eligibility; approval authorizes a controlled transition.
Read diagram description

Mission Control coordinates an Objective. Intent defines the desired outcome. Plan decomposes it into WorkOrders and Tasks. Route selects qualified factories and capabilities. Execute runs governed Attempts in bounded environments. Verify checks independent proof. Release promotes the exact approved Candidate. Learn uses observed outcome signals to propose evaluated improvements. The delivered product is a verified outcome; required production criteria must be observed. The seven-step enterprise summary does not replace the factory evolution lifecycle, detailed runtime states, or evidence and approval protocol.

Reference architecture · Availability and implementation require qualification.

From intent to a verified outcome. — full-size
Mission Control coordinates the ObjectivePlan · decomposition · routing · state · evidence · authority · outcomes
  1. 01IntentObjective / desired outcome
  2. 02PlanWorkOrders / Tasks
  3. 03RouteQualified Factory + capabilities
  4. 04ExecuteGoverned Attempts
  5. 05VerifyIndependent proof
  6. 06ReleaseApproved Candidate
  7. 07LearnOutcome signals / improvements
Execution boundary
Agents and harnesses run bounded Attempts inside governed runtime / sandbox environments.
Approval remains explicit
Before Release, the accountable authority approves the exact Candidate, environment and rollout scope.
Observe the required production and business criteria
BEYOND GENERATED CODEVerified outcome

Accepted behavior, attributable evidence and observed results.

Learning returns through qualification. Outcome signals inform evaluated improvements, not automatic production mutation.

Four views, different responsibilities
Factory Development Lifecycle
Design, qualify, govern, operate and improve the factory itself.
Enterprise delivery flow
The seven-step summary shown here; the Guide’s value stream is another teaching view.
Execution / runtime lifecycle
WorkOrders contain Tasks; Attempts can run, block, retry, recover or stop.
Evidence / verification / approval protocol
Proof establishes eligibility; approval authorizes a controlled transition.

Mission Control coordinates an Objective. Intent defines the desired outcome. Plan decomposes it into WorkOrders and Tasks. Route selects qualified factories and capabilities. Execute runs governed Attempts in bounded environments. Verify checks independent proof. Release promotes the exact approved Candidate. Learn uses observed outcome signals to propose evaluated improvements. The delivered product is a verified outcome; required production criteria must be observed. The seven-step enterprise summary does not replace the factory evolution lifecycle, detailed runtime states, or evidence and approval protocol.

Read the stage responsibilities
  1. 01

    Intent

    Describe the outcome, scope, constraints, and acceptance criteria from any approved entry point. Repository and organizational context ground the request; intent alone grants no authority.

  2. 02

    Plan

    Mission Control classifies the objective and materializes a durable Plan of WorkOrders, dependencies, verification contracts, budgets, stop conditions, and decision points.

  3. 03

    Route

    Filter for policy, authorization, compatibility, and qualification first. Select and pin the eligible Factory Version and Execution Profile for each WorkOrder.

  4. 04

    Execute

    A factory supervisor composes bounded Tasks from reusable agents, harnesses, tools, model routes, context, and execution infrastructure. Attempts produce attributable Candidates.

  5. 05

    Verify

    Independent verification checks each WorkOrder locally and checks the integrated Candidate globally against the Objective and current upstream artifacts.

  6. 06

    Release

    The accountable authority reviews evidence and approves the exact artifact, environment, rollout scope, and rollback conditions before controlled delivery acts.

  7. 07

    Learn

    Observe production and business outcomes. Attribute quality, time, cost, and human effort to the composition; qualify improvements as new versions instead of silently changing production.

One control plane and one governed capability ecosystem.

Factories consume common platform services instead of duplicating orchestration, identity, inference, context, sandboxes, observability, policy, and evidence systems.

FDLC / Reference architecture · 06

Share the platform. Specialize the outcomes.

Anti-pattern / duplicated ownership

A stack for every team.

Team A
  • Agent stack
  • Model integration
  • Context / RAG
  • Runtime
  • Credentials
  • Observability
  • Policy / Security
  • Verification
  • Evidence / Audit
  • Qualification
Team B
  • Agent stack
  • Model integration
  • Context / RAG
  • Runtime
  • Credentials
  • Observability
  • Policy / Security
  • Verification
  • Evidence / Audit
  • Qualification
Team C
  • Agent stack
  • Model integration
  • Context / RAG
  • Runtime
  • Credentials
  • Observability
  • Policy / Security
  • Verification
  • Evidence / Audit
  • Qualification

Repeated integrations, credentials, control planes and proof systems increase the governance and operating burden.

Shared foundation / explicit boundaries

One governed platform.

1

Shared Enterprise Platform

Mission Control coordinates; common services govern.

  • Identity
  • Models
  • Context
  • Runtime
  • Policy / Security
  • Observability
  • Verification
  • Evidence / Audit
Shared services + qualified capabilities
Reusable capability ecosystem
Agents · Harnesses · Models · Tools / Skills · Execution Profiles
Compose for distinct outcome contracts
Factory A
Outcome A
Factory B
Outcome B
Factory C
Outcome C

Illustrative factories, not one factory per team. Share services while preserving tenant, policy and authority boundaries.

SCALE BUILDERS · REPOSITORIES · WORKLOADS · OUTCOMESScale workloads, not infrastructure duplication.

Add a factory only when its governed outcome contract is materially different.

Read diagram description

The anti-pattern duplicates an agent stack, model integration, context, runtime, credentials, observability, policy, verification, evidence and qualification for Teams A, B and C. The preferred architecture centralizes those common services under one governed enterprise platform and reusable capability ecosystem. Factories A, B and C compose qualified capabilities for distinct outcome contracts while preserving tenant and authority boundaries. Increase builders, repositories, concurrency and workloads without creating another control plane or factory for every team.

Reference architecture · Availability and implementation require qualification.

Share the platform. Specialize the outcomes. — full-size
Anti-pattern / duplicated ownership

A stack for every team.

Team A
  • Agent stack
  • Model integration
  • Context / RAG
  • Runtime
  • Credentials
  • Observability
  • Policy / Security
  • Verification
  • Evidence / Audit
  • Qualification
Team B
  • Agent stack
  • Model integration
  • Context / RAG
  • Runtime
  • Credentials
  • Observability
  • Policy / Security
  • Verification
  • Evidence / Audit
  • Qualification
Team C
  • Agent stack
  • Model integration
  • Context / RAG
  • Runtime
  • Credentials
  • Observability
  • Policy / Security
  • Verification
  • Evidence / Audit
  • Qualification

Repeated integrations, credentials, control planes and proof systems increase the governance and operating burden.

Shared foundation / explicit boundaries

One governed platform.

1

Shared Enterprise Platform

Mission Control coordinates; common services govern.

  • Identity
  • Models
  • Context
  • Runtime
  • Policy / Security
  • Observability
  • Verification
  • Evidence / Audit
Shared services + qualified capabilities
Reusable capability ecosystem
Agents · Harnesses · Models · Tools / Skills · Execution Profiles
Compose for distinct outcome contracts
Factory A
Outcome A
Factory B
Outcome B
Factory C
Outcome C

Illustrative factories, not one factory per team. Share services while preserving tenant, policy and authority boundaries.

SCALE BUILDERS · REPOSITORIES · WORKLOADS · OUTCOMESScale workloads, not infrastructure duplication.

Add a factory only when its governed outcome contract is materially different.

The anti-pattern duplicates an agent stack, model integration, context, runtime, credentials, observability, policy, verification, evidence and qualification for Teams A, B and C. The preferred architecture centralizes those common services under one governed enterprise platform and reusable capability ecosystem. Factories A, B and C compose qualified capabilities for distinct outcome contracts while preserving tenant and authority boundaries. Increase builders, repositories, concurrency and workloads without creating another control plane or factory for every team.

Mission Control

Objective, Plan, WorkOrder, dependency, routing, evidence, authority, and outcome coordination

Identity and access

SSO/OIDC, provisioning, RBAC/ABAC, workload identity, delegated authority, and short-lived credentials

Capability registry

Versioned agents, harnesses, tools, skills, model routes, context providers, verifiers, and execution backends

Model gateway

Provider-independent logical routes, policy, quotas, fallbacks, regional constraints, quality, latency, and cost

Context intelligence

Authorized code and knowledge retrieval with ACL filtering, provenance, reranking, compaction, and token budgets

Execution control

Queues, schedulers, isolated sandboxes, resource and network limits, ephemeral credentials, and artifact capture

Observability and cost

Objective-level traces across WorkOrders, Attempts, inference, tools, verification, human effort, and accepted outcomes

Policy and compliance

External enforcement of model, tool, data, network, autonomy, residency, risk, DLP, and release controls

Evidence and audit

Artifact lineage, hashes, tests, scans, policy results, verifier decisions, approvals, and immutable audit events

Mission Control is the meta-factory control plane. It owns Objective → Plan → WorkOrders → routing → state → evidence → authority → outcomes, including the cross-factory dependency graph. Factories do not form an uncontrolled peer-to-peer orchestration network. Every Objective, WorkOrder, Task, Attempt, tool call, and consequential action remains attributable to a human or service principal and bounded by delegated authority.

Inference is not execution, and policy is not a prompt. Logical model routes select approved inference under quality, cost, availability, and regional constraints. Actual code changes, tests, scans, and builds run in isolated execution environments with filesystem, network, resource, and credential controls. Gateways, brokers, sandboxes, and release boundaries enforce policy outside the model.

Build and qualify capabilities for reuse across factory compositions.

Agent count, model count, profile count, and factory count are independent. The same qualified coding agent or test harness can participate in several factories under different Plans, policies, profiles, and verification contracts.

Agents

Reusable reasoning roles for planning, coding, testing, research, security analysis, review, and verification

Harnesses

Controlled context, tools, state, retries, budgets, recovery, and stopping conditions around Tasks and agents

Tools and skills

Governed Git, issue tracking, CI/CD, scanners, build systems, APIs, MCP services, and domain knowledge

Models and inference

Qualified logical routes across commercial, open, and specialized models without making a provider the factory identity

Execution Profiles

Versioned runtime, toolchain, sandbox, network, resource, context, autonomy, and verification settings

Keep the boundaries clear. An agent is a reasoning role. A harness controls execution around a Task or agent. A model supplies inference. An Execution Profile absorbs repository, runtime, environment, and risk variation. A factory owns a stable class of governed outcomes.

Start with a broad default. Add factories only when evidence justifies them.

A Factory Definition carries an outcome contract, ownership, planning semantics, capability composition, qualification, verification, authority, service objectives, and lifecycle. A different workflow or implementation technique alone does not justify another factory.

Software Delivery / broad default

Features, defects, refactoring, tests, dependency updates, routine security fixes, release preparation, and approved deployments

Boundary: One outcome contract can contain many workflows and reusable capability routes.

Modernization / when justified

Migration waves, framework and language changes, platform upgrades, compatibility analysis, and repository transformation

Boundary: Separate only when ownership, lifecycle, qualification, or exception handling materially differs from normal delivery.

Security Remediation / when justified

Enterprise vulnerability discovery, remediation, exception tracking, verification, reporting, and continuous risk reduction

Boundary: Separate when risk, evidence, compliance, sandbox, or authority requirements form a distinct operating contract.

Additional factories / evidence led

Reliability, test engineering, delivery, data migration, accessibility, compliance, or domain-specific outcomes

Boundary: Create one only when outcome semantics, ownership, qualification, governance, authority, or lifecycle are materially different.

Factory creation test. Create a separate factory when outcome semantics, ownership, qualification, governance, risk, authority, lifecycle, or verification requirements are materially different. Otherwise use another skill, workflow, harness, capability route, or Execution Profile inside the existing factory.

Three decisions, with qualification before optimization.

A routing score can rank eligible choices. It cannot override policy, missing qualification, expired evidence, or the builder’s authority.

FDLC / Reference architecture · 04

Three levels. Qualification first.

Objective → Mission ControlTranslate the desired outcome into a governed Plan.
1

Objective routing

Determine participating factories from the Objective’s requirements.

Mission Control coordinates the cross-factory Plan.

Decompose into WorkOrders
2

WorkOrder routing

Select the qualified Factory / immutable Factory Version.

Pin ownership and the approved Execution Profile.

Decompose into bounded Tasks
3

Task routing

Select a qualified capability combination.

  • Agent
  • Harness
  • Model
  • Tools / Skills
  • Execution Profile

Objective participation ≠ Factory selection ≠ Agent selection ≠ Model routing. Model routing supplies inference inside the broader qualified composition.

Read diagram description

An Objective enters Mission Control. Level one determines participating factories. The Plan decomposes into WorkOrders; level two selects and pins qualified Factory Versions and profiles. WorkOrders contain Tasks; level three selects qualified Agent, Harness, Model, Tool or Skill and Execution Profile combinations. At every level, requirements pass through policy, authorization, compatibility and qualification filtering before eligible candidates are ranked. A selected route is pinned and recorded. No eligible route means blocked or escalated, never an unqualified fallback.

Reference architecture · Availability and implementation require qualification.

Three levels. Qualification first. — full-size
Objective → Mission ControlTranslate the desired outcome into a governed Plan.
1

Objective routing

Determine participating factories from the Objective’s requirements.

Mission Control coordinates the cross-factory Plan.

Decompose into WorkOrders
2

WorkOrder routing

Select the qualified Factory / immutable Factory Version.

Pin ownership and the approved Execution Profile.

Decompose into bounded Tasks
3

Task routing

Select a qualified capability combination.

  • Agent
  • Harness
  • Model
  • Tools / Skills
  • Execution Profile

Objective participation ≠ Factory selection ≠ Agent selection ≠ Model routing. Model routing supplies inference inside the broader qualified composition.

An Objective enters Mission Control. Level one determines participating factories. The Plan decomposes into WorkOrders; level two selects and pins qualified Factory Versions and profiles. WorkOrders contain Tasks; level three selects qualified Agent, Harness, Model, Tool or Skill and Execution Profile combinations. At every level, requirements pass through policy, authorization, compatibility and qualification filtering before eligible candidates are ranked. A selected route is pinned and recorded. No eligible route means blocked or escalated, never an unqualified fallback.

Which capabilities does the outcome require?

Mission Control and the planner propose modernization, security, testing, delivery, and reliability work.

Which qualified factory can do this work?

The Factory Router selects an eligible, immutable Factory Version and an approved Execution Profile.

Which qualified resources should perform this step?

The Capability Router selects skills, model routes, harnesses, tools, and context within the WorkOrder’s authority.

Modernize payments to Java 21, remediate vulnerabilities, improve tests, and deploy safely.

The planner proposes the decomposition. Approval binds the exact Plan revision. Mission Control can recover from durable records even if the planner’s session is gone.

  1. WO-101 · AnalyzeEstablish repository and dependency baselines.
  2. WO-102 · ModernizeConsume the verified analysis and produce the migration Candidate.
  3. WO-103 · Secure + WO-104 · TestsRun in parallel only on isolated, pinned inputs. Combine their changes and recheck the integrated result.
  4. WO-105 · VerifyCheck the combined Candidate after both required branches pass.
  5. Release authorityApprove the exact artifact, environment, rollout scope, and rollback conditions.
  6. WO-106 · DeployExecute the authorized release through controlled delivery tooling.
  7. WO-107 · ValidateObserve production health and confirm the remaining objective criteria.

Changed inputs invalidate assumptions. If modernization replaces artifact A with artifact B, downstream evidence about A does not prove B. Mission Control identifies affected WorkOrders, blocks stale handoffs, and requires re-verification. Parallel agents do not share an uncontrolled mutable workspace.

Local PASS does not imply objective PASS.

Execution produces a Candidate. Verification supports or rejects its claims. Release authorization remains a separate decision.

FDLC / Reference architecture · 05

Evidence earns progress. Approval grants authority.

Execution
A producer Agent / Harness runs a governed Attempt.
Artifact + Evidence
Candidate digest + input lineage + tests, scans, builds, traces and policy results.
Bind proof to exact inputs and Candidate identities
1

Independent Verification

A producer’s completion claim is not its own proof.

Use deterministic checks, specialized evaluators and human judgment as required. A second model alone does not establish independence.

Local Verification
Does each WorkOrder / Task satisfy its acceptance contract on the exact inputs it consumed?
Global Verification
Does the exact integrated Candidate satisfy the Objective contract with current upstream proof?
Both required proof scopes converge
Exact integrated Candidate
Required checks pass against the same artifact digest and current inputs. Retain verifier identity, result and evidence references.
Current passing evidence
Approval Gate
The accountable human or explicitly authorized policy grants the next transition for this Candidate, environment and scope.
Approved Candidate only
CONTROLLED PROMOTIONRelease

Observe production criteria before closing the Objective.

Read diagram description

Execution produces an artifact and evidence tied to exact Candidate and input identities. Independent local verification checks WorkOrder and Task contracts; global verification checks the integrated Candidate against the Objective. Both required scopes need current passing proof for the exact integrated Candidate before approval can authorize release. Missing, failed or stale evidence blocks release. Changed upstream artifacts invalidate affected downstream proof. Correct or re-execute within policy, then return to independent verification and obtain fresh approval for a changed Candidate. Release is controlled promotion, followed by required production observation.

Reference architecture · Availability and implementation require qualification.

Evidence earns progress. Approval grants authority. — full-size
Execution
A producer Agent / Harness runs a governed Attempt.
Artifact + Evidence
Candidate digest + input lineage + tests, scans, builds, traces and policy results.
Bind proof to exact inputs and Candidate identities
1

Independent Verification

A producer’s completion claim is not its own proof.

Use deterministic checks, specialized evaluators and human judgment as required. A second model alone does not establish independence.

Local Verification
Does each WorkOrder / Task satisfy its acceptance contract on the exact inputs it consumed?
Global Verification
Does the exact integrated Candidate satisfy the Objective contract with current upstream proof?
Both required proof scopes converge
Exact integrated Candidate
Required checks pass against the same artifact digest and current inputs. Retain verifier identity, result and evidence references.
Current passing evidence
Approval Gate
The accountable human or explicitly authorized policy grants the next transition for this Candidate, environment and scope.
Approved Candidate only
CONTROLLED PROMOTIONRelease

Observe production criteria before closing the Objective.

Execution produces an artifact and evidence tied to exact Candidate and input identities. Independent local verification checks WorkOrder and Task contracts; global verification checks the integrated Candidate against the Objective. Both required scopes need current passing proof for the exact integrated Candidate before approval can authorize release. Missing, failed or stale evidence blocks release. Changed upstream artifacts invalidate affected downstream proof. Correct or re-execute within policy, then return to independent verification and obtain fresh approval for a changed Candidate. Release is controlled promotion, followed by required production observation.

Did this factory satisfy its contract?

  • Exact input and Candidate artifact identities
  • WorkOrder acceptance criteria and required evidence
  • Build, tests, scans, policy, and artifact integrity
  • Independent verifier Attempt and attributable verdict

A failure enters a bounded remediation path. Missing evidence is a blocked or incomplete result.

Does the composition achieve the outcome?

  • Required upstream WorkOrders complete with current evidence
  • Correct versions combined into one integrated Candidate
  • End-to-end behavior, regression, security, and performance
  • Objective acceptance criteria and release readiness

Pre-release verification establishes eligibility. If the objective includes production outcomes, completion also requires post-release observation.

Independent verification is more than a second model. Prefer deterministic checks for builds, tests, policy, and digests. Use specialized evaluators and human review where judgment is required. Shared prompts, models, or missing context can create correlated failures even across separate agents.

Qualify immutable compositions and activate them for a declared scope.

A Factory Definition names the governed outcome capability. A Factory Version identifies its immutable composition. An Execution Profile specializes the qualified operating envelope for a workload and environment.

FDLC / Reference architecture · 02

What makes a Factory?

Factory Definition / governed design

An outcome contract, assembled into a system.

The definition declares the result, responsibilities, capabilities and proof required.

1

Outcome Contract

What must be true, for whom, and how success is accepted.

Scope · owner · acceptance criteria · risk · authority

Defines the composition
Workflow
The ordered and conditional work, dependencies and stop rules.
Qualified Capabilities
  • Agent
  • Harness
  • Tools / Skills
  • Model

Reusable components selected for this workload.

Context
Authorized instructions, knowledge and current work state.
Execution Profile
Versioned runtime, sandbox, network, credentials and resource limits.
Policy
Permitted actions and authority enforced outside the model.
Verification
Independent checks against the acceptance contract.
Evidence Requirements
Tests, scans, provenance, traces and attributable decisions.
Pin the exact components and configuration
Composition qualification
Evaluate the assembled system for a declared workload and policy scope. Qualified parts alone do not qualify their interactions.
Only a passing composition can advance
IMMUTABLE QUALIFIED COMPOSITIONFactory Version

Activation and execution still require authorization. Changes return through qualification.

A Factory owns an outcome. An Agent reasons; a Harness bounds its loop; a Model supplies inference; Tools act; Skills supply reusable guidance. None alone is the Factory.

Read diagram description

A Factory Definition describes a governed composition around an Outcome Contract. It combines Workflow, qualified Agents, Harnesses, Tools and Skills, Models, Context, an Execution Profile, Policy, Verification and Evidence Requirements. Pin the exact configuration and qualify its interactions as a composition for a declared workload. Passing qualification produces an immutable qualified Factory Version. Activation and execution still require authorization; changes return through qualification. A component or workflow alone is not the factory.

Reference architecture · Availability and implementation require qualification.

What makes a Factory? — full-size
Factory Definition / governed design

An outcome contract, assembled into a system.

The definition declares the result, responsibilities, capabilities and proof required.

1

Outcome Contract

What must be true, for whom, and how success is accepted.

Scope · owner · acceptance criteria · risk · authority

Defines the composition
Workflow
The ordered and conditional work, dependencies and stop rules.
Qualified Capabilities
  • Agent
  • Harness
  • Tools / Skills
  • Model

Reusable components selected for this workload.

Context
Authorized instructions, knowledge and current work state.
Execution Profile
Versioned runtime, sandbox, network, credentials and resource limits.
Policy
Permitted actions and authority enforced outside the model.
Verification
Independent checks against the acceptance contract.
Evidence Requirements
Tests, scans, provenance, traces and attributable decisions.
Pin the exact components and configuration
Composition qualification
Evaluate the assembled system for a declared workload and policy scope. Qualified parts alone do not qualify their interactions.
Only a passing composition can advance
IMMUTABLE QUALIFIED COMPOSITIONFactory Version

Activation and execution still require authorization. Changes return through qualification.

A Factory owns an outcome. An Agent reasons; a Harness bounds its loop; a Model supplies inference; Tools act; Skills supply reusable guidance. None alone is the Factory.

A Factory Definition describes a governed composition around an Outcome Contract. It combines Workflow, qualified Agents, Harnesses, Tools and Skills, Models, Context, an Execution Profile, Policy, Verification and Evidence Requirements. Pin the exact configuration and qualify its interactions as a composition for a declared workload. Passing qualification produces an immutable qualified Factory Version. Activation and execution still require authorization; changes return through qualification. A component or workflow alone is not the factory.

Develop → Qualify → Promote → Activate → Observe → Improve

Pin the supervisor recipe, skills, model routes, harnesses, tools, context policies, sandbox, and verification contract. Qualify the composition as well as its components. A published version is not automatically eligible for routing.

Improvements create new candidates. Suspending a bad version stops new admissions; routing can return to a previously qualified version that remains eligible. Reverting factory routing does not undo an application deployment or a database change.

Make the operating requirements explicit before scaling.

Use these as architecture and procurement requirements to validate together. Availability, deployment options, support, and commercial commitments must be confirmed for the agreed scope.

Identity and isolation

Define tenant and business-unit boundaries, SSO and provisioning requirements, service identities, least privilege, sandbox isolation, and access to approved knowledge.

Policy and evidence

Bind approvals to Plan and Candidate revisions. Set retention, residency, evidence export, exception ownership, and audit requirements before admitting sensitive work.

Capacity and recovery

Budget at Objective, WorkOrder, and Attempt levels. Use queue fairness, concurrency quotas, cancellation, retry ceilings, durable recovery, and explicit blocked states.

Release and operations

Name the release and incident owners. Define deployment topology, rollout gates, observation windows, rollback procedures, and suspension of unsafe factory versions.

Measure accepted outcomes and the effort to achieve them.

Track objective success, first-attempt verification, escaped defects, rollback and recovery, end-to-end cycle time, human review minutes, and adoption. Attribute inference, compute, tools, verification, retries, and human intervention to the outcome.

Compare similar workloads over a declared observation window. Report sample size and missing data. Cost per accepted outcome is undefined when no outcomes are accepted; activity and token volume alone do not establish business value.

Use the measurement contract →

Prove one workflow. Expand on evidence.

  1. 01

    Scope

    Select one bounded workflow and representative repositories. Record today’s delivery time, defects, cost, and human effort; agree on acceptance and stop conditions.

  2. 02

    Prove

    Run a constrained pilot with independent verification, artifact lineage, failure recovery, and human release authority. Compare outcomes with the baseline.

  3. 03

    Expand

    Admit additional repositories, teams, and risk classes only after qualification. Reuse definitions and profiles; increase concurrency within measured capacity.

  4. 04

    Operate

    Review service health, adoption, escaped defects, cost per accepted outcome, and review burden. Promote improvements through controlled evaluation and rollout.

Bring your enterprise delivery requirements.

For large organizations, contact FDLC Enterprise at support@fdlc.ai for details on pricing, design partnerships, and a rollout aligned to your environment.

Prepare your target workflows, repository and team scope, expected workload and concurrency, security and residency requirements, integration needs, support expectations, and success measures. These inputs help scope a discussion; they are not published pricing units.

FDLC Enterprise is a proposed commercial offering and is not generally available. Pricing, service levels, deployment options, and packaged availability require a scoped agreement. The FDLC framework and guide remain open.