Scale dimension 1
Builder scale
Scheduling, quotas, tenant fairness, concurrency, and backpressure
FDLC EnterpriseDesign partnership
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.
Enterprise operating model
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.
Centralize the infrastructure.
Compose the work.
Reuse qualified capabilities.
Common services for every factory. One governed control plane.
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.
Outcome-specific operating units. Start with a broad default.
Additional factories only when justified: materially different outcome semantics, ownership, qualification, governance, authority, verification or risk.
Build once. Qualify. Govern. Reuse within the approved scope.
How the architecture produces a verified outcome.
Release requires approval of the exact Candidate. Learning proposes improvements; it does not silently change the live composition.
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.
Reference architecture · Availability and implementation require qualification.
Original reference illustration ↗ · Its scale figures are illustrative, not a capacity benchmark.
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.
Scale dimension 1
Scheduling, quotas, tenant fairness, concurrency, and backpressure
Scale dimension 2
Repository intelligence, ownership, policy, language, toolchain, and Execution Profiles
Scale dimension 3
Durable WorkOrders, Tasks, Attempts, queues, sandbox capacity, and horizontal execution
Example flow
The builder states the result. Mission Control materializes and coordinates the durable execution contract. Factories perform bounded work; evidence and authority govern what advances.
Accepted behavior, attributable evidence and observed results.
Learning returns through qualification. Outcome signals inform evaluated improvements, not automatic production mutation.
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.
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.
Mission Control classifies the objective and materializes a durable Plan of WorkOrders, dependencies, verification contracts, budgets, stop conditions, and decision points.
Filter for policy, authorization, compatibility, and qualification first. Select and pin the eligible Factory Version and Execution Profile for each WorkOrder.
A factory supervisor composes bounded Tasks from reusable agents, harnesses, tools, model routes, context, and execution infrastructure. Attempts produce attributable Candidates.
Independent verification checks each WorkOrder locally and checks the integrated Candidate globally against the Objective and current upstream artifacts.
The accountable authority reviews evidence and approves the exact artifact, environment, rollout scope, and rollback conditions before controlled delivery acts.
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.
Shared enterprise infrastructure
Factories consume common platform services instead of duplicating orchestration, identity, inference, context, sandboxes, observability, policy, and evidence systems.
Repeated integrations, credentials, control planes and proof systems increase the governance and operating burden.
Mission Control coordinates; common services govern.
Illustrative factories, not one factory per team. Share services while preserving tenant, policy and authority boundaries.
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.
Reference architecture · Availability and implementation require qualification.
Objective, Plan, WorkOrder, dependency, routing, evidence, authority, and outcome coordination
SSO/OIDC, provisioning, RBAC/ABAC, workload identity, delegated authority, and short-lived credentials
Versioned agents, harnesses, tools, skills, model routes, context providers, verifiers, and execution backends
Provider-independent logical routes, policy, quotas, fallbacks, regional constraints, quality, latency, and cost
Authorized code and knowledge retrieval with ACL filtering, provenance, reranking, compaction, and token budgets
Queues, schedulers, isolated sandboxes, resource and network limits, ephemeral credentials, and artifact capture
Objective-level traces across WorkOrders, Attempts, inference, tools, verification, human effort, and accepted outcomes
External enforcement of model, tool, data, network, autonomy, residency, risk, DLP, and release controls
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.
Reusable capabilities
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.
Reusable reasoning roles for planning, coding, testing, research, security analysis, review, and verification
Controlled context, tools, state, retries, budgets, recovery, and stopping conditions around Tasks and agents
Governed Git, issue tracking, CI/CD, scanners, build systems, APIs, MCP services, and domain knowledge
Qualified logical routes across commercial, open, and specialized models without making a provider the factory identity
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.
Outcome-specific operating units
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.
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.
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.
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.
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.
Routing and dependencies
A routing score can rank eligible choices. It cannot override policy, missing qualification, expired evidence, or the builder’s authority.
Determine participating factories from the Objective’s requirements.
Mission Control coordinates the cross-factory Plan.
Select the qualified Factory / immutable Factory Version.
Pin ownership and the approved Execution Profile.
Select a qualified capability combination.
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.
Reference architecture · Availability and implementation require qualification.
Level 1 / Objective
Mission Control and the planner propose modernization, security, testing, delivery, and reliability work.
Level 2 / WorkOrder
The Factory Router selects an eligible, immutable Factory Version and an approved Execution Profile.
Level 3 / Task
The Capability Router selects skills, model routes, harnesses, tools, and context within the WorkOrder’s authority.
Worked objective
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.
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.
Two levels of evidence
Execution produces a Candidate. Verification supports or rejects its claims. Release authorization remains a separate decision.
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.
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.
Reference architecture · Availability and implementation require qualification.
Local / WorkOrder
A failure enters a bounded remediation path. Missing evidence is a blocked or incomplete result.
Global / Objective
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.
Factory versioning
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.
The definition declares the result, responsibilities, capabilities and proof required.
What must be true, for whom, and how success is accepted.
Scope · owner · acceptance criteria · risk · authority
Reusable components selected for this workload.
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.
Reference architecture · Availability and implementation require qualification.
Version lifecycle
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.
Enterprise readiness
Use these as architecture and procurement requirements to validate together. Availability, deployment options, support, and commercial commitments must be confirmed for the agreed scope.
Define tenant and business-unit boundaries, SSO and provisioning requirements, service identities, least privilege, sandbox isolation, and access to approved knowledge.
Bind approvals to Plan and Candidate revisions. Set retention, residency, evidence export, exception ownership, and audit requirements before admitting sensitive work.
Budget at Objective, WorkOrder, and Attempt levels. Use queue fairness, concurrency quotas, cancellation, retry ceilings, durable recovery, and explicit blocked states.
Name the release and incident owners. Define deployment topology, rollout gates, observation windows, rollback procedures, and suspension of unsafe factory versions.
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 →Recommended adoption path
Select one bounded workflow and representative repositories. Record today’s delivery time, defects, cost, and human effort; agree on acceptance and stop conditions.
Run a constrained pilot with independent verification, artifact lineage, failure recovery, and human release authority. Compare outcomes with the baseline.
Admit additional repositories, teams, and risk classes only after qualification. Reuse definitions and profiles; increase concurrency within measured capacity.
Review service health, adoption, escaped defects, cost per accepted outcome, and review burden. Promote improvements through controlled evaluation and rollout.
FDLC Enterprise / Pricing and scope
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.