The Authoritative Delivery Hierarchy
Preserve intent, authority, causality, evidence, and acceptance across every delivery record.
A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
The chapter in one pass.
- Purpose: Preserve intent, authority, causality, evidence, and acceptance across every delivery record.
- Best for: Architects, platform engineers, product leaders, and reviewers.
- Prerequisites: The Human-Agent Operating Model.
- Reading time: 22 minutes.
- You will learn: Why Mission, Plan, WorkOrder, Task, Attempt, Evidence, Pull Request, and Release must remain distinct.
Keep three ideas: “done” is not one state; retries create new Attempts rather than rewriting history; and evidence must remain bound to the exact candidate and governing requirement.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Jump to validation criteriaOpen the source exercise
Draw the complete hierarchy from memory. For every object, write one phrase for what it owns and one phrase for what it cannot authorize. Then trace these three paths:
- a normal change from Company to production verification;
- a failed validator result that creates corrective work and fresh Evidence;
- a material Plan or WorkOrder revision that invalidates prior authority.
The exercise fails if any lower-level status automatically accepts a parent or if evidence cannot be traced to an exact Attempt and artifact.
3. Enduring Principle
One record, one governing responsibility
Each important record should own one kind of decision. It may summarize child state, but it must not borrow the child's meaning. The full conceptual hierarchy is:
Company -> Workspace -> Repository -> Factory Configuration -> Mission -> Approved Plan -> WorkOrder -> Task -> Attempt -> Evidence -> Pull Request -> Release
This hierarchy contains three connected structures:
- Organizational scope establishes who and what the factory may govern: Company, Workspace, Repository, and Factory Configuration.
- Intent and authority translate an outcome into approved work: Mission, Plan, and WorkOrder.
- Execution and proof preserve what happened and whether it is acceptable: Task, Attempt, Evidence, Pull Request, and Release.
The arrows show lineage, not automatic completion. Child progress may inform a parent decision. It cannot make that decision by implication.
Company
The Company is the highest accountability and data-isolation boundary. It owns organizational identity, membership, broad policy, and ultimate risk ownership. It does not describe a particular product outcome or authorize repository work.
Without this boundary, users, credentials, policies, costs, and evidence can leak across organizations.
Workspace
A Workspace is an isolated operating scope within a Company. It groups the people, repositories, configurations, Missions, and permissions needed for a product, team, or bounded initiative. It does not itself prove access to a specific repository or environment.
Without a Workspace boundary, every policy becomes organization-wide and teams cannot reason about local authority, ownership, or cost.
Repository
The Repository record identifies an exact source-control target and its connection status. It owns provider identity, canonical repository name, default branch, installation linkage, readiness, and repository-specific policy overrides. Registration is not authorization to mutate it.
Without a first-class Repository, the system may confuse repositories with similar names, act against stale credentials, or lose the relationship between work and source lineage.
Factory Configuration
The Factory Configuration is a versioned authority envelope for operating on a Repository. It binds an approved workflow, executor and version, policy, environment, budget, verifiers, risk boundary, and recovery controls. A digest identifies the exact configuration evaluated at dispatch.
It does not define the business outcome. It answers, “Under which operating rules may this factory perform work here?”
Without versioning, a run cannot prove which tools, policy, budget, or validator set governed it. Editing configuration in place destroys reproducibility.
Mission
A Mission is one durable governed outcome. It owns the objective, business reason, context, constraints, sources of truth, owner, risk, stop condition, budget, and measurable acceptance criteria. It coordinates work without becoming the runtime that performs it.
Without a Mission, agents optimize Tasks while the original business outcome drifts or disappears.
Plan
A Plan is a versioned proposal for achieving the Mission. It records research, unknowns, sequencing, WorkOrder blueprints, validation assertions, cost, and rollback approach. Approval freezes one exact version and permits its authorized WorkOrders to be materialized.
Plan approval does not dispatch an agent, satisfy WorkOrder risk approval, accept evidence, merge code, or deploy software. Without versioned approval, the system cannot prove that execution followed what the human reviewed.
WorkOrder
A WorkOrder is the primary unit of engineering authority and acceptance. It defines a bounded desired outcome, repository and branch strategy, permitted scope, constraints, dependencies, risk, model limits, required approvals, acceptance criteria, and human escalation conditions.
The WorkOrder is more than a ticket. It is the contract between human intent and agent execution. Without it, tool access and work scope are inferred from conversation.
Task
A Task is a bounded operational unit within authorized work. It provides useful decomposition, assignment, dependency, and progress information. It does not own business acceptance or expand the WorkOrder's authority.
Without Tasks, execution may become too coarse to schedule, recover, or assign. When Tasks replace WorkOrders, operational completion is easily mistaken for accepted value.
Attempt
An Attempt is one immutable execution try. It owns runtime identity, exact input versions, worker, tools, worktree, timeline, status, artifacts, cost, errors, and termination reason. A retry creates a new Attempt rather than rewriting the failed one.
Without immutable Attempts, the factory cannot reconstruct causality, detect duplicate execution, compare recovery hypotheses, or audit what actually ran.
Evidence
Evidence is criterion-linked proof produced by a known verifier against an exact artifact and environment. It records method, result, provenance, freshness, artifact hashes, source commit, and validity. Evidence may pass, fail, become stale, conflict, or require an authorized waiver.
Evidence is not an agent's narrative. Without criterion linkage and provenance, the factory can present confidence without proof.
Pull Request
A Pull Request is the source-control review boundary for the proposed change. It owns the repository comparison, branch, head SHA, checks, review state, and merge result. The review package links it back to the Mission, Plan, WorkOrder, Attempts, and Evidence.
A pull request is not the WorkOrder and does not prove customer value. A new head SHA can make earlier evidence stale.
Release
A Release is the governed progression of an accepted change through merge, deployment, activation, observation, rollback readiness, and production verification. These stages remain separate because each introduces new risk and requires different evidence.
Without a Release boundary, “merged,” “deployed,” “enabled,” “healthy,” and “valuable” collapse into one misleading status.
Invariants that protect the hierarchy
Five invariants make the model trustworthy:
- Every material action traces upward to human-governed intent.
- Every run records the exact versions of its WorkOrder, workflow, factory configuration, repository, and policy.
- No child record silently completes or accepts its parent.
- Material change creates a new version and invalidates affected authority or evidence.
- Every acceptance decision can trace downward to fresh evidence and exact artifacts.
8. Notes and lessons learned
My current conclusions are:
- The hierarchy is a chain of claims, not merely a database relationship.
- WorkOrder is the central contract between human intent and agent execution.
- Attempt history must be immutable because retries are new facts.
- Evidence belongs to criteria and exact artifacts, not generic completion.
- Plan approval, dispatch, completion, acceptance, merge, deployment, and value confirmation are different decisions.
- Product vocabulary must be stable even while implementation names migrate.
- A schema can represent the right model while the supported product journey remains incomplete.
9. Interview and discussion questions
- Why is a WorkOrder not simply a Task?
- What does Plan approval authorize, and what does it not authorize?
- Why must an Attempt be immutable?
- When does evidence become stale?
- Why can a passing pull request still fail Mission acceptance?
- Which entity owns business intent?
- Which entity owns execution authority?
- How should a material WorkOrder revision affect approvals and evidence?
- Why should Pull Request and Release remain distinct?
- How do Mission Control's implementation names map to the conceptual model?
- Which parts of the hierarchy are implemented, partial, or unproven?
- How would you simplify the operator experience without collapsing the domain model?
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence