Make the Loop Inspectable

AR-02 v1.0.0 says what FieldOps may do. It names the goal, action classes, effect boundary, exact approval, budgets, stop rules, and completion evidence. Yet a contract cannot advance itself. Between request and disposition, something must observe state, ask a model for a proposal, validate that proposal, perform an allowed action, inspect the result, and decide what happens next.

If that “something” is hidden inside a framework call, the team can watch text appear without knowing which rule advanced the run. If chat history is treated as state, a summary may silently erase a cancellation or consumed approval. If the model can declare success, the system may congratulate itself before an effect exists.

FieldOps therefore turns the run into an engineered object. Its identity is stable. Its states and transitions are enumerated. Model output is a proposal. Deterministic software admits or rejects every transition. Events carry evidence references. Completion is checked outside the model. A run loop can branch on final output, tool calls, or handoffs and can be bounded in software, although any particular SDK is only one implementation of that pattern. [CLM-007]

The result is AR-03 v1.0.0: a provider-neutral state and event contract that can be replayed with a deterministic policy double before real capabilities are exposed.

1. Treat the run as an engineered object

A run is not a conversation. It is one governed attempt to complete one versioned task contract.

The minimum identity packet contains:

• runId: stable across waits, retries, and recovery;
• attempt: distinguishes a recovery attempt without inventing a new task;
• taskId: links the run to its delegated goal;
• contractVersion: identifies AR-02 semantics;
• policyVersion: identifies deterministic enforcement;
• modelAdapterVersion: identifies how provider output was normalized;
• createdAt, deadline, and current disposition;
• budget limits and monotonic counters;
• principal and authority references, never raw credentials;
• evidence and event-stream references.

The run ID does not change because the model is called again. It does not change when the process restarts. A new attempt may resume the same run after a technical failure, but the attempt number increases. A materially new goal, principal, or proposal creates a new governed object rather than borrowing the old history.

Keep configuration separate from accumulated state. Limits belong to the accepted run contract. Counters belong to the current run. Provider messages are observations attached to events; they are not the canonical task, budget, approval, or effect ledger.

This separation prevents a subtle failure. Suppose the conversation is summarized while FieldOps waits for approval. The summary says “the reservation was approved” because it paraphrases a user message. Canonical state still says WAITING_HUMAN, and the authority store has no matching approval record. The summary cannot advance the run.

The run also has exactly one terminal disposition. COMPLETED, FAILED, CANCELLED, and ESCALATED are mutually exclusive in AR-03. Later designs may add more terminal kinds, but they must preserve the invariant: once terminal, no ordinary proposal can reopen the run.

2. Build an explicit state machine

AR-03 uses thirteen states.

CREATED means identity and immutable configuration exist but execution has not begun. OBSERVING collects trusted structured observations. DECIDING is the only region where a model selects a next proposal. VALIDATING applies deterministic schema, contract, state, authority, and budget checks. EXECUTING calls a capability that passed those gates. VERIFYING checks claimed completion or effect evidence. WAITING_HUMAN and WAITING_EXTERNAL suspend progress without losing state. RECOVERING reconciles an ambiguous outcome. Four terminal states close the run.

The normal read loop is:

1. CREATED receives run.started and enters OBSERVING.
2. OBSERVING records an observation and enters DECIDING.
3. DECIDING accepts a model proposal and enters VALIDATING.
4. VALIDATING either denies, waits, or admits the action.
5. EXECUTING records a read result and returns to OBSERVING.

An effect follows a stricter path. Validation can enter WAITING_HUMAN. A matching approval returns to VALIDATING, not directly to execution, because expiry, cancellation, inventory, policy, and budget must be checked again. Execution then enters VERIFYING when an effect record exists, or RECOVERING when the response is ambiguous. Only completion.verified can enter COMPLETED.

Each transition has a single accepted event type. The harness rejects completion.verified from DECIDING; it cannot be used as a shortcut. It rejects tool results while WAITING_HUMAN. It rejects every action from a terminal state.

Global cancellation is deliberately asymmetric. Any nonterminal state can receive run.cancelled and become CANCELLED. The model does not vote on cancellation. If a capability is already in flight, the harness signals cancellation where possible, prevents subsequent transitions, and records whether an external effect still requires reconciliation. Cancellation stops future work; it does not erase a committed effect.

Transitions should be total over expected events. For every state, define what happens on valid input, invalid input, timeout, cancellation, and internal failure. “Framework handles it” is not a transition. If an event is impossible by design, reject it and record the reason.

Transition invariants

Several assertions apply to every move:

• run.identity.stable: runId and taskId do not change.
• event.sequence.next: sequence increases by one.
• state.transition.declared: the state-event-state edge exists.
• terminal.unique: a terminal state cannot transition again.
• budget.counter.monotonic: counters never decrease.
• contract.version.fixed: accepted semantics do not drift mid-run.
• proposal.not_authority: model output cannot satisfy authorization.
• effect.evidence.required: effect progress references the ledger.

These are code assertions, not prompt instructions.

3. Draw the model/code boundary

At DECIDING, the model receives a bounded view: task objective, current observations, permitted proposal schemas, remaining non-sensitive budget hints, and relevant failure reasons. It can emit one of a finite set of proposals: request an approved observation, form a reservation proposal, ask for clarification, escalate, or suggest completion.

The adapter parses provider-specific output into a local proposal. Raw output is preserved as evidence by version, but the rest of the system consumes only the local type.

Validation then proceeds in a fixed order:

1. Is the run nonterminal and not cancelled?
2. Is the proposal syntactically valid?
3. Is the action enumerated in AR-02?
4. Is the transition legal from the current state?
5. Do task preconditions and evidence exist?
6. Are budgets available?
7. Is principal, scope, audience, and authority valid?
8. Is the capability version admitted?
9. Does the proposal require a wait, escalation, denial, or execution?

Order matters. Reject malformed arguments before expensive policy queries. Check cancellation again before effect dispatch. Never let a helpful model explanation override a denial reason.

The model may propose complete. The harness translates this into a verification request, not a terminal transition. It checks the completion predicate defined in AR-02. For the reservation outcome, FieldOps requires compatibility evidence, fresh inventory evidence, exact approval, an effect record, and a verification record. “Done” in model output is one observation and nothing more.

A model’s success declaration is evidence, not the completion predicate. Deterministic assertions should verify structured state and effects where possible. Qualitative tasks may require a calibrated human or model grader, but that grader must be identified, evaluated, and kept distinct from the acting model. [CLM-008]

This limitation matters. Some writing or research tasks have no purely mechanical quality predicate. Independent grading can support completion, yet it introduces its own uncertainty. FieldOps avoids claiming that all agent tasks can be completed through deterministic assertions; it claims that reservation state and contract invariants can.

4. Make events replayable

State tells where the run is. Events explain how it arrived there.

Every AR-03 event carries an event ID, sequence, run ID, attempt, actor, type, timestamp, previous and next state, contract and policy versions, budget snapshot, reason, and nullable references to observation, proposal, validation, and effect evidence. The event record stores identifiers and decisions. Larger or sensitive payloads live in governed stores and are referenced.

Events are append-only facts about what the harness observed and decided. They are not always facts about the external world. effect.dispatch.returned can record a response, but only the effect ledger or authoritative service establishes whether the reservation committed. A trace is an evidence index, not the source of truth for the effect.

Provider tracing documentation offers useful vocabulary for runs, agents, models, functions, guardrails, and handoffs. That vocabulary is one current implementation. FieldOps preserves its own stable event contract and maps provider spans into it. [CLM-007]

Replay folds ordered events over an initial run record. It must reproduce state, counters, waits, and terminal disposition without calling a model or tool. If replay needs a provider API, the local event contract is incomplete.

Replay has three uses. During diagnosis, it reveals the first invalid transition. During evaluation, it verifies invariants across many trajectories. During migration, it tests whether a new harness version interprets old events compatibly. It does not recreate unrecorded external reality and cannot prove that a trace was truthful.

Store raw provider evidence separately when useful. A local proposal references the raw output, adapter version, and parse result. If the adapter changes, engineers can explain why the same provider output would map differently without mutating the original event.

Privacy and evidence minimization

Inspectability does not mean copying every prompt, token, credential, and record into one trace. For each field, decide whether to retain raw content, a redacted view, a hash, a typed summary, or only an external reference. Security and privacy owners define formal policy. The harness owns faithful enforcement and clear gaps.

Never place access tokens, secrets, or approval credentials in model context or trace payloads. Preserve enough semantic information to reconstruct the decision: resource identifier, scope, policy decision, proposal hash, effect ID, and reason code.

5. Enforce limits and cancellation

AR-03 starts with four budgets: turns, actions, elapsed milliseconds, and effects. Real systems may add tokens, money, reads per source, approval attempts, queue time, or retrieved bytes. Each counter is monotonic and checked before the governed action.

A single global timeout is inadequate. It cannot explain whether a run exhausted reasoning turns, tool calls, an external wait, or effect attempts. Separate budgets produce precise dispositions and safer recovery.

When a read action reaches its limit, the harness denies it and moves to failure or escalation according to policy. The model cannot negotiate extra budget. A principal or operator can create a new governed decision if policy allows, with an event explaining the change.

Cancellation requires three checks: on receipt, before every new proposal or tool dispatch, and immediately before an effect. A model that ignores a cancellation message is irrelevant because the harness state is authoritative. A capability that cannot be interrupted may still finish; the run records its late result without allowing a new action and reconciles any possible effect.

Waiting states need leases. WAITING_HUMAN records what exact approval is required and when it expires. WAITING_EXTERNAL records the external condition, next check, and deadline. Resume revalidates contract, principal, authority, resources, budgets, and cancellation. A process wakeup is not permission to continue.

6. Deterministic FieldOps fault lab

The companion uses a policy double instead of a live model. The double emits predefined proposals so every fault is reproducible.

Fault 1: unavailable-tool loop

The double repeatedly asks for a tool that is not in the admitted catalog. Validation denies the proposal. Repetition consumes the configured action or turn budget. The run ends FAILED with action_budget_exhausted; it never invents the tool or spin forever.

Fault 2: early success

After reading a manual, the double emits complete. Verification finds no fresh inventory, approval, effect, or verification record. The run remains non-complete and ends with missing-evidence reasons. The final prose is not graded as a reservation.

Fault 3: invalid arguments

The double proposes inventory lookup without partId. Schema validation denies dispatch. The invalid call never reaches a capability adapter. One bounded revision may be allowed; repeated invalidity reaches a terminal disposition.

Fault 4: ignored cancellation

Cancellation enters while the double is deciding. The double still emits a proposal. The harness sees terminal CANCELLED and rejects it. Stable run identity and sequence show which event won.

Fault 5: repeated effect

After one reservation effect, the double proposes it again. The effect counter is already one. The harness rejects the second dispatch even if the proposal and approval look valid. Chapter 5 will add idempotency and reconciliation inside the capability boundary.

Fault 6: illegal transition

The double emits a tool result while the run waits for approval. No declared transition matches. The harness records illegal_transition, preserves the waiting state or moves to the specified failure disposition, and alerts the owner.

Diagnose each fault in order: event validity, legal transition, contract assertion, budget, effect evidence, terminal disposition. Starting with model reasoning can waste time because invalid state may fully explain the behavior.

Walk a FieldOps run event by event

Start with run-fieldops-001 in CREATED. The immutable record points to [email protected], fieldops-policy@1, and deterministic-double@1. Counters are zero. No model message exists yet.

run.started moves the run to OBSERVING. The observer reads the synthetic request through a governed adapter and emits observation.recorded. Its event refers to the request record, source revision, and redacted content view. The next state is DECIDING.

The policy double emits read_equipment with one equipment identifier. The adapter creates a local proposal record. proposal.emitted moves to VALIDATING; it does not dispatch anything. Validation checks the schema, action catalog, read scope placeholder, resource, action budget, and current state. proposal.allowed enters EXECUTING.

The capability double returns a typed equipment observation. The harness validates output before recording it. observation.received returns to OBSERVING, then observation.recorded returns to DECIDING. The action counter is one and cannot decrease.

The same sequence gathers a manual passage and inventory record. Each loop produces distinct proposal, validation, dispatch, observation, and state events. A trace viewer may group them visually, but the event contract retains the causal order.

The double next proposes a reservation. propose_reservation is not an effect, so validation can execute canonicalization after checking evidence. The output includes a proposal hash. When the model proposes reserve_part, validation sees that an exact approval is required and emits approval.required, entering WAITING_HUMAN.

