Design Human Checkpoints That Can Actually Work

A button labeled “Approve” does not create an authorized, available, informed reviewer. Human checkpoints are long-running states with queue, evidence, timing, expiry, rejection, takeover, cancellation, compatibility, and audit failures.

Runs can be paused and resumed from serializable state, as current SDK and experimental protocol mechanisms illustrate. That mechanism does not guarantee reviewer availability, evidence adequacy, authority, or compatibility after deployment. [CLM-021]

Seven different checkpoints

An information request asks for missing facts. A review asks for assessment. A confirmation verifies intent. An approval grants a bounded permission under policy. An intervention corrects or stops work. A takeover transfers operational ownership. Formal authorization is a domain or organizational act defined by the relevant authority.

They require different evidence and timing. Collapsing them into “human in the loop” hides who can decide what. [CLM-022]

The nouns belong in the contract and interface. An information request may accept any qualified source of a missing fact, while an approval must name a principal whose delegation covers the proposed effect. Review can return concerns without granting permission. Confirmation can prove that a user saw an exact proposal, but it does not replace organizational authorization. Intervention can narrow or stop a run. Takeover changes the accountable operator. Formal authorization may require signatures, dual control, licensing, or records outside the agent system.

FieldOps classifies the checkpoint before routing it. A part reservation may need an information request to identify equipment, a review of conflicting manuals, and approval for the exact inventory and slot effect. Combining them into one green button makes it impossible to know what the click meant.

Begin with the decision, not the button

Teams often start checkpoint design by choosing a widget: a modal, a chat reply, an approval button, or a ticket. That reverses the engineering order. The first question is not how a person responds. It is what decision must be made, by whom, under what authority, before which consequence becomes possible.

A useful checkpoint sentence has four parts:

Because trigger T occurred, principal P must make decision D over proposal V before effect E can become eligible.

For FieldOps, one sentence is: “Because a reservation proposal passed compatibility checks, the North inventory coordinator must decide whether to authorize proposal hash sha256:proposal-001 before one synthetic stock reservation can become eligible.” This sentence tells us why the checkpoint exists, who owns the decision, which immutable proposal is in scope, and which effect remains blocked. “Ask a human before reserving” tells us none of those things.

The sentence also exposes category errors. If the principal only knows a missing serial number, the checkpoint is an information request, not approval. If the principal can assess a compatibility conflict but cannot spend inventory, the checkpoint is a review. If a user must acknowledge the exact slot they requested, that is confirmation. If policy delegates a coordinator to grant permission, that is approval. Each response can feed the next state, but no response silently becomes a stronger act.

The seven-type matrix

Use the following matrix as a design worksheet. “Authority” means the authority required for this checkpoint, not every authority in the surrounding workflow.

Type	Question asked	Minimum evidence	Required authority	Typical disposition	Timing rule
Information request	What missing fact should the run use?	Known context, requested field, acceptable format, why it matters	Permission to supply or disclose the fact	supply, cannot supply, redirect, cancel	Valid until the fact or task context changes
Review	Is this analysis adequate, correct, or complete?	Artifact, criteria, provenance, disagreements, uncertainty	Competence and assigned review responsibility	accept review, return concerns, request revision, escalate	Before the reviewed artifact is relied upon
Confirmation	Is this the exact intent or proposal you recognize?	Exact object, consequence, alternatives, expiry	Identity of the person whose intent is being confirmed	confirm, deny, modify, cancel	Short lived and proposal-bound
Approval	May this bounded effect proceed under policy?	Exact effect, scope, evidence, consequence, alternatives, policy basis	Live delegation over the resource and consequence	approve, reject, require new proposal, escalate	Before effect, with expiry and revalidation
Intervention	What bounded correction or stop must be applied now?	Current run state, observed deviation, reachable controls, consequences	Operational authority over the correction or stop	stop, constrain, replace input, redirect, escalate	While intervention can still affect the run
Takeover	Who becomes the sole operational owner now?	Full current state, open ambiguity, pending effects, leases, callbacks	Authority and ability to accept operational ownership	accept transfer, decline, cancel, escalate	Atomic with revocation of the displaced path
Formal authorization	Has the domain-defined authorization act occurred?	Records and ceremony required by the governing domain	Authority defined outside the agent application	authorized, denied, incomplete, expired	According to the governing rule, not UI convenience

This matrix is not a maturity ladder. Approval is not “more human” than review, and takeover is not simply a large approval. They are distinct control relationships. An information request can be high consequence if it asks for sensitive data. A review can be advisory even when the reviewer is a renowned expert. Confirmation can be legally or operationally significant, but the application must not infer that significance from the label alone. Formal authorization can sometimes be recorded through an application, but its validity comes from the governing domain and authority, not from the rendering of a button. [CLM-022]

Information request: collect a fact without smuggling a decision

An information request needs a field contract. State what is missing, what formats are valid, how the answer will be used, which data should not be supplied, and what happens if the person cannot answer. Structured elicitation patterns can support this exchange, including response states and sensitive-data constraints. They remain interaction mechanisms, not proof that the answer is accurate or authorized for every downstream use.

Suppose FieldOps cannot match “pump near the loading bay” to an equipment record. It asks the site reporter for an equipment tag. The reporter replies EQ-104. That answer may resolve identity, but it does not approve maintenance, disclose inventory, or authorize a reservation. FieldOps must validate the tag against the permitted equipment directory. If the reporter pastes a credential instead, the client should refuse or redact it according to the field contract. If the reporter selects “I cannot identify it,” the run follows a declared ambiguity route rather than guessing.

