Chapter 6: Harness Engineering and Control Loops
1. Chapter Overview
Production AI needs a control plane around probabilistic work. The harness provides that structure at runtime: it decides when model-influenced work may begin, which path is eligible, whether a candidate is admissible, and when execution must pause, degrade, transfer, or stop.
Prompts request behavior, and models propose classifications, plans, answers, or actions. Neither has authority to advance a production workflow. That authority belongs to the harness at the transition between controlled states.
The primary engineering decision is how to design this control loop. Reviewers should be able to see which state is authoritative, what guards each transition, how validation changes the path, and where recovery ends. Specific approvals and explicit terminal outcomes then turn uncertain output into a decision the surrounding product can consume safely.
This chapter owns orchestration, workflow routing, runtime validation, retries, repairs, fallbacks, state transitions, guardrails, human-approval workflow mechanics, and termination. Its inputs include prompt contracts from Chapter 4 and context-package signals from Chapter 5. Proposed external actions pass to Chapter 7; system-level evaluation, policy definitions, release mechanics, and operational response remain with Chapters 8 through 11 respectively.
2. Primary Engineering Problem
Natural-language instructions are not durable workflow controls. Telling a model to respect a schema, stop after two attempts, request approval, or avoid an unsupported conclusion can influence generation. It does not establish authoritative state, prevent an invalid transition, allocate a global budget, or prove that a loop will terminate.
The engineering problem is:
Design a deterministic control system that admits model judgment where useful without delegating control authority to the model.
This is the line harness engineering must hold. A model may propose route R2, but the harness determines whether that route is eligible. A candidate may appear complete, but acceptance still depends on the required validators. Even a recommendation to try again has no force until the harness checks the failure class, the required change, and the remaining budget.
Every state transition therefore needs a decision contract, not just a position in a call sequence:
- the authoritative current state and state version
- the event that requests advancement
- the guard and invariants that must hold
- the model's permitted influence, if any
- deterministic checks and externally owned policy inputs
- the state mutation and control budget consumed
- the reason code and evidence reference
- the recovery or terminal path when the guard fails
An edge that cannot be described this way still contains a control decision; it is merely implicit. Duplicate work, stale approvals, silent degradation, and non-terminating loops tend to enter through those unowned edges.
3. Core Mental Model
A harness surrounds bounded units of probabilistic work with an authoritative state-transition system.
State is more than a status label
The authoritative workflow record should distinguish several kinds of state:
- Control state: the current lifecycle position and permitted next transitions.
- Task state: normalized inputs, intermediate artifacts, and completion evidence.
- Decision state: validation outcomes, approval decisions, rejection reasons, and accepted candidate identity.
- Attempt state: attempt types, counters, failure fingerprints, and consumed budgets.
- Dependency state: completeness, availability, or authority signals received from other components.
- Presentation state: what a user sees; this must not be treated as the source of truth for workflow advancement.
For each authoritative field, record its owner, source of truth, write authority, durability requirement, and invariant. Conversation text can expose or summarize that state, but cannot serve as its store. Restarts, truncated histories, duplicate events, and concurrent workers must all reach the same answer about where the workflow stands.
Useful invariants include:
- a terminal workflow cannot re-enter execution without a new execution identity
- an approval applies only to the candidate and evidence snapshot that was reviewed
- a hard validation rejection cannot reach an accepted state through a weaker fallback
- cumulative budgets never increase because an inner loop restarted
- only one state version can win a transition from a given prior version
The harness authorizes transitions
In practice, a controlled loop has seven responsibilities:
- Admit an event against the current state and authority inputs.
- Select an eligible route using deterministic facts and bounded semantic judgment.
- Prepare versioned prompt and context inputs through their owning contracts.
- Invoke a bounded model subroutine to produce a candidate, classification, or proposal.
- Validate the candidate in an ordered sequence.
- Authorize exactly one next transition: accept, repair, replay, re-prepare, clarify, request approval, degrade, transfer, reject, or fail.
- Commit the state mutation and its decision evidence consistently.
The model participates in steps 2, 4, and 5 only where semantic judgment is useful. Regardless of where it participates, its output remains a proposal until the relevant guards authorize a transition.
Progress and termination are designed properties
Success must be tied to accepted evidence rather than model confidence. The design must be equally clear about terminal rejection, terminal failure, degraded or partial completion, cancellation, and transferred ownership.
A local retry count cannot provide that guarantee. A composed workflow may rotate through routing, generation, repair, approval, and fallback while every inner component stays within its own limit. The outer harness therefore tracks cumulative budgets across attempts, elapsed time, model invocations, cost or resource use, repair depth, route changes, and approval waiting wherever those dimensions matter.
If the harness cannot show that another transition is eligible, materially different, and within budget, the correct control decision is to stop.
A harness moves work through generation and validation, with bounded repair, fallback, approval, refusal, and completion states.
System view
Validation Determines the Next Controlled State
Text equivalent
- Receive admits a bounded request only when its identity, current state, and authority inputs are valid.
- An admitted request moves to Assemble, which prepares versioned prompt and context inputs through their owning contracts.
- Assemble moves to Generate only when required inputs and cumulative budget are ready.
- Generate returns a candidate to Validate; the candidate does not carry authority to advance itself.
- Validate moves to Accept when every required check passes.
- A repairable validation defect moves to Repair with a named reason and required change.
- Repair returns to Generate only when the changed attempt remains inside local and global budgets.
- Repair moves to Retry budget exhausted when the failure fingerprint does not change or a cumulative limit is reached.
- Validate may choose Fallback only when an approved reduced-capability contract preserves the required minimum guarantees.
- Validate moves to Request approval when accountable judgment is required for the exact candidate and evidence snapshot.
- A hard validation guard moves directly to Refuse and cannot be bypassed by repair or fallback.
- Retry budget exhausted moves to Fallback when an approved degraded path exists, to Request approval when ownership can transfer for judgment, or to Refuse when neither path is safe.
- Request approval moves to Accept only for an approved, current candidate; an eligible revision returns to Repair.
- Rejected, expired, invalidated, or unavailable approval moves to Refuse unless an explicit transfer path exists.
- Accept reaches Complete only after the state transition and completion evidence are committed consistently.
- Fallback reaches Complete with the reduced guarantee recorded in both machine-readable and user-visible form.
4. System Boundary
The harness governs procedure around model-influenced work: workflow states, transition contracts, runtime acceptance consequences, recovery policies, approval waits, and terminal outcomes.
Those responsibilities do not transfer ownership of the dependencies it consumes.
Prompt contract boundary
Chapter 4 defines requested behavior, instruction hierarchy, output contracts, and prompt asset identity. The harness selects an approved contract for the current state, supplies its required inputs, and enforces the consequence of a nonconforming output. Prompt wording remains outside this chapter.
Context package boundary
Chapter 5 defines retrieval, ranking, compression, memory, permission-aware eligibility, and context-package status. The harness consumes package identity, completeness, provenance, and constraint signals. A change in those signals may justify re-preparation; it does not justify redesigning retrieval inside a retry loop.
External action boundary
The harness may govern a proposal, an approval state, or the transition to an action-ready boundary. Chapter 7 owns tool permissions, action authority, idempotency, side-effect deduplication, execution receipts, delegation, and long-running action workflows. At the handoff, the harness requires a safe action contract instead of inventing one at the call site.
Policy boundary
Product, risk, security, privacy, and governance owners define the applicable policy; Chapter 9 treats those concerns in depth. At explicit guard points, the harness consumes their authoritative decisions and records which policy input governed the transition. A model's self-assessment may contribute evidence, but it cannot enforce a hard policy guard.
Evaluation and operations boundary
This chapter defines finite transition cases and invariants that engineers can check locally. Chapter 8 owns representative datasets, scoring methods, regression strategy, and launch thresholds. The harness emits reconstructable control events, while Chapter 11 owns their transport, storage, dashboards, alerts, incident response, and post-incident use.
5. Design Principles
Principle 1: Make authoritative state explicit and durable
State has to survive the failures the workflow claims to handle. Before a consequential transition, persist enough information to decide whether work may proceed and whether an incoming event is current. Commit the next state with its decision evidence so execution cannot advance while the authoritative record still reports the prior state.
Use state versions or equivalent concurrency control to reject stale and duplicate transitions. Define recovery behavior for interruption between invocation, validation, and commit. This is workflow consistency; external side-effect idempotency remains a Chapter 7 concern.
Principle 2: Validate in layers and attach consequences
Validation is not one undifferentiated quality check. Failure classes have different owners and permit different next steps, so order the checks deliberately:
- Invocation validity: required inputs, state, and dependencies exist before work begins.
- Structural validity: the candidate parses and conforms to the selected output contract.
- Referential validity: identifiers, citations, and evidence references resolve to supplied inputs.
- Constraint validity: deterministic task rules and bounded constraints hold.
- Decision admissibility: authoritative policy and permission inputs allow the proposed transition.
- Completion validity: the candidate provides the evidence required to finish this workflow state.
Run cheap, deterministic checks before expensive or judgment-heavy work where practical. Each validator declares its input, owner, determinism, severity, reason codes, and possible dispositions. Those dispositions may include acceptance, degraded acceptance, repairable rejection, replayable failure, clarification, approval, terminal rejection, or terminal failure.
A later repair may fix a structural defect. It may not erase an earlier hard policy denial or bypass missing authority.
Principle 3: Classify failure before authorizing another attempt
Retry is too vague for a control policy. Distinguish:
- Replay: repeat after a transient transport or dependency failure.
- Repair: correct a diagnosed, bounded defect in an existing candidate.
- Regenerate: produce a different candidate under the same contract when variation is acceptable.
- Re-prepare: rebuild prompt or context inputs after an upstream condition changes.
- Clarify: pause until the requester supplies missing or ambiguous information.
- Re-plan: replace a rejected proposal before execution advances.
An attempt policy names its eligible reason codes, the condition that must change, local and global limits, and the transition on exhaustion. Repeating identical inputs after a deterministic failure adds cost without adding resilience.
Principle 4: Make fallbacks capability contracts
Fallback changes the execution path; it does not lower the acceptance threshold. Its contract states which capabilities and guarantees remain, which become weaker, what authority and consequence limits apply, and how consumers will recognize the result.
A valid fallback might narrow scope, return partial evidence, use a deterministic alternative, defer work, or transfer the case to a human-owned queue. It must never silently turn unsupported into supported, bypass a hard guard, or present degraded completion as normal success.
Principle 5: Attach guardrails to protected invariants
A guardrail is an enforceable decision at a named boundary. Common enforcement points are:
- admission guards before a workflow or route begins
- input guards before a model interaction receives data
- transition guards before authoritative state changes
- output guards before a candidate becomes product output
- action guards before a proposal crosses into Chapter 7's execution boundary
- budget guards before more work is authorized
- terminal guards that reject late events or stop non-progressing loops
The specification for each guard names the protected invariant, authoritative rule source, enforcement owner, failure behavior, and override authority. A control that exists only as prompt prose is an instruction, not a guardrail.
Principle 6: Treat human approval as a durable workflow state
Approval is neither a modal dialog nor a boolean field. It is an explicit paused state whose decision request binds a candidate identity, evidence snapshot, scope, state version, authority input, and expiry rule.
The gate defines allowed reviewer outcomes and their exact next transitions. Input changes, candidate changes, policy changes, expiry, cancellation, or supersession invalidate the approval. Timeout and reviewer unavailability must lead to a specified safe state; they must not default to approval.
Principle 7: Record control decisions as part of correctness
Every material transition should produce a structured control event. Free-form rationale is too difficult to reconstruct or query on its own. The event identifies the workflow, prior and next state, trigger, decision owner, reason code, validator outcomes, candidate or asset identities, budget changes, and approval reference where applicable.
The event need not copy sensitive payloads. Stable references are usually enough. Chapter 11 owns what happens to these events operationally; Chapter 6 owns producing decision evidence that matches the state transition.
6. Architecture Patterns
Select patterns for the control property they provide, not for how agentic they appear.
| Pattern | Use when | Required contract | Characteristic failure | Stop or handoff rule |
|---|---|---|---|---|
| Deterministic shell with a bounded model subroutine | Most workflow steps and acceptance rules are known, but one semantic judgment benefits from a model | Fixed inputs, narrow output contract, deterministic entry and exit guards | Model output is treated as a command rather than a candidate | Reject or route the candidate when its contract fails |
| Validate-and-repair loop | A candidate can have local, diagnosable defects | Validator reason codes, repairable fields, candidate identity, repair budget | Repair rewrites valid content or cycles on the same defect | Stop on hard failure, unchanged fingerprint, or budget exhaustion |
| Semantic router with deterministic eligibility guards | Request meaning affects the workflow path | Eligible destinations, allowed features, safe ambiguity path, route reason | A common route becomes an unsafe default or routes oscillate | Clarify, reject, or use a declared safe route when none is admissible |
| Staged proposal-review workflow | Complex work benefits from separating proposal from commitment | Stage states, entry evidence, acceptance criteria, invalidation rules | A later stage executes an unapproved or stale proposal | Re-plan, request approval, or terminate before commitment |
| Human approval gate | Consequence or ambiguity requires accountable judgment | Bound evidence snapshot, reviewer authority input, expiry, allowed decisions | Approval is reused after the candidate or context changes | Invalidate and return to preparation, or transfer safely on timeout |
| Degraded-service fallback | The primary path is unavailable but a smaller product promise is acceptable | Preserved and lost guarantees, consequence ceiling, outcome label | Degraded output is presented as complete or bypasses a hard guard | Complete as degraded, transfer, or stop; never silently promote |
| Circuit breaker and safe-stop path | Repeated failures or dependency signals make continuation predictably harmful | Signal scope, open condition, allowed work, reset authority | A breaker masks unrelated healthy work or resets automatically into failure | Reject new attempts in scope until reset conditions are met |
Patterns compose only through explicit transitions. For example, a router may admit a request into a staged workflow, one stage may use a bounded model subroutine, validation may authorize one repair, and a consequential proposal may enter an approval wait. Every nested path consumes the outer workflow budget; an inner loop cannot reset it.
This chapter owns routing within a workflow. Chapter 10 owns routing across deployed releases, model versions, or runtime configurations. Eligibility should rest on deterministic facts where possible, leaving only residual semantic ambiguity to model classification. Record both the route configuration and the reason for the choice. A reroute is eligible only when the next path is materially different and the route-change budget still permits it; otherwise the workflow can oscillate without progress.
7. Failure Modes
Failure mode 1: Model-proposed transitions become authoritative
The system advances because a model called the task complete, safe, or approved. Without an independent guard, confidence has been mistaken for control authority.
Failure mode 2: State is reconstructed from conversation text
Retries, restarts, and concurrent workers infer different workflow positions because presentation state displaced authoritative state. Duplicate transitions and stale decisions follow.
Failure mode 3: Validation has no consequence model
The system detects a defect, then displays the candidate, sends it downstream, or invokes a repair that bypasses the failed guard. Without an enforced disposition, the validator is merely advisory.
Failure mode 4: Repetition is mislabeled as recovery
After a deterministic failure, the workflow invokes the same inputs again, or nested components consume independent retry limits. Cost and latency rise even though no condition changed and no monotonic progress occurred.
Failure mode 5: Fallback silently changes the product promise
An alternate path removes an evidence requirement, uses incomplete context, or reduces capability while labeling its outcome as normal success. Downstream consumers can no longer distinguish complete, degraded, partial, and failed execution.
Failure mode 6: Routing oscillates
After a failure, the harness moves among routes without a materially different prerequisite, reason, or global budget. Each route counts itself as a fresh attempt although the workflow has made no progress.
Failure mode 7: Approval is stale or unbound
A reviewer approves a summary, but the candidate, evidence, context, or plan changes before execution continues. The human decision was valid; the object to which the system applies it is not.
Failure mode 8: Late events revive terminal work
A delayed model response, duplicate queue event, late approval, or recovered worker attempts a transition after cancellation or completion. Without state-version and terminal guards, completed work can resume incorrectly.
Failure mode 9: Recording is best-effort bookkeeping
The authoritative state advances while its decision evidence remains absent or contradictory. Reviewers can no longer reconstruct which guard, asset version, or budget allowed the transition.
Failure mode 10: Escalation transfers data but not control
The workflow sends a case to a human queue without an owner, decision scope, evidence, expiry, or continuation rule. Automation has stopped, but ownership has not actually transferred and the case has no reliable next state.
8. Tradeoffs
Deterministic control versus semantic flexibility
Deterministic guards improve predictability when conditions can be expressed reliably, but excessive hard-coding may reject useful, unusual cases. Enforce consequence, authority, budget, and contract boundaries deterministically. Reserve model judgment for meaning that cannot be reduced safely to fixed rules, then pass the semantic result through an admissibility guard before it changes state.
State durability versus latency and complexity
Persisting every transient operation adds latency and coordination cost. Persisting too little leaves interruption recovery unable to tell whether work may resume. Durable checkpoints matter most around consequential transitions, approval waits, expensive work, and handoffs. Purely recomputable preparation may remain transient when replay is safe and bounded.
Strict acceptance versus useful degradation
Rejecting every imperfect candidate protects a single quality bar, but may discard useful partial results. Degradation is appropriate only when the product can name the reduced guarantee, contain the consequence, and label the result accurately. When authority, hard policy, required evidence, or state consistency is missing, failure is safer than degradation.
Recovery depth versus total resource exposure
Repairs and alternate routes may improve completion, but each branch adds latency, cost, and another path that must terminate. Another attempt is justified only when the failure is classified, the attempt changes a relevant condition, and its expected value fits the cumulative budget. Otherwise, stop or transfer ownership.
Human judgment versus queue risk
Approval adds accountability when a person can evaluate evidence or consequence. It also introduces stale-decision and queue risks. Place a gate where reviewer judgment changes authority or acceptance, not merely to make automation appear safer. Bind the decision, define its expiry, and design the timeout path before launch.
Central consistency versus workflow-specific control
Shared transition primitives, reason codes, budget rules, and event contracts improve consistency. A universal harness, however, can hide important domain state and force unsafe generic fallbacks. Standardize control vocabulary and invariants while keeping workflow states and acceptance conditions close to the product decision they govern.
9. Production Checklist
Before approving a harness design, confirm:
- The workflow has an authoritative state source and a versioning or concurrency rule.
- Control, task, decision, attempt, and dependency state are distinguishable.
- Every state has defined entry conditions, invariants, allowed exits, and terminal behavior.
- Every transition names its trigger, guard, decision owner, mutation, reason, and failure path.
- Model outputs are proposals until a harness-owned transition authorizes advancement.
- Prompt and context inputs are consumed through versioned upstream contracts.
- Validation layers have owners, ordering, reason codes, and enforced dispositions.
- Hard validation or policy failures cannot be bypassed through repair or fallback.
- Replay, repair, regenerate, re-prepare, clarify, and re-plan are distinct policies.
- Every repeat policy states what must change and which cumulative budget it consumes.
- Fallbacks declare preserved and weakened guarantees and label degraded outcomes.
- Route candidates have eligibility rules, ambiguity behavior, reasons, and rerouting limits.
- Guardrails are attached to protected invariants and explicit enforcement points.
- Approval waits bind decisions to candidate, evidence, scope, state version, and expiry.
- Cancellation, supersession, duplicate events, late responses, and restart recovery are defined.
- Success, partial, degraded, rejected, failed, cancelled, and transferred outcomes are explicit.
- Control events can reconstruct the transition without copying unnecessary sensitive payloads.
- Harness-local checks cover state and transition invariants; broader evaluation remains in Chapter 8.
- Proposed external actions cross a defined boundary into Chapter 7 controls.
10. Design Review Questions
- What is the source of truth for workflow state, and who may mutate it?
- Which invariants must hold in every state and across every transition?
- Which decisions may a model propose, and which component authorizes them?
- What happens when an event arrives for an unknown, stale, cancelled, or terminal state version?
- Can duplicate or concurrent events authorize the same transition twice?
- Which validation layer owns each acceptance rule, and what exact transition follows each reason code?
- What materially changes before replay, repair, regeneration, re-preparation, or re-planning?
- Can any inner loop reset or escape the workflow's cumulative budget?
- How does the harness detect non-progress across route changes and repair attempts?
- When no route is admissible or classification is ambiguous, what is the safe path?
- Which guarantees does each fallback preserve, weaken, or remove?
- Can a degraded outcome be mistaken for complete success by a user or downstream system?
- What evidence, state version, and candidate identity does an approval bind to?
- What invalidates approval, and what happens on rejection, timeout, or reviewer unavailability?
- If recording the decision fails, may the authoritative state still advance?
- What completion evidence proves success, and what conditions force safe termination?
11. Main Artifact: Harness Control-Loop Diagram
The Harness Control-Loop Diagram is a coordinated specification. Its diagram exposes states and loops, while the supporting tables define the contracts that make each edge enforceable. Upstream and downstream artifacts are referenced rather than reproduced.
Workflow definition
- Harness Control-Loop Diagram identity and version:
- Workflow purpose:
- Trigger and request identity:
- Harness owner:
- Source AI System Stack Reference Model identity, version, and harness-layer boundary:
- Source Production Prompt Specification identity and version:
- Source Context Assembly Plan identity, version, and context-package schema:
- Authoritative state source and concurrency rule:
- Applicable authority and policy inputs:
- Downstream Tool Permission Matrix identity and action-ready interface:
- Evaluation Plan handoff: transition invariants, failure paths, and scenario IDs:
- AI Release Manifest handoff: harness asset identity and compatibility classification:
- Outer budgets for attempts, elapsed time, invocations, and resources:
- Terminal outcome vocabulary:
Control-loop diagram
mermaid stateDiagram-v2 [*] --> Admitted: admission guard passes [*] --> Rejected: admission guard fails permanently Admitted --> Routed: eligible route selected Admitted --> AwaitingClarification: required input missing Routed --> Prepared: prompt and context contracts ready Routed --> Transferred: human-owned route selected Prepared --> Invoking: invocation budget available Invoking --> Validating: candidate received Invoking --> Recoverable: transient invocation failure Validating --> Accepted: all required checks pass Validating --> Recoverable: bounded defect or changed prerequisite Validating --> AwaitingApproval: specific transition needs review Validating --> Degraded: approved fallback preserves minimum guarantees Validating --> Rejected: hard constraint or authority denial Recoverable --> Prepared: replay, repair, regenerate, re-prepare, or re-plan authorized Recoverable --> Failed: budget exhausted or no material change AwaitingClarification --> Admitted: current input supplied AwaitingClarification --> Cancelled: timeout or cancellation AwaitingApproval --> Accepted: current candidate approved AwaitingApproval --> Prepared: rejected or invalidated with eligible revision AwaitingApproval --> Transferred: ownership explicitly transferred AwaitingApproval --> Cancelled: timeout, cancellation, or supersession Accepted --> [*] Degraded --> [*] Rejected --> [*] Failed --> [*] Cancelled --> [*] Transferred --> [*]
Adapt the state names to the workflow, but preserve the distinction among active work, recoverable work, pending human or requester input, and terminal outcomes. No proposal is an accepted state.
State catalog
| State | Purpose and authoritative data | Entry criteria | Allowed exits | Key invariant |
|---|---|---|---|---|
| Admitted | Normalized request, request identity, authority inputs | Admission guard passes | Routed, AwaitingClarification | Request identity and scope are stable |
| Routed | Eligible route, reason, route configuration identity | Route guard authorizes one destination | Prepared, Transferred | Destination is eligible for current state and authority |
| Prepared | Prompt contract, context package, dependency state, budgets | Required upstream contracts are ready | Invoking, Cancelled | Inputs match the recorded asset identities |
| Invoking | Invocation identity and reserved budget | State version and budget guard pass | Validating, Recoverable | At most one winning result advances this state version |
| Validating | Candidate identity and validator results | Candidate belongs to current invocation | Accepted, Recoverable, AwaitingApproval, Degraded, Rejected | Candidate cannot be exposed as accepted before disposition |
| Recoverable | Failure class, fingerprint, required change, remaining budgets | Failure is eligible for bounded recovery | Prepared, Failed | Another attempt is materially different and globally affordable |
| AwaitingApproval | Candidate, evidence snapshot, scope, authority, expiry | A named transition requires human judgment | Accepted, Prepared, Transferred, Cancelled | Decision applies only to the bound snapshot and state version |
| Accepted | Completion evidence and final result identity | All mandatory guards pass | None | Terminal state rejects later execution events |
| Degraded | Partial result and explicit reduced-guarantee label | Approved fallback satisfies minimum contract | None | Lost guarantees remain visible to consumers |
| Rejected / Failed / Cancelled / Transferred | Terminal reason and ownership status | Defined terminal guard fires | None | Workflow cannot restart without a new execution identity |
Transition contract
Complete one row for every diagram edge.
| From → To | Trigger | Guard / decision owner | Model influence | State / budget change | Reason / failure path |
|---|---|---|---|---|---|
| Admitted → Routed | Admission completed | One destination eligible; harness owns authorization | May classify semantic intent | Record route, reason, configuration; consume route budget | Ambiguous → clarify; none eligible → reject or transfer |
| Prepared → Invoking | Inputs ready | State version current; invocation and global budgets available | None | Reserve attempt and invocation identity | Budget denied → failed or transferred |
| Invoking → Validating | Candidate returned | Candidate matches invocation and current state version | Produces candidate only | Record candidate identity and invocation use | Late or duplicate candidate → ignore and record |
| Validating → Recoverable | Repairable disposition | Reason code eligible; required change named; budgets remain | May propose repair or new candidate | Record failure fingerprint and consume recovery budget | Hard rejection or unchanged repeat → rejected / failed |
| Validating → AwaitingApproval | Approval disposition | Candidate and evidence complete; authority source names reviewer class | May summarize evidence, not grant authority | Persist bound snapshot, scope, state version, expiry | Missing authority → rejected or transferred |
| Validating → Accepted | All mandatory checks pass | Harness composes validator outcomes | No authority to self-accept | Commit completion evidence and terminal event | Commit failure → remain non-terminal or fail safely |
Validation and consequence matrix
| Layer | Input and rule owner | Typical reason | Permitted disposition | Prohibited shortcut |
|---|---|---|---|---|
| Invocation | Harness state and dependency contracts | missing prerequisite, stale state | clarify, re-prepare, reject | invoke with guessed state |
| Structural | Chapter 4 output contract | unparseable, missing required field | repair, regenerate, reject | accept because prose appears plausible |
| Referential | Candidate and Chapter 5 package references | unknown identifier, unsupported citation | repair, re-prepare, degrade if contract allows | invent or silently remove required evidence |
| Constraint | Deterministic task rules | range, consistency, or completion violation | repair, re-plan, reject | lower the constraint during fallback |
| Admissibility | Authoritative policy or permission input | denied authority, prohibited transition | approval if policy permits, transfer, reject | ask the model to override denial |
| Completion | Workflow acceptance contract | insufficient completion evidence | repair, clarify, degrade, fail | equate model confidence with completion |
Recovery, fallback, and approval policies
For each replay, repair, regenerate, re-prepare, clarification, or re-plan path, record:
- eligible reason codes and failure fingerprints
- the condition that must change before another attempt
- local limit and outer budget consumed
- backoff or wait condition where relevant
- next state after success and terminal state after exhaustion
For each fallback, record:
- the triggering failure and approved destination
- preserved and weakened guarantees
- consequence and authority ceiling
- user-visible and machine-readable outcome label
- conditions, if any, for returning to the primary path
For each approval gate, record:
- decision requested and allowed reviewer outcomes
- candidate, evidence, scope, state version, and policy identity
- reviewer authority input, expiry, and invalidation conditions
- transitions for approve, reject, edit request, timeout, cancellation, and unavailability
Control event contract
Every material transition should emit:
- workflow, execution, event, transition, and correlation identities
- prior state, prior state version, trigger, selected transition, and next state
- decision owner and reason code
- candidate, prompt, context package, route configuration, harness, and policy identities as applicable
- validator outcomes and failure fingerprint
- attempt type and the before-and-after states of local and global budgets
- approval reference or terminal outcome where applicable
- decision timestamp and stable evidence references
Harness-local checks
Before the artifact is accepted, verify that:
- every state has an allowed-exit set, and every diagram edge has a transition row
- terminal, cancelled, and superseded states reject stale continuation events
- duplicate events cannot produce two winning transitions from one state version
- hard failures cannot reach accepted or degraded states
- every recovery edge consumes the correct outer budget and names a changed condition
- route ambiguity reaches the declared safe path and rerouting cannot oscillate indefinitely
- approval is invalidated by changed candidate, evidence, state, authority, or expiry
- degraded outcomes retain machine-readable and user-visible loss-of-guarantee labels
- failure to commit required decision evidence has explicit state behavior
These checks apply to the harness specification. Chapter 8 turns system behavior into a broader evaluation plan, and Chapter 11 operationalizes the resulting control events.
The Harness Control-Loop Diagram applies the harness-layer boundary from the AI System Stack Reference Model and consumes exact versions of the Production Prompt Specification and Context Assembly Plan. It gives action-ready boundary assumptions to the Tool Permission Matrix, behavioral invariants and failure paths to the Evaluation Plan, and its releasable asset identity to the AI Release Manifest. A receiving artifact may tighten a guard, reduce authority, or reject a transition. It must not silently expand the workflow boundary, evidence eligibility, action authority, fallback guarantees, or recovery budgets.
12. Key Takeaways
- A model may propose a result or transition; the harness authorizes state advancement.
- Authoritative state, guarded transitions, durable decision evidence, and terminal outcomes form the control system.
- Validation is useful only when every outcome has an enforced consequence.
- Replay, repair, regeneration, re-preparation, clarification, re-planning, and fallback solve different failure classes and consume cumulative budgets.
- Guardrails protect named invariants at explicit enforcement points; prompt instructions are not substitutes.
- Approvals bind to a specific candidate, evidence snapshot, scope, state version, authority input, and expiry rule.
- A safe harness can prove why work continued, degraded, transferred, or stopped without taking ownership of adjacent chapters' disciplines.