The process can stop. The event stream and run record persist. The model does not remain “alive” in a conversation. On approval receipt, a trusted input records the approval reference. The transition returns to VALIDATING, because every live precondition must be checked again.

Assume validation passes and reserve_part executes. The synthetic service returns an effect record. The harness enters VERIFYING, reads the authoritative result, and evaluates the completion predicate. completion.verified enters COMPLETED. The terminal event records every evidence reference and a final budget snapshot.

Now alter one fact. If the service commits but the response times out, effect.ambiguous enters RECOVERING. Chapter 5 defines the ledger lookup, but the state contract already prevents a blind transition back to execution. If cancellation arrives during recovery, CANCELLED becomes the disposition while reconciliation work is recorded as an operational obligation. Cancellation does not rewrite the effect history.

This walkthrough shows why one undifferentiated RUNNING state is inadequate. It cannot say whether the system is thinking, validating, awaiting authority, executing an effect, or verifying an outcome. Those distinctions determine what may happen next.

Design the event vocabulary

Event names should describe observed facts or harness decisions, not aspirations. proposal.emitted means an adapter produced a parseable local proposal. It does not mean the proposal is allowed. proposal.allowed records a deterministic validation outcome. effect.recorded means a referenced effect record exists. completion.verified means the named predicate passed.

Avoid names such as agent.finished, tool.success, or task.done unless their exact semantics are defined. They mix actor opinion, transport response, and product outcome.

Use a three-part event pattern when helpful: subject, change, qualifier. Examples include observation.recorded, proposal.denied, approval.expired, effect.ambiguous, and completion.rejected. Stable reason codes carry detail without creating a new event type for every message.

Actors are typed. model can emit a proposal. harness can decide a transition. human-principal can supply an approval reference. capability-adapter can record a validated result. resource-service can be the source of an effect record. Attribution does not confer authority; it makes the chain inspectable.

Event timestamps help order and diagnose, but sequence is assigned by the run’s authoritative writer. Wall clocks can skew. A real distributed design must define concurrency and ordering; Chapter 10 will address durable execution. AR-03 assumes a single local semantic transition writer.

Evidence references and integrity

An event reference should resolve to immutable or versioned evidence. Store the identifier, type, content hash where appropriate, retention class, and access rule. If evidence is later deleted under policy, retain a tombstone explaining what type existed and why it is unavailable, subject to privacy and legal requirements.

Do not calculate correctness from the trace alone. A malicious or faulty adapter could emit a well-shaped event without performing the effect. Verification queries the authoritative resource. Trace integrity, service truth, and policy correctness are separate assertions.

Specify the provider adapter

Provider APIs represent messages, tool calls, handoffs, and final output differently. The adapter has four jobs.

First, it builds the bounded model input from canonical state. It never lets chat history overwrite contract or authority. Second, it preserves raw provider output with provider and model version. Third, it parses that output into one local proposal type or a typed parse failure. Fourth, it emits metrics about context size, latency, and parse behavior without granting the provider response direct access to capabilities.

The local proposal union might contain ObserveAction, ProposeEffect, RequestClarification, RequestEscalation, and SuggestCompletion. Unknown provider output becomes INVALID_PROPOSAL. A provider-specific handoff is not accepted unless the local architecture has an admitted handoff type; FieldOps has none in this chapter.

Adapters must be tested against recorded raw outputs. A model upgrade and an adapter upgrade are separate changes. Replaying old raw evidence through a new adapter can reveal mapping drift, but production history retains the mapping originally used.

Framework convenience is welcome behind this seam. A framework may implement tool dispatch, traces, or resumable state. The team still owns the local transition contract. If the framework can call a tool without producing the required validation event, wrap or reject that path.

Make completion a proof obligation

Completion has three layers.

Structural completion says the run is in a legal terminal state with required event and evidence references. Task completion says the AR-02 predicate is satisfied. Outcome quality says the result meets the product or domain standard, which may require evaluation or human judgment.

FieldOps reservation completion is largely structural and task-verifiable. It needs the exact effect and authoritative verification. The claim does not extend unchanged to a research report, design, or conversation. Those outputs may need rubric-based graders, expert review, or later real-world evidence. [CLM-008]

Never use the acting model as the only grader of its own success. An independent model grader can still share correlated errors. Calibrate it against human judgments, version it, record uncertainty, and reserve human escalation for consequential or ambiguous cases. Evaluation guidance supports inspecting trajectories and outcomes rather than accepting a final answer, but local grader validity must be demonstrated.

For every completion assertion, record:

• predicate ID and version;
• required evidence types;
• evaluator and its authority;
• evaluation time and input references;
• pass, fail, or indeterminate result;
• uncertainty or disagreement;
• terminal transition allowed by each result.

indeterminate should not become success. It may trigger additional evidence, human review, escalation, or failure according to consequence.

Operational review packet

Ship AR-03 with six review views.

The state table lists purpose, legal inputs, legal outputs, timeouts, cancellation, and owner for every state. The transition table maps state and event to next state, guard assertions, counter deltas, evidence, and failure disposition. The event dictionary defines every type and field. The budget sheet defines units, limits, owners, and exhaustion behavior. The completion sheet maps predicates to authoritative evidence. The fault suite supplies deterministic traces and expected dispositions.

Review the packet with product, platform, model, security, domain, and authority owners. Product checks dispositions and completion meaning. Platform checks scheduler and store assumptions. Model specialists check adapter evidence. Security checks sensitive fields and denial paths. Domain owners check predicates. Formal authority owners check waits and effect gates.

The agentic AI engineer remains primary for local run semantics. The role does not claim ownership of the generic scheduler, event store, model quality, domain truth, or formal authority.

Review AR-03 v1.0.0

The dossier now contains thirteen states, sixteen local transitions, two global terminal transitions, four budgets, a required event field set, an external completion predicate, and six fault fixtures. The deterministic library demonstrates legal replay, illegal-transition rejection, cancellation precedence, stable run identity, monotonic counters, and independent completion.

The architecture adds explicit code. That is intentional. Hidden loops are concise until a failure must be explained, resumed, evaluated, or migrated. Explicit state creates a controlled seam for those later obligations.

It does not eliminate nondeterminism, prove model correctness, provide a distributed transaction, or replace a platform event store. Chapter 10 owns durable execution across crashes. Chapter 15 owns production telemetry. Here the agentic AI engineer owns the local semantic contract they must preserve.

Common loop failures and design trade-offs

Chat history as state. A conversation can omit, reorder, summarize, or reinterpret control facts. Keep it as model context derived from canonical state. Never calculate remaining effect budget or authority from prose.

One opaque framework loop. A framework may be reliable, but the application still needs to know which transition and assertion each callback represents. Adapt framework events into local semantics and reject routes that bypass them.

Model self-certification. Asking “Are you done?” can help elicit a proposal. It cannot establish completion. Verify task predicates and authoritative effects independently.

One global timeout. A global deadline prevents infinite runtime but provides weak diagnosis. Add turn, action, effect, and wait budgets with clear exhaustion dispositions.

Trace as source of truth. A trace shows what instrumentation recorded. It may be incomplete or wrong about an external service. Link to authoritative observations and verification.

Cancellation as a prompt message. A model may overlook or resist a message. Cancellation is a harness state checked before dispatch and enforced outside the model.

Recovery by replaying the last call. An interrupted effect can already have committed. Enter reconciliation with the original idempotency identity rather than repeating output from chat history.

Explicit states create more code and schema evolution. They also create places to attach tests, migration, operational ownership, and evidence. Do not create a state for every internal line of code. Create one when the legal actions, authority, waiting behavior, evidence obligations, or recovery differ.

Event detail has a similar trade-off. Too little detail makes replay meaningless. Too much copies sensitive payloads and binds storage to provider formats. Preserve stable semantic fields and governed references, then retain raw evidence only where justified.

Deterministic enforcement can become rigid. Expose policy variables such as limits and allowed capability versions, but keep their types, owners, ranges, and versions explicit. Flexibility is governed configuration, not a model escape clause.

Reader review drill

Diagnose each statement by naming the missing state or assertion.

• “The tool returned, so ask the model what to do next.” Output validation and observation recording must occur before DECIDING.
• “Approval arrived, so execute.” Resume enters VALIDATING; it must recheck cancellation, expiry, proposal equality, freshness, and budget.
• “The model says it finished the reservation.” Enter VERIFYING; require effect and postcondition evidence.
• “The worker restarted, so this is a new run.” Preserve runId; increment attempt and replay authoritative events.
• “The trace has two effect spans.” Query the effect ledger; spans do not establish two effects.
• “Cancel was clicked, but the model already generated a call.” The harness cancellation state wins before dispatch.
• “We can reset the action counter after a summary.” Counters are canonical and monotonic for the governed run.
• “A new SDK supports handoffs.” FieldOps still has no admitted handoff transition; Chapter 9 owns that contract.

For every answer, state the event, legal previous state, deterministic gate, evidence, and disposition. This is the operational skill the chapter assesses.

Phase 5 handoff fields

Chapter 5 needs more than the names of actions. AR-03 hands it the states in which a capability may run, proposal and validation event types, action/effect counters, cancellation checks, observation-result requirements, ambiguous-effect recovery state, and effect-evidence references.

A capability contract must declare which event it can produce. Reads produce validated observations. Proposals produce canonical proposal evidence. Effects can produce committed, rejected, or ambiguous outcomes. Unknown results cannot be converted into a normal observation.

The capability adapter must preserve the run identity and cannot select the next state. It returns a typed result; the harness applies the transition table. This prevents a service response or provider decorator from becoming an implicit control-flow owner.

Learning lab

Complete a transition table for every state. Add events for validation denial, approval decline, cancellation during execution, ambiguous effect, verification mismatch, and external-wait expiry. For each row, name the deterministic assertion, evidence reference, counter change, and disposition.

Then replay six fixture traces. The assessment allocates five points to legal transitions, five to deterministic enforcement, four to completion, three to cancellation, and three to replay evidence. Automatic failure occurs if a terminal run advances, the run ID changes, a counter decreases, or a model declaration enters COMPLETED without required evidence.

Implement the runner as a transition authority

The runner is not a while-loop around chat. It is the only local component allowed to change authoritative run state. Models, provider adapters, tools, reviewers, clocks, and cancellation sources emit proposals or observations. The runner validates them against AR-02, current state, expected revision, budgets, and ownership.

Define the run record:

{
  "runId": "run-401",
  "taskId": "task-401",
  "contract": "[email protected]",
  "state": "CREATED",
  "revision": 0,
  "attempt": 1,
  "ownerEpoch": 1,
  "componentSet": "bvs-04-1",
  "counters": {"turns": 0, "actions": 0, "effects": 0},
  "deadlines": {"run": "fixture+10m"},
  "cancelRevision": 0,
  "terminalDisposition": null,
  "lastEventId": null
}

Stable run identity groups attempts. Attempt identity distinguishes recovery executions. Owner epoch prevents stale workers. Revision provides compare-and-set state transitions. The chapter’s local fixture demonstrates these semantics; Chapter 10 will make durability and distributed ownership comprehensive.

Transition function

transition(run, expectedRevision, event):
  assert run.revision == expectedRevision
  assert run.terminalDisposition is null
  assert event.runId == run.runId
  assert event.componentSet is admitted
  assert event.type is allowed from run.state
  assert cancellation and budget policy permit transition
  assert AR-02 action/authority assertions pass where required

  next = transition_table[run.state][event.type]
  append_event(before=run.state, after=next, evidence=event.refs)
  update counters monotonically
  set state=next and revision=revision+1
  enforce terminal uniqueness

If any assertion fails, append a rejection/control event without applying the proposed transition. An invalid transition does not become a model message asking for correction unless policy explicitly permits a new proposal.

Enumerate every state contract

CREATED contains immutable task/contract/component identity and initial budgets. Its only normal transition is initialization into OBSERVING; invalid contracts fail.

OBSERVING admits a bounded request for existing state/evidence. It cannot execute an effect. A valid observation moves toward DECIDING; unavailable evidence may wait, retry within a read rule, fail, or escalate.

DECIDING invokes the model adapter with a versioned context projection. The model can propose observe, act, wait, handoff, stop, or final output. It cannot set authoritative next state.

VALIDATING checks schema, current state, contract, authority requirements, budgets, freshness, and cancellation. Accepted read/action moves to EXECUTING; accepted final output moves to VERIFYING; approval-required proposal moves to WAITING_HUMAN; invalid proposals return to decide only within correction budget or terminate/escalate.

EXECUTING invokes one admitted capability. It records dispatch evidence and cannot accept another model decision concurrently in this simple runner. Result moves to observation/verification/recovery according to typed semantics.

VERIFYING evaluates postconditions and the completion predicate against authoritative state/effect evidence. Pass moves to COMPLETED. Missing/ambiguous effect moves to RECOVERING or WAITING_EXTERNAL. Failed completion with remaining budget may return to observation; impossible completion fails/escalates.

WAITING_HUMAN has a checkpoint reference, allowed decisions, expiry, cancellation, and resume policy. No action executes merely because time passes.

WAITING_EXTERNAL names the external observation needed, deadline, owner, and safe timeout disposition. It is not an unbounded polling loop.

RECOVERING owns reconciliation and resolution of ambiguous execution. It cannot blindly redispatch an effect. Chapter 10 deepens this state.

COMPLETED, FAILED, CANCELLED, and ESCALATED are terminal. STOPPED can be modeled as terminal or a control transition to one of these explicit dispositions; FieldOps uses the explicit terminal reason. Exactly one terminal disposition is recorded.

Transition table fragments

Current	Event	Guard	Next
CREATED	run.initialized	contract/version valid	OBSERVING
OBSERVING	observation.admitted	provenance/schema/scope valid	DECIDING
DECIDING	model.proposal	adapter output valid envelope	VALIDATING
VALIDATING	proposal.read_admitted	contract/budget/cancel pass	EXECUTING
VALIDATING	proposal.approval_required	exact proposal formed	WAITING_HUMAN
WAITING_HUMAN	approval.admitted	live exact authority	VALIDATING
EXECUTING	action.observed	typed result admitted	OBSERVING
EXECUTING	effect.ambiguous	dispatch may have occurred	RECOVERING
VALIDATING	final.candidate	output schema valid	VERIFYING
VERIFYING	completion.passed	all external predicates pass	COMPLETED
any active	cancel.effective	ordering established	CANCELLED or containment

Every absent row is denied. This is safer than a default transition to DECIDING.

Define the model adapter envelope

Provider APIs expose text, function/tool calls, handoffs, structured output, refusal, and errors differently. Normalize them into a local proposal union:

ModelProposal =
  ObserveIntent(capabilityId, modelArgs)
  ActionIntent(capabilityId, modelArgs)
  HandoffIntent(targetClass, artifactRefs, reason)
  WaitIntent(reason, expectedEvent)
  FinalCandidate(outputArtifact, claimedEvidenceRefs)
  StopIntent(reason)

The envelope carries provider/model/adapter version, raw-output evidence reference, input-context hash, timestamp, and usage counters. Raw provider data is preserved under the appropriate evidence policy, not copied wholesale into run state.

Reject mixed or ambiguous outputs

If the adapter returns both final answer and effect call without a declared ordering, reject. If it emits two effect calls where the contract permits one sequential proposal, reject or serialize through an explicit planner policy; do not let provider ordering decide authority. If arguments fail schema, no capability executes.

A refusal may become an observation for the runner, not necessarily failure. A provider error maps to a stable local class. A handoff is a proposal to transfer work and context, not an ownership or permission transfer.

Keep provider convenience bounded

An SDK may implement a tool loop, tracing, guardrails, sessions, or resume. Those mechanisms are useful implementation examples. [CLM-007] The local runner still owns contract validation, run identity, counters, cancellation, completion, terminal disposition, and effect evidence. Hidden framework retries and automatic tool execution must be disabled, mapped, or included in the contract.

Record an event trail that can be interpreted

Each accepted transition produces an immutable event with event ID, run, attempt, owner epoch, sequence, previous/new state, type, actor/component, component set, proposal/action/effect references, validation results, budget snapshot, cancellation revision, time, reason, and integrity link.

Rejected proposals also create events. Otherwise a trace hides attempted prohibited behavior and budget consumption.

Sequence before time

Use monotonic sequence/revision for local ordering. Wall clocks support latency and cross-system correlation but can skew. An event cannot claim state revision 9 if revision 8 was never accepted. Late callbacks reference their original dispatch and are evaluated against current owner/state.

Observation versus authority

A model event proves the adapter observed model output. A validation event proves the local validator returned a result under a version. A tool span proves an invocation observation. Only authoritative state/effect systems prove their own records. Do not compute completion from a green trace span.

Replay modes

Audit replay reprocesses recorded events to reconstruct the accepted state path. It should reach the same terminal disposition or reveal corruption/incompatibility. It does not repeat external actions.

Decision replay feeds recorded observations into a candidate policy/model and compares proposals without applying effects. It evaluates behavior change.

Execution simulation runs against deterministic capability doubles and may create synthetic fixture effects. It is not a production replay.

Name the mode. “Replay the run” without this distinction can duplicate effects.

Replay assertions

Verify stable run ID, increasing event sequence/revision, legal before/after pair, monotonic counters, component versions, evidence-reference integrity, no action while waiting, no accepted event after terminal state, and exactly one terminal disposition. Where an event is missing, stop reconstruction rather than inventing it from timestamps.

Execute a complete FieldOps run

Run R-401 starts from [email protected] with read/propose authority and one approval-bound synthetic effect.

1. run.created records task, principal reference, component set, budgets, and state CREATED.
2. run.initialized validates contract and enters OBSERVING.
3. Initial observation records issue/equipment references and enters DECIDING.
4. Model proposes search_manual with bounded query. Adapter validates envelope; runner enters VALIDATING.
5. Contract admits read and budget; runner enters EXECUTING and invokes a recording double.
6. Valid manual passages enter as observation; state returns through OBSERVING to DECIDING.
7. Model proposes check_inventory; the same validate/execute/observe sequence occurs.
8. Model proposes reservation. Deterministic proposer canonicalizes it; validation sees approval requirement and enters WAITING_HUMAN.
9. Synthetic approval event arrives. Runner revalidates task/run/proposal/time and returns to VALIDATING.
10. Effect is admitted and executed by a double. Result includes effect reference; runner enters VERIFYING.
11. Completion verifier reads authoritative fixture state and checks exact effect plus required artifacts.
12. completion.passed moves to COMPLETED; final output is rendered from verified state.

The model made decisions at steps 4, 7, and 8. It did not choose state, authorize effect, or declare terminal truth.

Read the trace critically

Three model calls do not imply three turns under every provider; the local counter definition is versioned. A tool success response is not effect verification. Approval arrival is not effect dispatch. COMPLETED proves the local predicate passed against referenced fixtures; it does not prove customer, safety, or production outcomes.

Six hostile failure walkthroughs

1. Unavailable-tool loop

The policy double repeatedly asks for lookup_stock, which is not in the catalog. Each proposal enters validation and is rejected UNKNOWN_CAPABILITY. Correction budget increments. After the declared limit, the runner transitions ESCALATED or FAILED with no tool invocation.

Diagnosis order: adapter produced a valid proposal envelope; transition was legal into validation; contract/catalog assertion failed; correction budget stopped repetition; terminal disposition is unique. Do not add a similarly named broad tool to make the demo pass.

2. Early success

After reading a manual, the model emits a polished final candidate claiming the part is reserved. Validation admits it only as a candidate and moves to VERIFYING. Completion checks find no proposal, approval, effect, or verification. The runner returns to observation if budget/policy permit or fails with COMPLETION_EVIDENCE_MISSING.

The model statement remains an artifact. [CLM-008] It is not erased, but it cannot control state.

3. Invalid arguments

The model calls check_inventory without location and with quantity text in an unknown field. The provider schema may have allowed generation, but local validation rejects. No capability dispatch occurs. One bounded correction can expose required model-owned fields without revealing trusted scope.

Repeated invalid arguments hit action/turn budgets. The failure is selection/schema compatibility, not inventory outage.

4. Ignored cancellation

Cancellation revision 3 arrives while the model call is in flight. The model later proposes reserve_part. Before accepting the proposal and again before dispatch, the runner compares cancellation revision and denies. Run becomes CANCELLED; no effect occurs.

If cancellation arrives after possible dispatch, the runner cannot assert cancelled-no-effect. It enters recovering/containment and reconciles. Cancellation is a signal and policy transition, not time travel.

5. Repeated effect

The first synthetic reservation is verified and effect budget becomes one of one. A late duplicate model proposal arrives. Terminal-state invariant rejects all further proposals. If it arrived before completion, action/effect budget and semantic identity still deny a second effect.

Trace may show two model proposals and only one admitted effect. Count accepted effects from authoritative ledger, not proposal spans.

6. Illegal transition

A buggy callback attempts WAITING_HUMAN -> COMPLETED directly. Transition table has no row. Append transition.rejected with callback reference and remain waiting or escalate according to control policy. Never repair by inserting missing intermediate events after the fact.

The invalid event may reveal a framework adapter defect. Quarantine the component version and replay the fixture after repair.

Enforce budgets as state invariants

Define turns, model operations, proposed actions, admitted actions, effects, elapsed time, tokens, external cost, and waiting time separately. Chapter 16 will set operational budgets from distributions; Chapter 4 ensures counters cannot decrease or be ignored.

Increment at the boundary that owns the event. Model-operation count increments when dispatch occurs, even if provider fails. Proposed actions increment on admitted model envelope. Admitted actions increment after validation. Effects increment by authoritative semantic effect, not attempt.

Budget precedence

Cancellation and prohibited-action checks precede convenience retries. Hard effect/authority limits cannot be traded for unused token budget. A soft context budget may trigger compaction or escalation. Define precedence so simultaneous breaches yield one stable disposition and preserve all observations.

Deadline behavior

Run deadline does not mean kill every dependency blindly. Stop new actions, signal cancellation, classify in-flight operations, and reconcile possible effects. Waiting-human expiry follows approval policy. External wait deadline produces a typed disposition. One global timeout cannot express these consequences.

Counter mutation tests

Attempt to decrement turns on retry, reset actions after handoff, count reconciliation as a new effect, omit failed model dispatch, and continue after ceiling. Each mutation fails. Stable counters make evaluation and release claims interpretable.

Make cancellation testable

Cancellation record includes run, issuer/authority reference, effective revision/time, reason, scope, requested disposition, and event ID. The runner polls or receives it at declared safe points: before model dispatch, after model response, before capability admission, before effect dispatch, and during waits.

Test cancellation at each point. For read operations, stop future calls and decide whether to admit a late observation. For proposals, preserve or discard artifacts under policy. For waiting approval, invalidate or close the checkpoint. For effect dispatch, distinguish definitely not sent, sent unknown, and confirmed.

Stale owner

A recovered worker has owner epoch 4. The old worker at epoch 3 receives a late model result. Its event is recorded as stale/rejected and cannot mutate state. This anticipates Chapter 10 without pretending the local fixture solves distributed consensus.

Cancel versus complete

Cancellation and completion race at revision 12. Only one compare-and-set transition wins. If completion wins with verified effect before cancellation effective, record completed and handle any later consequence through policy; do not overwrite history. If cancellation wins before dispatch/verification, completion proposal is rejected. Ambiguous effect requires recovery, not arbitrary winner by UI timestamp.

Treat completion as a proof obligation

Compile the Chapter 3 predicate into named checks:

• required observations exist with provenance/freshness;
• proposal artifact is canonical and versioned;
• any effect has exact authority record;
• effect ledger contains at most the allowed semantic effects;
• authoritative state verifies expected part, slot, quantity, tenant, and status;
• prohibited actions/effects are absent in enforcement evidence;
• unresolved effects and mandatory escalations are zero or explicitly terminal;
• final artifact references the verified state version.

The verifier reads authoritative fixtures rather than model context. It returns pass, fail, or insufficient evidence with individual assertion results. The runner decides transition from that result.

Qualitative completion

Some tasks cannot use purely deterministic predicates. A research report may need a calibrated grader or expert review. Keep the grader separate from acting model, identify versions, validate on representative examples, report disagreement/uncertainty, and retain structural assertions such as required sources and prohibited effects. [CLM-008]

FieldOps reservation is chosen because its completion is mostly structural. Do not generalize its verifier to design quality, truth, or safety.

Negative completion evidence

Absence claims need reliable observation. “No prohibited action in sampled trace” is weaker than “capability broker has no admitted dispatch and effect ledger has no effect.” State which source is authoritative and what could be missing.

Diagnose from state before reading prose

When a run appears stuck, inspect current state, revision, owner epoch, cancellation, counters, last accepted event, pending external/checkpoint/effect references, and component set. Then follow evidence.

