Factory Configuration, Workflow Contracts, and Execution Manifests
An approved WorkOrder states what may be achieved. It does not fully describe the machinery that will perform the work. If workflow, agents, prompts, tools, models, repository paths, context, budgets, and recovery rules are resolved after d
A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Open the source exercise
Compile one WorkOrder into an execution manifest. Mark every version, hash, scope, budget, principal, and recovery rule. Then change an agent prompt and show which records become stale.
3. Enduring Principle
Separate configuration, workflow, and attempt snapshot
Factory Configuration is an approved, versioned operating envelope for one repository. It binds workflow, executor, policy, environment, risk boundary, budget, verifiers, recovery, agent versions, and code scopes.
Workflow contract defines the graph of roles and steps, dependencies, inputs, structured outputs, failure policy, handoffs, and concurrency.
Execution manifest is the immutable Attempt-specific compilation of the WorkOrder and Factory version. It records exactly what the worker received and which authority applied.
Hash behaviorally relevant inputs
A Factory digest should change whenever a change could alter execution: workflow version, executor, policy, environment, model route, agent version, prompt or tool hash, context lock, code scope, budget, validators, risk, or recovery. Stable canonical serialization is required; object insertion order must not create false changes.
Compile before dispatch and fail closed
Readiness verifies that every referenced component exists, is approved, active, compatible, and current. Compilation should reject missing agent bindings, unsafe workflow authority, invalid scope, stale context, or an executor that cannot satisfy the recovery contract. An incomplete manifest is not permission to use runtime defaults.
Use structured completion and bounded handoffs
Every step should emit schema-validated status, completed, incomplete, and unknown assertions, evidence references, risks, next action, and owner. Large outputs become artifacts; compact summaries enter shared context. Retry resumes from durable checkpoints instead of replaying an entire transcript.
Agents may recommend a pull request or deployment. Deterministic control-plane code owns publication and approval authority.
8. Notes and lessons learned
The Factory Configuration answers “which operating system is approved for this repository?” The execution manifest answers “what exactly governed this try?” Both are necessary; neither replaces the WorkOrder’s authority.
9. Interview and discussion questions
- Why is a WorkOrder insufficient as an execution manifest?
- Which changes must alter the Factory digest?
- How do structured handoffs reduce both risk and token cost?
- What should be redacted from a public run inspector?
- When may a runtime input legitimately float?
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence