Models reason.
Agents act.
Selected for the exact Work Order by capability and operating constraints.
- Task and complexity fit
- Quality and risk profile
- Latency and availability
- Cost per verified outcome
Reference architecture / 02
Six areas. Explicit boundaries.
An AI software factory is a system of responsibilities. The architecture makes each responsibility visible so teams can decide what to build, buy, govern, verify, and operate.
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.
Trust constrains every area. Learning closes the loop only through governed promotion. The model is replaceable; the control contract is not.
Learn the fifty core concepts → Open the canonical glossary →
The control boundary
Intelligence can change. Authority cannot be implicit.
Models reason and agents act, but neither should own identity, permission, authoritative state, release policy, or the evidence used to judge its work. Those responsibilities belong to the factory around them.
Models reason.
The factory governs.
Durable controls remain outside the model and apply to every provider, agent, and tool.
- Identity and delegated authority
- Policy, budget, and routing
- State, leases, and recovery
- Evidence, decisions, and audit
Operation stays bounded.
The Harness governs one Agent, the Runtime hosts it, and the Sandbox isolates its effects.
- Explicit Agent Loop
- Scoped capabilities and file access
- Short-lived credentials
- Network, time, and resource limits
Authority flows down →Allow intelligence to vary. Always bound authority.← Evidence flows back
Capability supply should evolve as better options emerge.
The operating record must survive every capability substitution.
Every Attempt returns attributable evidence. No producing system may promote its own result.
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.
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.
Canonical execution vocabulary
Name the boundary before assigning the responsibility.
Most disagreement about agent harnesses is a boundary disagreement. FDLC separates the worker, its iteration loop, its operating envelope, workflow coordination, execution infrastructure, isolation, and enterprise authority so each has a clear owner, lifecycle, identity, and qualification boundary.
Model
Inference engine. Supplies intelligence; it is not the worker or authority.
What reasoning or generation is available?
Agent
Goal-directed worker. Uses model intelligence, instructions, context, state, and capabilities.
Who is pursuing the bounded task?
Agent Loop
Iteration cycle. Loads state, selects, acts, observes, evaluates, replans, and terminates.
How does one Agent make progress and stop?
Agentic SDK
Developer toolkit. May supply Agent definitions, loops, tools, handoffs, guardrails, sessions, tracing, orchestration helpers, or Runtime integration; it is not itself the Agent, Harness, Runtime, Orchestrator, or Control Plane.
Which reusable primitives or implementations are used to construct the agentic application?
Agent Harness
Operating envelope. Governs context, models, tools, working state, permissions, budgets, recovery, telemetry, and stopping.
How is the Agent allowed to operate?
Coding Harness
Software-engineering Harness. Specializes the Agent Harness for code, shell, compiler, test, package, Git, diagnostic, and artifact workflows.
How may an Agent inspect, change, build, and verify a repository?
IDE Harness
Editor-integrated Coding Harness. May use open files, selections, diagnostics, terminal, Git, and approval state; an IDE alone is not a Harness.
Which editor state participates in bounded execution?
Work Graph
Workflow topology. Represents nodes, dependencies, branches, joins, gates, interrupts, cycles, and terminal states.
What work can happen next?
Orchestrator
Durable coordinator. Advances the Work Graph across Agents, Harness invocations, deterministic work, and human waits.
Which eligible node executes next?
Runtime
Execution substrate. Provides process lifecycle, compute, queues, leases, persistence, resume, concurrency, and recovery.
Where and how does execution live and survive?
Sandbox
Isolation boundary. Restricts filesystem, processes, network, credentials, dependencies, and resources.
What can this execution affect?
Capability
Stable operation. Names provider-independent work such as inspect a repository or run tests.
What can the system do?
Capability Implementation
Qualified realization. Binds provider, tool, skill, model, adapter, version, permissions, and evidence.
Which exact implementation performs it?
Control Plane
Enterprise authority. Owns identity, policy, budgets, evidence requirements, decisions, and emergency control.
Who may authorize, revoke, approve, promote, and release?
Factory
Outcome system. Composes people, process, agents, Harnesses, capabilities, Runtime, Trust, delivery, and learning.
How does intent become accepted software?
Factory Platform
Shared enterprise foundation. Supplies Mission Control, identity, policy, registries, orchestration, Runtime, Sandboxes, evaluation, evidence, approvals, and release integration.
Which governed services should many Factories reuse?
Factory Version
Immutable qualified composition. Binds separate Model, Agent, Harness, graph, capability, Runtime, Sandbox, verification, and policy identities without mutable runtime coupling.
Which exact governed composition is eligible to run?
Loop Engineering
Worker-iteration discipline. Improves the Agent Loop inside a bounded unit of work.
Is one Agent choosing, evaluating, replanning, and stopping well?
Graph Engineering
Work-topology discipline. Improves the Work Graph coordinated by the Orchestrator.
Are dependencies, branches, joins, gates, retries, and terminal states correct?
Harness Engineering
Operating-envelope discipline. Improves how an Agent may operate while leaving enterprise authority in the Control Plane.
Are context, tools, state, permissions, budgets, recovery, and validation correct?
AI Harness
Non-canonical external label. Translate it to Model Harness, Agent Harness, Coding Harness, Evaluation Harness, Runtime, Orchestrator, or Control Plane.
Which actual architectural boundary does the speaker mean?
Canonical relationshipControl Plane authorizes an Execution Profile → Orchestrator advances the Work Graph → Agentic SDK may supply implementations → Agent Harness governs one Agent → Agent Loop iterates inside a graph node → Runtime hosts execution → Sandbox isolates effects → Evidence returns for independent judgment
A Harness may enforce a local rule, but the Control Plane owns the identity, policy, approval, budget, and revocation authority behind that rule. A packaged product may implement several boundaries; the immutable identities must remain distinct.
Agentic systems architecture
A toolkit can implement layers. It does not become the system.
Agentic SDKs are useful because they package common agent-building primitives. FDLC keeps the responsibilities separate so adopting an SDK never silently transfers enterprise authority, durable orchestration, runtime ownership, or release control to a library.
- 01Enterprise authority
Control Plane
Determines what may run, where it may run, and with what authority.
- WorkOrder and Factory Version
- Execution Profile
- Authority and policy
- Verification and release
- Observability and audit
ExamplesMission Control · Factory platform · Release management
- 02Work coordination
Orchestrator
Advances the Work Graph across agents, capabilities, deterministic steps, and human decisions.
- Plan and decompose
- Route and assign
- Manage dependencies
- Track durable progress
ExamplesTask orchestrator · Workflow engine · Multi-agent coordination
- 03Developer toolkit
Agentic SDK
Provides reusable primitives and implementations for constructing agentic applications.
- Agent definitions
- Loop and tool abstractions
- Handoffs and guardrails
- Sessions and tracing
- Optional runtime integration
ExamplesOpenAI Agents SDK · Google ADK · LangChain / LangGraph · Custom SDKs
- 04Execution mechanism
Agent Harness
Operates the Agent Loop under explicit context, tool, state, budget, recovery, and stopping controls.
- General Agent Harness
- Coding Harness
- IDE Harness
- Provider-specific adapter
ExamplesHeadless runner · Coding-agent environment · Custom harness
- 05Goal-directed worker
Agent
Binds a bounded objective to instructions, tools, context, memory, policy, and a model profile.
- Objective
- Instructions
- Available capabilities
- Context and memory view
- Escalation behavior
ExamplesCoding agent · Review agent · Research agent
- 06Reasoning engine
Model
Supplies inference, reasoning, generation, classification, and tool-call proposals.
- Generate
- Reason
- Plan
- Propose tool use
ExamplesQualified model route · Code-specialized model · Local model
Key boundary
An Agentic SDK is a construction toolkit. It may provide an Agent Loop, Harness implementation, Work Graph helpers, or Runtime integration. Those supplied parts still require separate identities, qualification evidence, and authority from the Control Plane.
SDKThe toolkit used to construct behavior
A library may supply a Runner, loop, guardrails, tracing, or adapters
HarnessThe machinery that operates one agent
Owns the bounded model → tool → observation cycle for an Attempt
RuntimeThe substrate where execution lives
Owns processes, compute, persistence, resume, and recovery
OrchestratorThe coordinator across work
Advances dependencies, handoffs, waits, joins, and terminal states
Control PlaneThe enterprise authority around execution
Owns identity, policy, budgets, approval, verification, release, and revocation
What this means for FDLC
Control Plane and factory coordination
Mission Control owns governed WorkOrders, resolved execution identities, authority, durable state, verification, acceptance, and release coordination. It may invoke SDK-built components without transferring those decisions to the SDK.
Coding Harness and capability implementation
Fab operates a bounded repository-editing Agent Loop and integrates through Mission Control's Harness adapter contract. Its model adapters and loop are implementation details; Fab has no independent acceptance, publication, or Control Plane authority.
SDK guardrails can enforce behavior inside an execution framework. They do not establish enterprise authority to modify a repository, spend a budget, accept a Candidate, publish a release, or change Production.
Across factories
One objective can require several qualified factories.
Mission Control owns the governed Plan, WorkOrder dependencies, and artifact handoffs. Factory supervisors coordinate Tasks inside their assigned boundary. Local evidence verifies each WorkOrder; global evidence verifies the integrated result.
Capability map
Inspect each area as an operating contract.
Purpose describes why the area exists. Responsibilities and components describe what it owns. Decisions and failure modes reveal what must remain explicit.
01Architecture area
Intent
Define what should happen and how success will be judged.Turn human goals into explicit, reviewable work before execution begins.
Expand areaCollapse area
Architecture area
Intent
Define what should happen and how success will be judged.Responsibilities
- Goals and requirements
- Acceptance criteria linked to verification requirements
- Versioned Plans and dependency graphs
- Prioritization and specification
Common components
- Intent workspace
- Specification store
- Plan registry
- Dependency graph
Required decisions
- What outcome matters?
- What is out of scope?
- What evidence will prove success?
- Who can approve change?
Failure modes
ExpandCollapse
- Ambiguous outcomes
- Plans that are treated as disposable prompts
- Unmeasurable acceptance criteria
- Scope drift after approval
Maturity progression
ExpandCollapse
- L1Prompt
- L2Template
- L3Versioned Plan
- L4Executable specification
- L5Outcome-linked portfolio
Examples
- Dependency upgrade policy
- API migration specification
- Vulnerability remediation acceptance criteria
RelationshipIntent supplies the frozen contract that Harness executes, Trust verifies, and Learning may propose changing only through governance.
02Architecture area
Harness
Turn model intelligence into bounded, observable agent operation.Define how an Agent may use models, context, tools, working state, execution resources, and external systems while keeping workflow coordination, infrastructure, isolation, and enterprise authority explicit.
Expand areaCollapse area
Architecture area
Harness
Turn model intelligence into bounded, observable agent operation.Responsibilities
- Agent Harness operating envelope and Agent Loop
- Work Graph coordination through the Orchestrator
- Runtime lifecycle, durable checkpoints, and recovery
- Sandbox isolation and qualified enforcement points
- Scheduling, leases, quotas, and backpressure
- Bounded retries, cancellation, and reconciliation
Common components
- Agent Harness
- Agent Loop
- Orchestrator and Work Graph
- Runtime
- Sandbox
- Harness adapter
Required decisions
- How may this Agent operate and stop?
- Which graph node is eligible next?
- Where does execution live and survive?
- What isolates effects, and who owns the authority behind each control?
Failure modes
ExpandCollapse
- Calling a loop, runtime, or control plane a harness
- State trapped in model context
- Workflow routing hidden inside one Agent
- Local enforcement mistaken for enterprise authority
- Retrying an unknown external outcome before reconciliation
Maturity progression
ExpandCollapse
- L1Interactive session
- L2Scripted runner
- L3Durable Attempt
- L4Recoverable workflow
- L5Fleet control
Examples
- Fenced Work Order lease
- Checkpointed migration
- Restart-safe verification run
RelationshipThe Harness bounds one Agent. The Orchestrator advances the Work Graph, the Runtime hosts execution, the Sandbox isolates effects, and the Control Plane owns authority. Together they bind Intent, Capability, Model, and Trust into one exact Attempt.
03Architecture area
Capability
Package reusable ways for agents to act in a domain.Make agents, skills, tools, context services, and interfaces versioned, discoverable, and governable.
Expand areaCollapse area
Architecture area
Capability
Package reusable ways for agents to act in a domain.Responsibilities
- Agent definitions
- Versioned skills and tools
- MCP and API contracts
- Authorized, current, attributable context
Common components
- Capability registry
- Agent Factory
- Skill packages
- Tool gateway
- Context adapters
Required decisions
- Can a deterministic tool satisfy this task?
- Which exact capability version is admitted?
- What permissions and context are required?
- How are outputs and capability quality evaluated?
Failure modes
ExpandCollapse
- Prompt folders without ownership
- Tool sprawl
- Implicit permissions
- Capabilities promoted without evals
Maturity progression
ExpandCollapse
- L1Ad hoc prompt
- L2Named skill
- L3Versioned package
- L4Evaluated registry
- L5Governed supply chain
Examples
- Repository research skill
- Dependency modernization agent
- Read-only issue tracker tool
RelationshipCapability is selected from Intent, admitted by Trust, and run by Harness. Model routing is one part of capability selection; some work needs no model.
04Architecture area
Model
Match reasoning capability to the work without provider lock-in.Abstract and route models by capability, quality, latency, cost, and policy.
Expand areaCollapse area
Architecture area
Model
Match reasoning capability to the work without provider lock-in.Responsibilities
- Provider abstraction
- Model selection and routing
- Capability matching
- Fallbacks and cost control
Common components
- Model catalog
- Routing policy
- Evaluation profile
- Fallback chain
- Cost ledger
Required decisions
- What capability does this work require?
- What is the risk ceiling?
- When may a fallback run?
- What result justifies the cost?
Failure modes
ExpandCollapse
- One-model monoculture
- Routing without workload-specific evidence
- Fallback that weakens qualification or policy
- Optimizing token price instead of outcome cost
Maturity progression
ExpandCollapse
- L1Hard-coded model
- L2Manual choice
- L3Policy routing
- L4Evidence-calibrated routing
- L5Outcome-optimized portfolio
Examples
- Low-cost documentation route
- High-reasoning architecture review
- Deterministic fallback for structured checks
RelationshipModel executes inside the Harness, uses Capability and context, and remains constrained by Trust regardless of intelligence.
05Architecture area
Trust
Decide what may run, what can advance, and what requires judgment.Keep authority outside the model and require evidence for consequential state transitions.
Expand areaCollapse area
Architecture area
Trust
Decide what may run, what can advance, and what requires judgment.Responsibilities
- Evaluation and verification
- Policy and security
- Delegated authority
- Evidence, approvals, and oversight
Common components
- Policy engine
- Identity service
- Verification plane
- Evidence store
- Approval control
Required decisions
- Who is acting for whom?
- What exact authority was delegated?
- Do producer and verifier have independent failure modes?
- Does current evidence cover every required criterion?
Failure modes
ExpandCollapse
- Self-verification
- Permissions inferred from content
- Stale evidence or memory overriding current authority
- Averaging a failed hard gate into a passing score
Maturity progression
ExpandCollapse
- L1Trust the response
- L2Human review
- L3Policy gates
- L4Independent verification
- L5Risk-calibrated autonomy
Examples
- Exact-head PR gate
- Security scan receipt
- Human approval for production deployment
RelationshipTrust constrains every other area and separates completion, verification, approval, and release.
06Architecture area
Learning
Improve the factory from validated outcomes under change control.Turn real outcomes, failures, cost, and reviewer decisions into bounded improvement proposals.
Expand areaCollapse area
Architecture area
Learning
Improve the factory from validated outcomes under change control.Responsibilities
- Outcome and feedback capture
- Failure taxonomy
- Experiments and baselines
- Controlled improvement
Common components
- Learning-signal store
- Eval datasets
- Experiment registry
- Promotion workflow
Required decisions
- Is the signal attributable?
- What baseline should change?
- How will regression be detected?
- Who approves promotion?
Failure modes
ExpandCollapse
- Treating memory as learning
- Optimizing on model confidence
- Self-modifying production
- Unversioned prompt drift
Maturity progression
ExpandCollapse
- L1No feedback
- L2Manual lessons
- L3Structured signals
- L4Controlled experiments
- L5Governed continuous learning
Examples
- Failure becomes an eval case
- Routing change tested against a baseline
- Skill revision promoted after canary
RelationshipLearning consumes Trust-approved signals and returns proposed changes to Intent, Capability, Model, or policy—not directly to production.
Context & skills
Treat skills as production dependencies.
A skill changes how an agent works. Give it an owner, pin its version, test its behavior, and control where it can run.
Every version has to earn its place.
- 01PackageVersion + owner
- 02EvaluateTests + holdouts
- 03AuthorizeScope + policy
- 04ObserveRuns + outcomes
Observed failures become new test cases. Revisions repeat evaluation and authorization before rollout.
Separate decisions: admitting a skill does not accept its work or authorize a release.
Inspect the five operating practices
01Context & Skills Engineering
Design specifications, rules, references, and reusable procedures as reviewed, versioned dependencies of agent behavior.
- Apply it
- Give each skill an owner, exact version, trigger and non-trigger conditions, expected outputs, and evaluation cases. Freeze the context supplied to each run.
- Evidence
- Reviewed changes, pinned content digests, and positive and negative tests.
- Watch for
- More context can add conflicting instructions. Resolve conflicts and retrieve only what the task needs.
02Agent Governance, Security & Trust
Control what agents may install and run, and preserve evidence of who authorized each consequential action.
- Apply it
- Separate structural lint, security scanning, install policy, and runtime enforcement. Bind tools, secrets, filesystem and network access to the approved scope.
- Evidence
- Attributable scans, policy decisions, denied actions, and recovery records.
- Watch for
- A security rule written in a skill is not an enforced boundary. A scan score is not a guarantee of safe execution.
03Standardization & Reuse at Scale
Turn repeated work into a shared library teams can maintain and use without silently diverging copies.
- Apply it
- Start with one owned workflow. Pin dependencies, record scan coverage, surface unmanaged copies, and select upgrades explicitly. Roll back future runs without rewriting past evidence.
- Evidence
- Consumers resolving the same digest, observed installations, and upgrade and rollback history.
- Watch for
- A large registry does not prove adoption. Cross-agent packaging does not prove equivalent runtime behavior.
04Continuous Evaluation & Optimization
Establish whether a skill is selected, applied, and useful before treating a revision as an improvement.
- Apply it
- Separate selection tests from forced-use tests. Compare no-skill, current and candidate versions on frozen scenarios and repeated trials. Record failures, verification, review effort, and measured cost.
- Evidence
- Actual execution artifacts and independent criterion checks, with model, harness and rubric provenance.
- Watch for
- Installed is not used. Loaded is not followed. Structural scores and simulated results are not measured performance.
05Tools-in-Action: Real-World Playbooks
Make engineering lessons reproducible through specific accounts of what worked, what failed, and where the evidence stops.
- Apply it
- Publish exact inputs, tools, commands, stop conditions and recovery steps. Separate designed examples, local demos, production pilots, and sustained operation.
- Evidence
- A repeatable walkthrough with artifacts, sample size, limitations, and negative results.
- Watch for
- Do not turn a dashboard or customer logo into a productivity claim. A blocked run can teach a useful lesson without proving success.
Read the complete practices and worked playbook in the Guide →
The worked local example records a harness-version mismatch and zero executed trials. It demonstrates an honest stop condition, not improved performance or production qualification.
Architecture in practice
Six decisions before a factory takes on real work.
Use these checks when designing a new workflow or reviewing an existing one. Each connects a design choice to the evidence needed to operate it. They refine the six architecture areas without adding another lifecycle.
01Operating decision
Qualify the plan before dispatch
Is this a complete, affordable, authorized strategy?
Read decisionCollapse decision
Operating decision
Qualify the plan before dispatch
Problem
A plausible plan can still omit dependencies, proof, budget, or authority and create expensive downstream work.
Architectural decision
Treat the planner as replaceable intelligence and the exact Plan revision as the governed artifact. Admit that revision only after deterministic and risk-based review.
Why it exists
Orchestration, verification, and human decisions need one stable contract even when the planning capability changes.
Governing invariant
No WorkOrder is released from a Plan that lacks traceable acceptance criteria, verification, dependency, authority, currentness, and applicable economic requirements.
Failure behavior
Reject or revise the Plan. Preserve the rejected revision and identify downstream Tasks, Evidence, approvals, and capabilities invalidated by a material change.
Maturity and implementation
FDLC practice. Mission Control has governed, versioned Plans and bounded approval; the broader semantic qualification brief remains a development priority.
Evidence required: An exact Plan revision, criterion-to-verifier mapping, bounded task graph, and recorded decision. Material changes identify which tasks, evidence, and approvals need review again.
Implementation relationshipIntent → Plan revision → WorkOrder readiness
02Operating decision
Separate routing from scheduling
Which capability may do the work, and when can it run?
Read decisionCollapse decision
Operating decision
Separate routing from scheduling
Problem
Static preferences and provider fallbacks can send work to a capability that is cheap or available but unqualified for the task.
Architectural decision
Filter capabilities by workload, complexity, context, policy, quality, latency, reliability, and authority before ranking eligible choices by observed performance and economics. Schedule admitted work separately.
Why it exists
Eligibility protects hard requirements; empirical outcome evidence improves selection without letting scarcity weaken policy.
Governing invariant
A route, fallback, or deterministic tool must satisfy the exact workload's current qualification and authority envelope before it receives work.
Failure behavior
Record why every route was rejected, then wait, use a prequalified fallback, or escalate. Keep unavailable cost and provider data UNKNOWN.
Maturity and implementation
FDLC practice. Mission Control routing is implemented and gated; full live fallback qualification and accepted-outcome economics remain incomplete.
Evidence required: Selected capability and version, rejected alternatives with reasons, qualification scope, resource reservation, and a prequalified fallback or explicit blocked state.
Implementation relationshipWorkOrder → Factory Version → Execution Profile → Attempt
03Operating decision
Recover without repeating consequences
What is known after a crash, timeout, or cancellation?
Read decisionCollapse decision
Operating decision
Recover without repeating consequences
Problem
Repeating a failed operation can duplicate consequential effects, while a late worker can overwrite newer authorized work.
Architectural decision
Recover from durable state using new Attempt identity, fenced leases, checkpoints, idempotency, and authoritative reconciliation of uncertain side effects.
Why it exists
Retries repeat an action; recovery first establishes what happened and what authority remains before choosing a safe next action.
Governing invariant
A stale Attempt cannot commit, and an ambiguous external outcome cannot be treated as failure or retried until reconciled.
Failure behavior
Revoke future authority, preserve the incomplete history, classify the failure, reconcile external effects, and resume only from a proven safe boundary.
Maturity and implementation
FDLC practice. Mission Control has qualified Attempts, fenced leases, and recovery at its documented scope; fleet-scale provider recovery is not claimed.
Evidence required: Durable checkpoint, logical operation identity, current lease, external effect receipt, and the reason a new Attempt is safe. Show uncertainty until it is resolved.
Implementation relationshipAttempt → checkpoint/effect → reconciliation → replacement Attempt
04Operating decision
Keep evidence current and independent
Does this proof support this exact acceptance claim now?
Read decisionCollapse decision
Operating decision
Keep evidence current and independent
Problem
Previously passing evidence can outlive the source, candidate, Plan, Factory Version, policy, runtime, verifier assumptions, or dependencies it proved.
Architectural decision
Bind Evidence to exact subjects and validity conditions, and evaluate currentness before every consequential transition.
Why it exists
Evidence supports a claim only under the conditions in which it was established; currentness turns that rule into an enforceable contract.
Governing invariant
No approval, publication, or release relies on stale, incomplete, mutated, or incorrectly scoped Evidence.
Failure behavior
Invalidate affected eligibility, show the changed condition, and rerun the required independent Verification. Investigate disagreements by criterion and failure mode.
Maturity and implementation
FDLC practice. Mission Control has exact-subject Verification and currentness controls at a qualified bounded scope; broader external-dependency invalidation remains workload-specific.
Evidence required: Criterion coverage, source and content identity, independent verifier result, validity conditions, unresolved findings, and the next authorized decision.
Implementation relationshipCandidate → Verification Subject → Evidence → decision
05Operating decision
Measure acceptance and observed value separately
Did the delivered change solve the user's problem?
Read decisionCollapse decision
Operating decision
Measure acceptance and observed value separately
Problem
Request or token cost can look efficient while retries, review, rejection, release failure, and poor business outcomes make the complete workflow expensive.
Architectural decision
Account separately for request, Attempt, WorkOrder, accepted WorkOrder, released outcome, and observed business outcome. Label every amount ACTUAL, ESTIMATED, or UNKNOWN.
Why it exists
Different denominators answer different decisions. Cost per accepted outcome is useful only when the complete cohort and coverage are visible.
Governing invariant
Missing cost is never zero, undefined denominators never produce a ratio, and technical release success never substitutes for observed user value.
Failure behavior
Keep the result pending or UNKNOWN, identify missing sources and owners, and stop efficiency or ROI claims until the measurement contract is satisfied.
Maturity and implementation
FDLC measurement contract. Mission Control inference accounting has offline qualification; real provider billing and complete accepted-outcome economics remain unqualified.
Evidence required: Release-to-outcome lineage, workload cohort, observation window, result, cost coverage, and explicit ACTUAL, ESTIMATED, or UNKNOWN amounts.
Implementation relationshipAttempt cost → WorkOrder cost → accepted/released outcome → observed value
06Operating decision
Promote and revoke exact factory versions
What earned this composition the right to serve this workload?
Read decisionCollapse decision
Operating decision
Promote and revoke exact factory versions
Problem
Learning signals and passing evaluations can silently change active behavior if promotion is treated as a configuration update rather than a release decision.
Architectural decision
Promote an immutable Factory Version through observe, propose, evaluate, qualify, approve, promote, and observe; restore a separately identified previous version when thresholds fail.
Why it exists
A composition is the unit of behavior. Independent qualification and explicit authority keep learning fast without allowing self-authorization.
Governing invariant
Learning creates Improvement Candidates; it cannot mutate or activate Production Factory behavior.
Failure behavior
Stop new admission for the smallest qualified scope, decide how to treat active work, preserve evidence, and restore only through current authority and a tested target.
Maturity and implementation
FDLC lifecycle. Mission Control Factory Learning is advisory and Incident Command has one narrowly qualified repository pause/restore operation; autonomous Production promotion is not qualified.
Evidence required: Version manifest, representative and adversarial evaluations, permitted workload and autonomy, rollout cohort, stop thresholds, and a tested restoration target.
Implementation relationshipOutcome → Learning Signal → Improvement Candidate → Factory Version decision
Use the design worksheet, recovery drills, and worked example in the Guide →
Production reliability
Treat failure as governed work.
A factory can remain trustworthy while a model, worker, dependency, or release is unhealthy only when impact, containment, effects, recovery, and closure are explicit operating records.
01Operating contract
Contain and preserve
What is the smallest control that stops the harm without destroying the facts?
Read contractCollapse contract
Operating contract
Contain and preserve
Required behavior
Scope containment to the affected Attempt, capability version, route, workflow class, publication path, or environment. Preserve state, effects, evidence, decisions, and configuration before repair when safety permits.
Governing invariant
A control acknowledgement is not enforcement; the observed stop is recorded separately.
Required record
Bind the decision, actor, authority, exact subject, observed effect, evidence, unknowns, deadline, and next permitted action.
02Operating contract
Reconcile before repeating
What actually happened at every external boundary?
Read contractCollapse contract
Operating contract
Reconcile before repeating
Required behavior
Classify each effect as absent, completed, failed, or unknown. Retry only with current authority and an idempotency or reconciliation contract; model multi-system work as a saga with explicit compensation.
Governing invariant
Unknown outcomes never become implicit failures, successes, or permission to retry.
Required record
Bind the decision, actor, authority, exact subject, observed effect, evidence, unknowns, deadline, and next permitted action.
03Operating contract
Operate a declared degraded mode
Which work may continue when assurance or capacity is reduced?
Read contractCollapse contract
Operating contract
Operate a declared degraded mode
Required behavior
Predefine fail-closed, queue, read-only, qualified-fallback, and shutdown behavior for identity, policy, context, model, tool, evidence, telemetry, capacity, and control-state failures.
Governing invariant
Availability cannot weaken the workload's authority, data, quality, or evidence requirements silently.
Required record
Bind the decision, actor, authority, exact subject, observed effect, evidence, unknowns, deadline, and next permitted action.
04Operating contract
Restore an exact known-good state
Which artifact and configuration remain compatible, qualified, and authorized now?
Read contractCollapse contract
Operating contract
Restore an exact known-good state
Required behavior
Bind recovery to immutable source and artifact identity, runtime configuration, policy, schema, dependencies, qualification scope, restoration authority, and an observation plan.
Governing invariant
Previous is not synonymous with known-good; rollback, compensation, and reconciliation remain separate operations.
Required record
Bind the decision, actor, authority, exact subject, observed effect, evidence, unknowns, deadline, and next permitted action.
05Operating contract
Close with independent proof
What proves the impact stopped and the required outcome is healthy again?
Read contractCollapse contract
Operating contract
Close with independent proof
Required behavior
Reconcile downstream effects, verify recovery independently, review stale queued work, preserve the forensic bundle, record residual risk, and route corrective changes through governed improvement.
Governing invariant
Restored service is a milestone. Verified recovery and dispositioned unknowns permit closure.
Required record
Bind the decision, actor, authority, exact subject, observed effect, evidence, unknowns, deadline, and next permitted action.
Use the incident packet, degraded-mode matrix, saga contract, and failure drills in the Guide →
See what Mission Control must add to support these controls →
Practical qualification
Prove the behavior behind the architecture.
Start with one outcome, an accountable owner, a baseline, and explicit stop conditions. Qualify the exact implementation against that workload.
Diagnose retrieval
Trace source freshness, permissions, candidate recall, assembled context, and claim support separately. Citations alone do not prove an answer; cached evidence must remain eligible.
Choose recovery
Retry transient failures within limits. Reconcile unknown write effects before repeating them. Replan within scope, use qualified fallbacks, and stop when authority or budget is missing.
Qualify the runtime
Test cancellation, recovery, tool contracts, isolation, traceability, and upgrades. Tool discovery is inventory; execution still needs a qualified version and current authorization.
Decide on outcomes
Compare accepted results, human effort, quality, and total cost against the baseline. Expand, revise, or stop on evidence; a calendar milestone does not prove readiness.
Choose autonomy per action.
Use fixed workflows for known steps and bounded agent judgment for uncertain ones. Reading, editing, publishing, and releasing need distinct grants. Recheck authority after a wait or changed revision; an earlier approval cannot authorize a different action.
Walk through the dependency-update example and execution-time checks →
Software factory concept
Authority flows down. Evidence flows back.
HumansIntent + policyOwn goals, judgment, and material risk
Control planePlan · govern · routeIdentity, authority, budget, and state
Capability supplyAgents · models · skills · tools · context
ExecutionHarness · Runtime · SandboxAgent Loop, Attempts, leases, checkpoints, recovery
TrustEvidence + independent verificationPolicy and human approval at consequence
OutcomeAccepted, observed valueFeeds governed learning—not direct mutation
What should I do next?