An anti-pattern is a question whose answer mixes fact and permission: “Is this pump EQ-104 and should we book the 14:00 slot?” A person might mean yes to identity but not scheduling, or the reverse. Split the checkpoints and preserve both records.

Review: solicit judgment without inventing permission

A review compares an artifact against criteria. The reviewer needs the artifact version, review criteria, important provenance, known conflicts, and the expected form of feedback. “Looks good” may close a review task, but it cannot grant an effect unless the same principal separately has approval authority and the interface makes that second act explicit.

FieldOps encounters two manual editions with conflicting torque guidance. A maintenance specialist reviews the extracted passages, edition dates, equipment applicability, and conflict note. The specialist may say, “Edition 7 applies; revise the plan.” That is valuable judgment. It does not reserve a part or dispatch a technician. A later proposal incorporates the reviewed result and goes through its own authority path.

Review design should permit partial and negative judgments. Useful outcomes include accepted, accepted with named limitations, revision required, insufficient evidence, conflict unresolved, and out of scope. A binary pass button pressures reviewers to compress uncertainty into false certainty.

Confirmation: verify intent against an exact representation

Confirmation asks whether the displayed representation matches the person’s intent. Current product confirmation and active-supervision patterns show why a state-changing action may be surfaced immediately before execution. They also retain residual risks: a person can be rushed, inattentive, manipulated, or confused; the display can omit a material consequence; and confirmation does not create organizational delegation. The Operator and ChatGPT agent confirmation case is therefore a bounded design contrast, not evidence that confirmation makes execution safe.

Good confirmation names the action, target, quantity, recipient, timing, and material consequence. If any changes, confirmation is invalidated. A prompt such as “Confirm changes” is too weak when three resources and two external recipients are affected. A concise table can be easier to inspect than fluent prose because stable fields reveal mutations.

In FieldOps, the requester may confirm, “Yes, the incident concerns EQ-104 at North Dock and the requested service window is 14:00-16:00.” That establishes intent about the report. It does not establish inventory authority or technician eligibility.

Approval: grant bounded permission, then validate again

Approval is permission over a particular proposal. It needs a principal with a live delegation, an exact scope, an expiry, a one-use rule when appropriate, and a consequence the reviewer can understand. An approval response changes the run from “permission absent” to “permission recorded.” It does not change inventory, acquire a worker lease, freeze policy, or perform the effect.

Think of approval as an input to an execution guard:

eligible = approval.valid
  and approval.proposal_hash == current.proposal_hash
  and reviewer.delegation.covers(current.effect)
  and current.resource_state.is_fresh
  and current.contract.is_compatible
  and run.owner_lease.is_live
  and budgets.allow(current.effect)

Every term can become false after the click. That is why approval resumes into validation, not into effect. The expression is intentionally conjunctive. A model score, a senior job title, or a fast response cannot compensate for an expired delegation or changed proposal.

Intervention: preserve a narrow control path

Intervention lets a person stop or correct work without necessarily accepting full ownership. Examples include “stop after the current read,” “do not contact the vendor,” “use the verified equipment record only,” and “return this run to proposal state.” The contract must say which state changes the intervention permits and who remains accountable afterward.

An intervention received after a queued effect has already committed cannot erase the effect. It can stop new work, trigger reconciliation, or begin compensation under a separate authority path. The interface must distinguish “stop future actions” from “undo completed action.” Otherwise a red stop button creates a false promise.

Takeover: transfer control, context, and accountability together

Takeover is a handoff, not an elevated chat message. It transfers one owner lease, revokes the agent’s pending effect capability, marks queued callbacks non-authoritative, and provides the operator with current durable state. The operator needs more than the last message: they need the proposal, evidence versions, current budgets, unresolved ambiguity, pending timers, issued tokens, committed effects, and reconciliation status.

If the agent and operator can both continue, takeover has failed. The correct implementation is a compare-and-swap on ownership or an equivalent atomic transfer. A late worker must observe that its lease no longer authorizes mutation. The audit record names old owner, new owner, transfer time, reason, state version, and revocations performed.

Formal authorization: integrate without pretending to define it

Some decisions depend on a signature ceremony, dual control, a licensed professional, a regulated record, a procurement threshold, or a labor agreement. Agent engineers should model the integration point and evidence receipt, while the relevant organizational, legal, security, safety, or domain owner defines validity.

Do not rename application approval as formal authorization to make the architecture look complete. Instead, record a requirement such as external_authorization_type, governing_policy, authorized_principals, evidence_reference, issued_at, expires_at, and verification_method. The system can verify a signed receipt or authoritative status if the domain supplies one. It still does not decide that the ceremony was legally or professionally sufficient.

A classification procedure that survives ambiguity

For every proposed human touchpoint, answer these questions in order:

1. What new fact, judgment, intent, permission, control, ownership, or formal record must exist afterward?
2. Which exact downstream transition is blocked until it exists?
3. Who is competent to respond, and who is authorized to bind the resource or organization?
4. Can one person play multiple roles? If so, how will each act remain explicit?
5. What evidence must be visible, and which sensitive material must stay hidden?
6. When does the response become stale?
7. What are reject, modify, no-response, cancel, escalate, and takeover semantics?

If the answer to the first question contains “and,” split the touchpoint until each decision can be recorded independently. If the downstream transition is “the agent continues somehow,” the checkpoint is underspecified. If authority is “whoever receives the notification,” routing has been mistaken for delegation.

Durable interrupt and resume

The checkpoint binds type, trigger, exact decision, proposal hash, evidence view, uncertainty, consequence, alternatives, reviewer, authority basis, issue and expiry, SLA, permitted dispositions, fallback, cancellation, resume compatibility, and audit.

The run enters WAITING_HUMAN durably. Approval returns it to validation, never directly to effect. Resume checks reviewer authority, rejection/cancellation, one-use state, proposal equality, delegation, token, inventory freshness, deployment compatibility, owner lease, and budgets.

Pause and resume form a protocol. The interrupt atomically records the checkpoint and relinquishes execution ownership. A response records reviewer identity, disposition, time, bound proposal hash, and evidence version. The resumed worker acquires a fresh lease and compares every mutable dependency. If relevant input changed, the old response remains auditable but cannot authorize the changed effect.

There is no magic continuation. An SDK can serialize state; an experimental task mechanism can represent waiting; an elicitation form can collect a response. None proves the respondent may decide, that evidence is sufficient, or that the decision is still live. [CLM-021]

Model the checkpoint as a state machine

Do not implement the pause as a suspended process that hopes to wake up. Persist a state transition that another compatible worker can understand. A minimal lifecycle is:

PROPOSING
  -> CHECKPOINT_ISSUED
  -> WAITING_HUMAN
  -> RESPONSE_RECORDED
  -> RESUME_VALIDATING
  -> READY_FOR_EFFECT | REJECTED | EXPIRED | CANCELLED | ESCALATED | TAKEN_OVER

READY_FOR_EFFECT still means eligible for the effect path, not that the effect occurred. Chapter 10’s effect ledger remains responsible for invocation, receipt, ambiguity, reconciliation, and compensation. Human checkpoint state must never be overloaded as an effect receipt.

State transitions need guarded commands. recordResponse should require the expected checkpoint version, an open status, a permitted disposition, an authenticated respondent, and an exact proposal hash. beginResume should require a recorded response and acquire a fresh owner lease. markReady should require all revalidation checks. takeOver should atomically replace the owner and revoke the displaced execution path.

Persist events and current state. The current record makes decisions fast; the append-only event history explains how the record arrived there. A useful history includes checkpoint.issued, route.attempted, response.recorded, response.rejected_as_unauthorized, checkpoint.expired, resume.started, resume.validation_failed, owner.transferred, and checkpoint.cancelled. Store reason codes and references, not only free-form messages.

The interrupt transaction

The interrupt boundary is easy to get subtly wrong. Imagine a worker sends a notification and crashes before saving WAITING_HUMAN. A replacement may execute because it sees no checkpoint. Reverse the order and another failure appears: the worker saves a checkpoint, crashes before routing it, and nobody knows the run is waiting.

The durable solution separates authoritative state from delivery. In one local transaction, write the checkpoint, transition the run to WAITING_HUMAN, relinquish the execution lease, and enqueue an outbox delivery keyed by checkpoint ID. A delivery worker can retry notification without creating a new checkpoint. If notification permanently fails, routing state escalates according to policy; the run does not become implicitly approved.

Where the storage system cannot provide one database transaction across all components, use revision-guarded writes and reconciliation. The invariant is more important than a particular framework: once a checkpoint is authoritative, no effect path may proceed without its valid disposition, and notification delivery must be recoverable and deduplicated.

The response transaction

A response is data with identity and binding, not a message string. Record at least:

{
  "checkpointId": "cp-0081",
  "checkpointVersion": 3,
  "proposalHash": "sha256:proposal-001",
  "respondentPrincipal": "reviewer-07",
  "authenticatedSession": "session-reference",
  "disposition": "approve",
  "reasonCode": "within-policy",
  "commentReference": "comment-004",
  "evidenceViewVersion": 2,
  "respondedAt": "2026-08-16T10:09:00Z"
}

Authentication answers which principal controlled the response channel. Authorization answers whether that principal had the required delegation over this decision. The system must check both. A forwarded link may authenticate the wrong person. A correct reviewer whose delegation has expired may be identifiable but unauthorized. A shared mailbox may deliver operationally useful notices but cannot by itself establish which principal made the decision.

Concurrent responses need deterministic resolution. If one reviewer rejects while another approves, do not accept whichever write arrives last. The policy should define whether the first valid disposition closes the checkpoint, whether dual control is required, or whether conflicting responses force escalation. Record losing responses as attempts with a reason such as checkpoint_already_closed; do not delete them.

Resume from meaning, not a stack frame

Serializable state is only useful if its meaning survives. Persist business identifiers, contract versions, source references, and state revisions. Do not depend on an in-memory closure, temporary object, or model transcript position. A new worker may run on another host after a deploy. It should reconstruct the next decision from the durable record and compatible code.

The resume sequence is deliberately conservative:

1. Load the checkpoint, run, proposal, approval, and effect-contract records by stable ID.
2. Acquire the run owner lease using the expected run revision.
3. Verify the checkpoint is closed by a permitted, authoritative disposition.
4. Verify the response is unused, unrevoked, and inside its validity window.
5. Recompute or retrieve the canonical proposal hash and compare it exactly.
6. Revalidate respondent authority and the task’s delegation envelope.
7. Revalidate mutable resource state, capability version, policy, token, and budgets.
8. Check checkpoint schema and deployment compatibility.
9. Persist the validation result and intended next transition.
10. Enter the effect path only when every required guard is true.

If a guard fails, the run does not “best effort” its way forward. A changed resource produces a new proposal. An expired approval denies resume. A revoked token requires reauthorization. An incompatible deployment migrates the state through an explicit, tested adapter or stops. An exceeded budget escalates or terminates. The historical response remains true as a record of what the reviewer decided at the time; it simply cannot authorize a different present action.

Compatibility across deployments

Long-running checkpoints cross release boundaries. A response may arrive after the application has changed its proposal schema, policy engine, capability contract, or interpretation of a disposition. A deploy that can read bytes is not necessarily semantically compatible.

Version the checkpoint schema, proposal schema, authority policy reference, and effect contract. Define a compatibility table:

Change	Safe resume behavior
Add optional display-only evidence	Resume if canonical proposal and authority semantics are unchanged
Change quantity or slot field	New proposal and new checkpoint
Rename a disposition with identical tested meaning	Migrate through explicit adapter
Change who may approve	Revalidate under current governing rule; deny or reroute if no longer covered
Change effect capability semantics	Stop or create a new proposal under the new contract
Remove support for checkpoint version	Quarantine and require operator migration or cancellation

Avoid a universal “schema version greater than” check. Compatibility is about meaning. A minor-looking code change can alter authority or consequence, while a larger storage migration can preserve both exactly.

Why framework support is necessary but insufficient

Current SDK approval examples demonstrate useful mechanics: a tool call can request approval, a response can reject, and serializable run state can support later continuation. Current experimental long-running task semantics can represent work that waits and later changes state. These primitives reduce implementation burden and make interruption testable. They support [CLM-021].

They cannot answer local governance questions. Which inventory coordinator covers tenant North? What evidence must that person see? Does approval expire after five minutes? What happens if inventory changes? Can an alternate reviewer take over? Is an external authorization receipt required? Does a deployment preserve checkpoint semantics? Those are application contracts and organizational decisions.

Treat the framework as a transport and persistence helper behind your own checkpoint interface. Keep authoritative fields in a product-owned schema, translate framework events into that schema, and test the local invariants. This reduces lock-in and prevents a convenience API from becoming the accidental definition of authority.

Recovery walkthrough: response arrives during a crash

FieldOps issues cp-0081, writes WAITING_HUMAN, relinquishes lease L19, and sends the review card. At 10:09, reviewer reviewer-07 approves. The response service authenticates the principal and writes response-22, but crashes before updating the checkpoint summary.

A reconciler scans open checkpoints with recorded responses. It observes response-22, checks that the checkpoint version and proposal hash match, verifies the response was within time, and advances the summary to RESPONSE_RECORDED. No second approval is requested. A resume worker acquires lease L20 and begins validation.

Now suppose the original response service restarts and retries its summary update. The revision guard fails because the summary already advanced. It reads current state, finds its response recorded, and treats the operation as idempotently complete. It must not overwrite a later rejection, expiry, or takeover. This is why response identity and state revisions matter.

Now change one fact: inventory was consumed at 10:10, before resume validation. The approval event remains valid historically, but inventoryRef=inventory-12 no longer describes the available stock. FieldOps records resume.validation_failed with reason availability_changed, releases the lease, and creates a new proposal if an alternative exists. It does not reinterpret the old approval as permission to choose any substitute part.

Evidence a reviewer can use

Show the exact synthetic part, slot, quantity, compatibility and inventory references, observation time, uncertainty, consequence, and alternatives. Provide drill-down sources. Do not expose hidden chain-of-thought; it is neither necessary evidence nor a reliable authority record.

Confirmation UX from current products and structured elicitation are bounded interaction examples. They do not prove the reviewer has formal authority or that the action is safe.

Evidence should be layered. The first view presents the decision, high-consequence facts, uncertainty, and expiry. Drill-down opens cited manual passages, inventory snapshots, capability receipts, prior effects, and conflict notes. The interface distinguishes observed facts from model inferences and policy decisions. It never uses confidence decoration to hide missing evidence.

The proposal hash prevents approval of a moving target. A changed slot, quantity, technician, incident, or capability version creates a new proposal. Modifications are not silent approvals: they return a bounded proposal through validation and, when policy requires, another checkpoint.

Build the evidence view as a decision instrument

The evidence surface is not a compact version of everything the agent saw. It is a purpose-built instrument for one human decision. Its job is to let the reviewer verify the proposal, inspect material support, understand uncertainty and consequence, and choose among real dispositions within the available time.

Start with an evidence schema, not a generated narrative. A practical schema has six layers:

1. Decision header: checkpoint type, exact question, proposal ID and hash, current status, issue time, expiry, and reviewer role.
2. Proposed effect: action, resource, parameters, quantity, recipient, timing, capability, and effect consequence.
3. Material support: validated facts with observation time, source status, and provenance reference.
4. Uncertainty and conflict: uncertain propositions, missing facts, contradictory evidence, and how each affects the decision.
5. Alternatives: reject, request a new proposal, choose a declared non-effect path, escalate, cancel, or take over where permitted.
6. Control footer: authority basis, response semantics, no-response fallback, audit notice, and links to permitted drill-down.

The main view should fit the decision’s attention budget. That does not mean hiding detail. It means arranging detail in layers. High-consequence facts and exceptions appear immediately; source documents and prior events remain reachable. A reviewer should never need to infer which timestamp qualifies which fact.

Consider two evidence statements:

Part A17 is available. Confidence: 94%.

Inventory record inventory-12 reported quantity 1 for part-A17 at 10:03 UTC.
The record is 8 minutes old. One competing reservation is unresolved.
If the quantity is no longer available, this proposal must be regenerated.