If state is WAITING_HUMAN, check checkpoint routing/expiry rather than model latency. If RECOVERING, inspect effect identity/reconciliation rather than resend. If VALIDATING repeats, inspect rejection reasons and correction budget. If VERIFYING, inspect missing predicate evidence.

Model transcripts can help explain a proposal but are not state truth. Trace dashboards can omit or misclassify events. Authoritative run/effect records govern their claims, and disagreement becomes an instrumentation finding.

Use the coding-agent case carefully

The accepted long-running coding-agent harness case demonstrates that progress artifacts and resumable structure can help work continue across context boundaries. Its files, checkpoints, and coding tasks do not establish FieldOps distributed transaction semantics or external effect recovery.

Transfer the narrow lesson: leave versioned, machine-readable progress and next-state evidence rather than relying on chat history. Do not transfer claims about approval, inventory effects, leases, or exactly-once behavior.

Provider tracing and agent-loop documentation similarly demonstrate available branches and vocabulary. They do not become the canonical state machine or proof of local completion.

Extended transition exercise

Complete the full state/event table for CREATED, OBSERVING, DECIDING, VALIDATING, EXECUTING, VERIFYING, WAITING_HUMAN, WAITING_EXTERNAL, RECOVERING, and terminal states. For every row name guard, counter changes, evidence, rejection, cancellation behavior, and next legal events.

Then specify tests for unavailable-tool loop, early success, invalid arguments, ignored cancellation, repeated effect, illegal transition, stale owner, late approval, ambiguous effect, missing event, and component-version drift.

Replay exercise

Given an event list with one missing revision, two equal timestamps, a late callback, and a trace span claiming success, reconstruct only supported state. Mark the gap. Do not order equal timestamps by convenience or treat span success as completion.

Run audit replay without effects, decision replay with candidate policy, and execution simulation against doubles. Explain why only the last can create synthetic fixture effects and none authorizes production replay.

Completion exercise

The model says “reserved”; tool response says success; effect ledger says SENT_UNKNOWN; inventory read is stale; approval is live. The correct state is recovery/wait, not completed or simple failed. Name the evidence required to resolve it.

Assessment rubric

The frozen 20 points remain legal transitions 5, deterministic enforcement 5, completion 4, cancellation 3, replay evidence 3.

Full transition credit requires explicit table, rejection, stable identity/revision, and one terminal state. Enforcement credit requires schema/contract/authority/budget/version checks outside model. Completion credit requires independent authoritative predicates and truthful insufficiency. Cancellation credit requires safe points, races, in-flight classification, and stale-owner denial. Replay credit requires immutable events, integrity/order, three replay modes, and no re-execution by audit.

Automatic failure occurs if model-declared success completes the run, invalid transition mutates state, cancellation is ignored before effect, counters decrease, more than one terminal disposition exists, or replay repeats an external effect.

Final AR-03 defense

The reviewer starts one valid FieldOps run and reconstructs every accepted transition from immutable events. Run ID stays stable; attempt/epoch changes are explicit; revisions and counters increase; each action points to AR-02 validation; one terminal disposition appears.

They then invoke the runner directly with illegal transitions, forged trusted fields, over-budget proposals, stale ownership, post-terminal callbacks, and early final output. Every mutation is rejected without relying on model obedience.

They cancel at every safe point and inject a commit-before-response-loss. Pre-dispatch cancellation prevents effect. Post-dispatch ambiguity enters recovery and never claims reversal. They remove one event and confirm replay reports a gap.

Finally, they swap provider adapter vocabulary while preserving the local proposal union. If semantics cannot map without ambiguity, the adapter is rejected. AR-03 remains provider-neutral and does not claim the finite state machine eliminates nondeterminism, framework defects, or external failure.

Detailed handoff to Chapter 5

AR-03 v1.0.0 gives each capability a precise invocation context: run/task/principal references, current state/revision, owner epoch, action proposal, contract validation, remaining budgets, cancellation revision, deadline, evidence links, and expected result event.

Chapter 5 must return typed observation/action/effect results. It must distinguish pre-dispatch failure, definite result, and ambiguous effect. It must supply stable capability/version, error class, semantic intent/effect identity, and reconciliation references. A generic exception or natural-language success cannot drive transitions.

The runner will not expose shell, SQL, browser, arbitrary API, or any real external system. FieldOps remains deterministic and synthetic. Chapter 5 can design narrow capability doubles against an inspectable action surface rather than embedding an invisible framework loop.

Operate the loop under callback and wait pressure

Real control flow is not a neat sequence of immediate responses. Approvals, external observations, cancellations, and provider callbacks can arrive late or out of order. Make their admission explicit.

Every asynchronous request creates a correlation record with run, attempt, owner epoch, dispatch event, expected response type, deadline, and allowed receiving states. A callback lacking the record is orphan evidence, not a transition. A callback for an old epoch is recorded and denied. A callback after terminal state cannot reopen the run.

Approval arrives after expiry

Run waits in WAITING_HUMAN until checkpoint expiry. The expiry event wins revision 14 and moves to ESCALATED. Approval arrives with the correct proposal at revision 15. It is historically meaningful but cannot transition the terminal run. The system records late_approval_rejected; it does not create a new run silently.

External read arrives after cancellation

An inventory read was dispatched before cancellation and returns afterward. Policy may retain the bounded observation for audit, but it cannot restart decision making. If the result contains sensitive data beyond now-valid scope, access/retention rules apply. Cancellation of workflow is not automatic deletion authority.

Provider returns duplicate completion

The adapter emits two identical final candidates due to transport replay. The first enters verification. The second has the same provider request identity but current state is already VERIFYING; it is deduplicated or rejected according to adapter contract. No second completion event appears.

Handoff arrives while owner changes

A worker proposes a handoff and loses ownership before acceptance. The proposal remains evidence, but only the current owner can apply an ownership transition under Chapter 9’s later contract. Chapter 4 records stale epoch and denies mutation. Context transfer never transfers authority by itself.

Specify failure and escalation records

FAILED means the run reached a declared technical/contract failure with no active recovery under this attempt. ESCALATED means a named external decision/evidence is required. CANCELLED means a valid cancellation won under the known ordering, with in-flight effects classified. Do not use one status for all unsuccessful endings.

A terminal record includes disposition, reason, deciding event, contract/component versions, final counters, cancellation revision, unresolved effect/checkpoint references, evidence completeness, owner, and allowed follow-up. The model can draft a user explanation only after this record exists.

Failed is not absent effect

A run can fail after an effect committed but verification or rendering failed. Terminal record links the confirmed effect and residual work. Conversely, a provider call can fail before any effect. Keep run outcome and effect outcome separate.

Escalation must be routable

Name owner class, evidence packet, decision requested, deadline, and safe state while waiting. “Ask a human” without routing, authority, and expiry is an unbounded wait. If no owner exists, reduce scope or fail safely.

Cancellation must be qualified

Record cancelled_no_dispatch, cancelled_effect_unknown, or another precise residual classification. A bare cancelled label can mislead downstream users into assuming nothing happened.

State-machine change procedure

Adding a state or transition changes behavior and replay compatibility. Propose the change with failure it solves, allowed incoming/outgoing events, invariants, counters, cancellation behavior, terminal mapping, migration for active records, and negative fixtures.

Suppose the team adds WAITING_RETRY. Reject it if it hides effect ambiguity or permits unlimited loops. If it is for a read-only transient error, specify attempt ceiling, backoff owner, deadline, cancellation, and return state. Effects with unknown outcomes belong in RECOVERING, not generic retry.

Suppose WAITING_HUMAN is split into WAITING_REVIEW and WAITING_AUTHORIZATION. The change can improve evidence but requires mapping old checkpoints, updating events, and preventing a review comment from becoming authorization. Replay old fixtures through a compatibility adapter and quarantine ambiguous state.

Preserve historical interpretation

Store state-machine/schema version on events. Do not reinterpret an old FAILED using a new reason taxonomy without a derived migration event. Historical claims remain tied to their version.

Event-store failure drills

Event append fails before state write

The transition is not committed. Retry the conditional transition under the same operation identity if the store can establish absence. Do not advance in memory and hope audit catches up.

State write succeeds but acknowledgement is lost

Read authoritative run revision before retry. If revision/event exists, return prior result. If outcome remains unknown, stop ownership transfer until reconciled. Chapter 10 expands durability, but the state machine must expose ambiguity now.

Duplicate event ID

Identical content can return the prior accepted result. Same ID with different content is integrity conflict and stops the run. Event idempotency is semantic, not simple ignore-on-duplicate.

Missing evidence object

Event references an artifact that has expired or was never stored. Replay can reconstruct state transition but cannot support the original evidence claim. Mark evidence incomplete and narrow any evaluation/completion conclusion.

Corrupted sequence

Two accepted events claim the same revision with different next states. Do not choose by timestamp. Quarantine the run and investigate storage/ownership. Exactly-one transition is an invariant, not a reporting preference.

Inspectability review questions

Can the current state be determined without reading chat history? Can every model output be identified as a proposal? Which deterministic assertion admitted each action? Which event proves cancellation was checked immediately before effect? Which source proves the effect? Can one run have multiple attempts without changing identity? Can stale callbacks mutate? Can counters reset? Can audit replay avoid effects? Can the model’s final output differ from completion truth?

Can a reviewer identify provider/model/tool/policy/schema versions? What happens if an adapter emits mixed final/tool output? Where do unknown effect outcomes go? Who owns each escalation? What terminal record remains after renderer failure? Which Chapter 5 error fields are required?

Any answer that depends on “the framework handles it” is incomplete until mapped to the local state/event assertion.

Additional counterexamples

Chat history as state. The conversation contains plans and past tool text but lacks authoritative revision, cancellation, ownership, budgets, and effect truth. Keep it as context projection.

One global green status. Model succeeded, tool timed out, effect is unknown, and run is shown green. Preserve layer-specific states and one evidence-backed disposition.

Trace replay executes tools. A debugging command resubmits tool calls. That is execution simulation or a dangerous live rerun, not audit replay.

Terminal state edited in place. An operator changes failed to completed after finding an effect. Append correction/reconciliation events under governed policy; preserve the earlier disposition and evidence.

Cancellation checked once. The run checks before model call but not before effect. Inject cancellation between them and require the final gate.

Model chooses recovery. After ambiguous timeout, the model says retry. Recovery policy and effect ledger decide; the model has no authority to reinterpret ambiguity.

AR-03 acceptance checklist

Verify stable run/task/component identity, attempts and epochs, expected revisions, explicit states, total transition table, proposal union, local schema/contract/authority/budget enforcement, monotonic counters, deadlines, cancellation safe points, waiting records, recovery state, completion verifier, immutable events, replay modes, and one terminal disposition.

Run the six frozen faults plus stale callback, late approval, cancellation/effect race, event append ambiguity, duplicate event conflict, missing evidence, and state-machine version migration. Assert no real effect and no invalid state mutation.

Verify claims stay bounded. The SDK example demonstrates one loop/resume pattern, not canonical architecture. The coding case supports progress artifacts, not distributed effects. The finite state machine makes control inspectable; it does not remove model nondeterminism, service failure, evaluation uncertainty, or organizational authority.

The packet passes when another engineer can rebuild current state, identify every rejected proposal, reproduce the deterministic faults, and explain exactly why completion did or did not occur without relying on model prose.

Perform a final state subtraction test. Remove run revision and demonstrate a lost-update race. Remove owner epoch and admit a stale callback. Remove cancellation revision and allow a post-cancel proposal. Remove effect reference and make completion unknowable. Remove component set and make replay uninterpretable. Remove terminal uniqueness and produce two contradictory endings. Each mutation must fail a named assertion.

Archive the state table, proposal union, event schema, adapter map, completion predicates, cancellation matrix, replay fixtures, counter definitions, and rejection log under AR-03 v1.0.0. Record that all services, identities, approvals, clocks, effects, and faults are synthetic. The evidence supports this harness version only; later tool, provider, policy, state, or adapter changes reopen the dependent claim.

The final reviewer also runs the harness with a deterministic policy that emits no useful action. The loop must terminate through budget or declared failure without inventing progress. Then the reviewer supplies a correct final artifact before required effect evidence exists. Verification must still reject completion. These cases show that inspectability is valuable even when the model is unhelpful: the harness preserves bounded state, evidence, and one honest ending.

Chapter checkpoint

FieldOps now has an inspectable loop but no implementation-grade capability surface. AR-03 v1.0.0 hands Chapter 5 stable action proposal types, legal state transitions, budget and cancellation assertions, event fields, and effect-evidence references. The next task is to decide which tools are narrow, legible, authorized, and recoverable enough to expose.