The second is longer but decision-useful. It names the source, time, unresolved condition, and consequence. The first offers an unexplained score that can create comfort without revealing what is uncertain. Uncertainty belongs to propositions: “compatibility between revision C housing and part A17 is unresolved,” not “the agent is 72% confident.”

Separate facts, inferences, policy, and recommendation

A strong evidence card visually and structurally distinguishes four epistemic roles:

• Observed fact: a value read from an authoritative or named source at a stated time.
• Derived inference: a conclusion computed or modeled from stated inputs.
• Policy rule: a governing constraint and its version or owner.
• Recommendation: a proposed disposition with reasons and acknowledged limitations.

If FieldOps says “coordinator approval required,” the reviewer should be able to tell whether this is a policy rule or a model recommendation. If it says “part compatible,” the reviewer should see whether compatibility came from an exact table match, a specialist review, or a probabilistic inference. Mixing these categories encourages authority laundering: a recommendation sounds like policy, or a retrieved sentence sounds like verified fact.

Use stable field order and explicit absence. manualEdition: unknown is safer than omitting the field and allowing the reviewer to assume it was checked. Highlight changed fields when a new proposal follows an earlier one. If only the slot changed, show that fact and explain why the change requires a new decision.

Evidence minimization is a control

More evidence is not automatically better. An overloaded reviewer can miss the one fact that invalidates the action. Excess data can reveal unrelated tenant records, personal information, or credentials. Raw tool output can contain untrusted instructions. Hidden model chain-of-thought can expose sensitive context and is not a reliable justification artifact.

Minimize by relevance and authority. Include what the reviewer needs for the named decision, with provenance-preserving links for permitted drill-down. Redact fields outside scope. Resolve source content into a safe rendering. Mark untrusted annotations as untrusted. Preserve the evidence reference and hash in the audit record so the organization can reconstruct what was shown without storing unnecessary secrets in the checkpoint itself.

Do not ask reviewers to inspect chain-of-thought. Provide conclusions, supporting facts, uncertainty, alternatives, and traceable source excerpts instead. This is both more actionable and more auditable. A reviewer can challenge a cited compatibility rule; they cannot reliably validate a stream of hidden internal reasoning.

Worked evidence audit

Audit the FieldOps card one field at a time:

Field	Value	Reviewer question	Failure if absent
Proposal	sha256:proposal-001	Am I deciding this exact object?	Approval can drift to changed parameters
Effect	Reserve 1 of part-A17 for slot-B2	What will change?	Generic permission is misapplied
Compatibility	compat-7, manual edition 7	Why is this part eligible?	Reviewer cannot inspect technical basis
Inventory	inventory-12, observed 10:03	How fresh is availability?	Stale state looks current
Consequence	One synthetic stock unit becomes unavailable to other runs	Who or what is affected?	Cost is hidden
Uncertainty	One competing reservation unresolved	What could invalidate the proposal?	Reviewer receives false certainty
Alternatives	reject, new proposal, take over	Can I decline or redirect?	Approval becomes coercive
Authority	North inventory coordinator	Why can I decide?	Routing masquerades as delegation
Expiry	10:18	Until when can this decision control execution?	Old responses remain usable

Now imagine the card says only “Reserve recommended part?” with approve and deny buttons. It hides quantity, stock consequence, observation time, unresolved competition, authority basis, and expiry. The workflow technically includes a human, yet the person cannot perform a bounded review. The checkpoint is decorative.

Interpret product and protocol examples narrowly

The approved confirmation case shows that deployed agent products can surface state-changing actions for confirmation and active supervision. It is useful evidence that interruption and confirmation controls are practical interface patterns. It also documents residual product risk. It does not demonstrate that the person holds organizational authority, that every relevant fact is visible, or that confirmation prevents manipulation.

The approved protocol-design case shows useful interaction states and authorization patterns across a client and server ecosystem. It helps separate elicitation from resource-scoped authorization and warns against treating sessions or forwarded credentials as identity. It does not define FieldOps policy, create inventory delegation, or guarantee a reviewer will respond.

This disciplined interpretation matters. A reference implementation can show that a mechanism exists. A system card can reveal a product control and its limits. Neither replaces a local threat model, authority map, evidence study, or failure test. The chapter’s two claims stay bounded to pause/resume capability and checkpoint-type distinctions. [CLM-021] [CLM-022]

Counterexamples that look reasonable

The senior reviewer: A vice president receives the approval because the coordinator is absent. Seniority does not imply resource-scoped delegation. If policy does not cover the proposal, deny approval and escalate through a defined authority path.

The comprehensive transcript: The system displays the entire conversation and tool trace. The reviewer cannot find the stale inventory timestamp among hundreds of lines. Completeness without decision structure is not adequate evidence.

The helpful modification: A reviewer changes quantity from one to two and clicks approve. The original hash no longer matches. Treat the edit as input to a new proposal, recheck compatibility, inventory, budgets, and policy, then issue any required checkpoint.

The permanent approval: A manager approves “all similar reservations this week.” That may be a delegation policy proposal, not approval of this exact effect. Model and authorize it separately, including scope, limits, revocation, and monitoring. Do not stretch a one-effect checkpoint into standing authority.

The explanation score: A model-generated rationale is fluent and cites three records, so the UI labels it verified. Citation presence is not source validation. Show which assertions were checked, against what, and when.

Timing, rejection, and takeover

If availability changes after review, create a new proposal and approval. Expired delegation or approval denies resume. An unauthorized reviewer cannot approve. No response expires and escalates. An incompatible deployment migrates the checkpoint or stops. Rejection is terminal for that proposal and is never treated as a transient error.

Takeover transfers one accountable owner, revokes the agent’s pending effect path, and gives the operator current state and evidence. Cancellation stops new work. Neither takeover nor intervention rewrites committed effects.

Human attention is finite. High friction can create bypass pressure; low friction can create fatigue. Human-factors, staffing, labor, legal consent, and formal domain authority remain specialist-owned. AR-08 defines the technical checkpoint and honest fallback.

Engineer the queue as part of the control

A checkpoint that reaches the right role after the decision window closes is not operationally reachable. Routing, staffing, and attention are different problems from serialization. The system needs enough queue policy to detect and handle unavailability honestly, while workforce design and labor policy remain with their appropriate owners.

Track at least four times:

• issuedAt: when the authoritative checkpoint and evidence version were created.
• deliveredAt: when a notification channel acknowledged delivery, if it did.
• slaAt: when routing should escalate or an operational objective is missed.
• expiresAt: when the response can no longer authorize resume.

Also track the observation times of mutable evidence. Those can be older than issue time and may have their own freshness limits. A checkpoint issued at 10:00 can contain inventory observed at 09:40; a response at 10:02 may be inside approval expiry while the inventory evidence is already too stale for effect. Resume revalidation catches this distinction.

The SLA is an operational promise, not permission. Missing it might page an alternate, raise priority, or cancel a low-value run. It must not turn silence into approval. Expiry is a validity boundary. It can arrive before or after the SLA. For a high-volatility resource, approval might expire in five minutes while the organization aims for a two-minute response. For an advisory review, a one-day SLA might coexist with a seven-day artifact validity period.

Route by authority and availability

Maintain a resolver that maps the decision scope to eligible principals or roles. The resolver checks tenant, resource class, consequence threshold, conflicts, delegation interval, and any separation-of-duties rule. Then an availability layer chooses among eligible recipients. Reversing those steps sends decisions to whoever is free and hopes they are authorized.

A routing record should explain:

decision_scope: tenant North, inventory part-A17, quantity 1
required_role: synthetic-inventory-reviewer
eligible_principals: reviewer-07, reviewer-11
excluded_principals: reviewer-02 (tenant mismatch), reviewer-05 (delegation expired)
primary: reviewer-07
fallback: reviewer-11
escalate_at: 10:12
expire_at: 10:18

Availability can change. If the primary goes offline, rerouting the open checkpoint is acceptable when the fallback has the same required authority and sees the same evidence version. Do not mutate the proposal or lower the authority threshold to achieve the SLA. If no eligible reviewer is reachable, stop or escalate according to the declared fallback.

Notification channels should carry a reference, not all sensitive evidence. The authenticated review surface retrieves the current checkpoint and shows if it is already closed, expired, or superseded. Signed links need audience, expiry, and one-use or replay protections appropriate to the threat model. A forwarded notification cannot become bearer authority.

Expiry and revalidation are independent guards

Expiry protects against decisions that are too old by policy. Revalidation protects against relevant state that changed even within the valid window. You need both.

Suppose the FieldOps approval lasts fifteen minutes. A coordinator approves after two minutes, but a competing run consumes stock after three. The approval is unexpired and still unusable for the old proposal. Conversely, inventory might remain unchanged for an hour, but a fifteen-minute approval is expired because the authority contract intentionally limits how long the decision can be held.

Define the revalidation set from the proposal and effect contract. It normally includes the proposal hash, resource state revision, delegation, approval status, capability schema, policy version, owner lease, token audience and expiry, relevant budgets, cancellation, and prior effect ledger state. Avoid “revalidate everything” as an untestable requirement. Name each dependency and its failure disposition.

No response is a first-class outcome

Silence can mean absence, overload, notification failure, uncertainty, refusal to engage, or an abandoned task. The system cannot infer consent or rejection. At SLA, it can remind within an attention budget or escalate to an authorized fallback. At expiry, it marks the checkpoint unusable. Then the declared policy selects cancel, stop unresolved, route to a different authorized role, or transfer the run.

Limit reminders. Repeated prompts can pressure a person to approve merely to clear the queue and can recreate a rejected action under a new notification. Record reminder count and channel outcomes. If delivery fails, surface undelivered; do not call the checkpoint “pending reviewer” as though the person has it.

Rejection is a successful control decision

Systems often treat rejection as an exception to retry. That is dangerous. A valid rejection closes the exact proposal terminally. Record who rejected, what was shown, the proposal hash, time, and any structured reason. The run may stop or form a materially different proposal from new evidence, but it cannot resubmit the same effect until fatigue produces approval.

Distinguish rejection from a request for revision. “Reject: inventory consequence unacceptable” is terminal for that proposal. “New proposal required: choose a later slot” is input to proposal construction, not approval of the later slot. The new object gets a new hash and whatever checks its policy requires.

Operational takeover runbook

Use this runbook when a reviewer selects takeover or an incident commander invokes it:

1. Authenticate the operator and verify takeover authority for the run and affected resources.
2. Compare the expected run revision and current owner lease.
3. Write one atomic transfer that revokes the agent lease and assigns the operator lease.
4. Mark outstanding approval responses and queued agent callbacks non-authoritative for execution.
5. Stop new agent planning and capability invocation.
6. Present current proposal, checkpoint, evidence versions, committed effects, ambiguous attempts, budgets, timers, and unresolved questions.
7. Require the operator to acknowledge control or fail the transfer closed.
8. Reconcile late events against the new ownership revision.
9. Record any operator action under the operator’s own authority and audit identity.
10. Define how, or whether, ownership can later return to an automated path.

A takeover that only changes an assignedTo display field is insufficient. Workers need an enforcement check at every mutation boundary. Queued jobs need the expected owner revision. Capability calls need a live lease or token bound to that owner state. Late approval must not revive the displaced agent path.

Cancellation is narrower. It marks the run so no new work or effect begins, revokes pending approvals, and lets reconciliation complete. It cannot erase a committed reservation. If policy permits release, that is a new compensating effect with its own authority, evidence, and receipt.

Failure walkthrough: the seven required traces

Run each trace from the same frozen FieldOps fixture so the expected result is unambiguous.

Availability changed. Reviewer approves part A17 and slot B2. Before resume, stock or slot revision changes. Expected: validation fails, old response stays historical, and a new proposal plus approval is required.

Expired token. Approval is timely, but the execution credential expires before resume. Expected: deny effect and reacquire authority only through the permitted credential path. Approval does not extend the token.

Unauthorized reviewer. A helpful site manager receives a forwarded link and approves. Expected: record the attempt, deny the disposition, keep the checkpoint open or reroute, and reveal no extra evidence.

No response. Primary and fallback remain silent through SLA and expiry. Expected: expire and escalate or cancel according to policy. No reservation occurs.

Incompatible deployment. A new release changes checkpoint or effect semantics while the run waits. Expected: migrate through a tested adapter when meaning is preserved, otherwise stop. Never resume merely because JSON parses.

Rejection. The coordinator rejects the exact proposal. Expected: terminal REJECTED; the same hash cannot re-enter approval as a retry.

Takeover. The coordinator accepts operational ownership. Expected: transfer one owner, revoke the agent effect path, deliver current state, and ignore late callbacks that carry the old revision.

These traces test control semantics, not human perfection. A mistaken but authorized approval remains possible. That residual risk informs consequence limits, evidence quality, dual control where a domain requires it, and staged deployment. The technical system should never claim that adding a reviewer proves safety.

The checkpoint clock

Issue time says when evidence was assembled. SLA says when routing or escalation should occur. Expiry says when the decision stops being usable. They are not interchangeable. A five-minute response target can coexist with a fifteen-minute approval validity period, while inventory still needs revalidation immediately before use.

No response follows a declared fallback: escalate to a named alternate, transfer the run, cancel with no new effect, or stop unresolved. It never means consent. After rejection, the exact proposal is terminal. A materially new proposal may begin new work, but the system cannot disguise repeated presentation of the rejected action as a retry.

Takeover requires atomic ownership transfer. The agent loses the effect path, queued callbacks become non-authoritative, and the operator receives the current checkpoint, evidence, outstanding ambiguity, and cancellation state. A human may intervene without full takeover, but then the record names the bounded correction and the owner who remains accountable.

Skill procedure

Classify the checkpoint. State the exact decision and authority basis. Bind a proposal hash. Assemble minimal validated evidence with drill-down. Name primary and fallback reviewers. Define response options, SLA, expiry, cancellation, and no-response behavior. Persist WAITING_HUMAN. Record disposition. On resume, reacquire one owner and revalidate proposal, authority, state, deployment, and budgets. Execute only if every guard passes; otherwise regenerate, escalate, transfer, or stop.

Run seven fault traces: changed availability, expired token, unauthorized reviewer, no response, incompatible deployment, explicit rejection, and takeover. The checkpoint passes only if none can cause an effect under stale or absent authority.

Worked FieldOps checkpoint

FieldOps has assembled a proposal for one synthetic part and one technician slot. Inventory is available at 10:03, the technician credential is live, and the proposal requires approval by an inventory coordinator for tenant North. The system presents exact identifiers, timestamps, supporting manual edition, compatibility evidence, alternatives, uncertainty, effect consequence, and an expiry of 10:18. It asks one question: approve, reject, modify, escalate, or take over this proposal?

At 10:09 the coordinator approves the exact hash. The run resumes at 10:11. It does not reserve immediately. A fresh worker acquires the lease, verifies the respondent’s principal and North-tenant delegation, confirms the approval is unused and unexpired, and rereads inventory and technician availability. If both remain current, the capability invocation can proceed under the earlier effect contract.

If another run took the slot at 10:10, the proposal changed. The approval is preserved as a historical decision, but FieldOps creates a new proposal rather than substituting a different slot. If the coordinator’s delegation expired at 10:10, resume denies despite the timely click. If deployment changed checkpoint semantics, resume migrates through an explicit adapter or stops. None of these results accuses the reviewer; the system enforces the contract.

Suppose the coordinator rejects the proposal. The run records REJECTED and cannot present the same action repeatedly. It may return to the user with alternatives or stop. Suppose instead the coordinator chooses takeover. Ownership transfers, agent effect capability is revoked for this run, late callbacks are ignored, and the coordinator receives open ambiguity and current evidence. The operator may decide differently under their authority, but the agent cannot claim that outcome as its own execution.

Design the evidence surface

The main card should answer five questions without scrolling: what exact effect is proposed, why now, what evidence supports it, what could go wrong, and what choices are available? Timestamps and source status belong near the facts they qualify. Uncertainty must identify the uncertain proposition, not display an unexplained percentage.

Drill-down should preserve provenance and access boundaries. A reviewer can inspect the permitted manual excerpt and inventory record without receiving unrelated tenant data. Sensitive elicitation cannot become an informal path for secrets or credentials. The audit record stores the evidence references and decision, not hidden reasoning or unnecessary raw content.

Checkpoint anti-patterns

Generic approval: “continue?” does not bind effect, parameters, or consequence.

Authority by interface: receiving the button does not prove the recipient may decide.

Approval as freshness: a response does not freeze inventory, credentials, policy, or budget.

No-response consent: silence is absence of a decision. Apply the declared fallback.

Endless nagging: repeated prompts can become coercive or bypass rejection. Terminate the proposal.

Human as safety wrapper: reviewer error and unavailability remain possible. Technical checkpoints are one control, not a safety proof.

Takeover without revocation: two active owners can race. Transfer ownership and invalidate the displaced path atomically.

The useful checkpoint is neither maximal friction nor a decorative confirmation. It makes a specific decision possible for a specific authorized person at a time when the decision can still control the effect.

Practice: design, attack, and defend a checkpoint

Exercise 1: classify six pending runs

For each run, choose one primary checkpoint type and explain why the other types do not substitute for it.

1. A requester wrote “the west pump” and three equipment records match.
2. Two manual editions conflict about the compatible replacement part.
3. The requester must verify that FieldOps understood the requested service window.
4. One unit of shared inventory will become unavailable to other teams.
5. A supervisor observes the agent contacting an unapproved vendor and must stop that behavior.
6. An incident commander must assume control while two effect attempts remain ambiguous.

A defensible classification is information request, review, confirmation, approval, intervention, and takeover, respectively. The value is in the reasoning. For run 2, the specialist’s technical review may inform the proposal but cannot spend inventory. For run 5, a stop intervention can be enough; forcing full takeover adds delay and responsibility the supervisor may not need. For run 6, intervention alone leaves ownership ambiguous, so takeover is required.

Exercise 2: write a checkpoint contract

Choose run 4 and produce a complete contract containing checkpoint type, trigger, decision sentence, proposal hash, effect, evidence fields, uncertainty, consequence, alternatives, reviewer role, authority basis, issue time, SLA, expiry, permitted responses, no-response fallback, cancellation, compatibility versions, and audit fields.

Then mutate one field at a time:

• quantity changes from one to two;
• inventory observation becomes stale;
• reviewer delegation changes tenant;
• approval arrives after expiry;
• a deploy changes effect capability version;
• a takeover occurs before the approval response arrives.

For each mutation, state whether the old checkpoint remains open, becomes unusable, closes terminally, or requires a new proposal. The answer should follow named guards, not intuition.

Exercise 3: perform an evidence subtraction test

Start from the worked FieldOps evidence card. Remove one field and ask whether a reasonable reviewer could still understand the exact decision and material consequence. Removing decorative explanation may improve the card. Removing the proposal hash, quantity, inventory timestamp, unresolved competition, authority basis, or expiry creates a specific failure. Record that failure.

Next, add the entire model transcript. Measure how long it takes a peer to identify the inventory timestamp and unresolved reservation. This contrast teaches that evidence sufficiency and evidence volume are different variables. Do not use real sensitive content in the exercise.

Exercise 4: trace a race

Simulate this ordering:

10:00 checkpoint issued
10:04 reviewer opens evidence version 1
10:05 inventory changes
10:06 evidence view refreshes to version 2
10:07 reviewer submits approval for version 1
10:08 resume worker loads version 2

The response service may preserve the 10:07 decision, but resume must not treat it as authorization for version 2. Decide whether the UI blocks submission after detecting the refresh, records a superseded response, or both. Then test a network-delayed response that arrives after another reviewer rejects. Your state machine should produce one deterministic authoritative disposition and preserve the other attempt for audit.

Exercise 5: takeover tabletop

Assign one person as agent worker, one as reviewer, one as operator, and one as late callback. Give each a card with an owner revision. Initiate takeover, then let the old worker and callback attempt mutations. They must fail because their expected owner revision is stale. Ask the operator to identify committed effects, ambiguous attempts, open timers, and remaining budgets from the handoff package. If any are missing, the transfer is not operationally complete.

Assessment rubric

Score the final design out of 20:

• checkpoint type and decision separation: 4;
• named principal, scope, and authority basis: 5;
• minimal decision-useful evidence with provenance and uncertainty: 4;
• SLA, expiry, no-response policy, and resume revalidation: 4;
• atomic takeover and displaced-path revocation: 3.

Automatic failure applies if an effect executes before a required response, a generic approval authorizes a changed proposal, rejection is retried as a transient error, silence becomes consent, or chain-of-thought substitutes for evidence. A passing design can still document residual risks. In fact, it should: reviewer overload, inattention, mistake, coercion, and unavailable formal authority are not eliminated by technical correctness.

A final design review checklist

Before shipping, ask a reviewer who did not build the workflow to find the exact proposal, consequence, evidence age, uncertain proposition, authority basis, expiry, reject path, and takeover control. Inject all seven failure traces. Restart the service during interrupt, response, and resume. Deploy an incompatible checkpoint reader. Replay a response. Forward a link to an unauthorized principal. Let the queue expire with no response.

The release candidate passes only when these attempts fail closed without losing the audit story. The goal is not to maximize how often a human clicks approve. It is to preserve the meaning and control of a human decision across delay, failure, and change.

FieldOps drill

Resolve delayed approval after changed inventory, expired token, wrong reviewer, absent reviewer, incompatible deployment, explicit rejection, and operator takeover. Score type 4, authority 5, evidence 4, timing/revalidation 4, takeover 3. Automatic failure occurs if execution precedes response, approval is generic, rejection retries, or chain-of-thought substitutes for evidence.

AR-08 v1.0.0 hands Chapter 12 a complete executable system including human delay, authority, rejection, expiry, and takeover.