Turn every tool call into a bounded, receipted effect.

# Tool-Using Workflow or Agent Scenario Pack

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-TWA-1.0`

Use this pack when an AI-assisted workflow can call a tool, wait for approval, resume later, or create an external effect. It turns each proposed action into an inspectable contract, permission decision, approval, durable state transition, and effect receipt.

The pack does not grant tool access, authorize an action, make a retry safe, or prove an outcome by itself. Identity, authorization, approval, dispatch, reconciliation, and terminal ownership must be enforced by authoritative systems outside the model.

## Smallest Credible Starting Set

For one bounded, reversible action with a named owner, complete:

1. `tool-action-contract.md`
2. `permission-matrix.md`
3. `approval-record.md` when the contract requires approval
4. `workflow-state-model.md`
5. `effect-receipt.md`

Attach every runbook whose entry condition is plausible. Advisory and proposal-only workflows may omit dispatch fields, but they still record the explicit no-effect boundary. Add deeper toolkit modules when the workflow handles sensitive data, crosses a trust boundary, delegates authority, creates durable state, produces an irreversible effect, or raises consequence.

## Users, Owners, and Authority

| Role | Responsibility | Authority boundary |
| --- | --- | --- |
| Requester | States the intended outcome and supplies permitted input | May request work; cannot grant tool authority |
| Workflow owner | Owns purpose, state model, stop conditions, and terminal service outcome | May narrow or stop workflow admission under policy |
| Action owner | Owns one semantic action, its consequence, and its contract | Defines the action boundary; cannot authorize a principal |
| Tool owner | Owns the adapter, schema, dependency behavior, and compatibility | May suspend the tool path; cannot broaden business authority |
| Policy authority | Defines which principals may perform which actions and under what conditions | Issues or denies authoritative permission decisions |
| Approver | Reviews one canonical action and evidence snapshot | May choose only the recorded decisions within current delegated authority |
| Executor | Dispatches an authorized action through the controlled boundary | Cannot change material parameters, target, or effect identity |
| Reconciliation owner | Determines effect state from authoritative evidence | May classify the outcome; cannot invent a missing receipt |
| Compensation authority | Authorizes any corrective or offsetting effect | Compensation is a new action with its own contract and receipt |
| Output verifier | Validates returned data and the claimed postcondition | Accepts or rejects evidence; does not approve the original action |
| Terminal owner | Owns unresolved, failed, cancelled, partial, or completed work | Decides the permitted terminal disposition and follow-up |

One person may hold several roles when policy permits. Record each assignment, authority source, expiry, handoff, and separation-of-duties requirement.

## Required Inputs and Entry Criteria

- A bounded workflow purpose, initiating principal, represented principal if any, accountable owner, environment, and consequence class.
- A versioned semantic action with exact target, typed parameters, provenance, protected fields, preconditions, postcondition, explicit denies, and output contract.
- An authoritative permission decision that is no broader than the action and current at dispatch.
- A canonical action digest and an approval rule that names the reviewer authority, allowed decisions, binding fields, evidence snapshot, expiry, and invalidation conditions.
- A stable workflow, action, attempt, effect, and receipt identity scheme.
- Defined commit, acknowledgement, completion, partial-success, unknown-outcome, cancellation, retry, compensation, and reconciliation semantics.
- A durable state store with legal transitions, single-writer or lease behavior, checkpoints, safe resume rules, and terminal ownership.
- An audit path that can relate proposal, canonicalization, permission, approval, dispatch, dependency response, observed effect, reconciliation, compensation, and terminal disposition.

Do not dispatch when identity, target, parameter provenance, authority, approval binding, idempotency, commit semantics, reconciliation path, output validation, or terminal ownership is missing or indeterminate.

## Working Sequence

| Stage | Required record | Result |
| --- | --- | --- |
| Contract | Tool and Action Contract | Versioned semantic action, tool boundary, inputs, effect semantics, outputs, and failure behavior |
| Permit | Permission Matrix | Least-authority decision surface with explicit denies and current decision sources |
| Approve | Approval Record | One review decision bound to the exact action, evidence, authority, and expiry |
| Execute | Workflow State Model | Enforceable transitions, durable facts, retry and cancellation rules, and terminal owners |
| Prove | Effect Receipt | Attributable dispatch, acknowledgement, effect, reconciliation, output validation, and disposition |

## Completed Walkthrough

Use `examples/approved-ticket-creation-and-failed-job-restart.md` to inspect the five records completed for two separately approved effects. It demonstrates approval binding, idempotency, a lost response, reconciliation before retry, and terminal effect receipts.

## Enforcement Boundary

The model may propose an action and explain its reasoning. Controls outside the model canonicalize inputs, authenticate the principal, resolve protected fields, authorize the exact action, validate approval, derive or verify effect identity, dispatch, record durable state, constrain retries, validate outputs, and issue receipts.

A transport acknowledgement is not completion. A timeout is not failure. Cancellation after dispatch does not prove that no effect occurred. Compensation is a separately authorized effect, not deletion of history. When evidence cannot establish the outcome, the action remains `outcome-unknown`, receives a reconciliation owner, and blocks any repeat that could duplicate consequence.

## Runbook Selector

| Condition | Runbook |
| --- | --- |
| Input, target, principal, permission, or action scope fails validation or exceeds the contract | `runbooks/action-rejected-or-scope-escape.md` |
| The action changed after review, the approval expired, or reviewer authority cannot be proved | `runbooks/approval-invalidated-or-expired.md` |
| Dispatch may have produced an effect but the outcome is unknown, late, or duplicated | `runbooks/unknown-outcome-or-duplicate-effect.md` |
| Cancellation races with dispatch, work completes late, or a superseded task returns | `runbooks/cancellation-or-late-result.md` |
| The tool returns malformed, untrusted, incomplete, or postcondition-inconsistent output | `runbooks/output-validation-failure.md` |
| A completed or partial effect requires correction, compensation, or cross-system reconciliation | `runbooks/compensation-and-reconciliation.md` |

## Exit and Acceptance Criteria

Close one action only when:

- the executed action matches the accepted contract, canonical digest, permission decision, and any required approval;
- the effective principal, target, environment, material parameters, provenance, tool version, and policy version are recorded;
- effect identity, commit point, attempts, acknowledgement, dependency receipt, and observed postcondition are distinguishable;
- every output used downstream has passed its schema, provenance, trust, completeness, and postcondition checks;
- cancellation, late results, partial completion, and retries follow the state model;
- each effect is confirmed, compensated, rejected before dispatch, cancelled before dispatch, terminally failed with no effect, or explicitly owned as unresolved;
- reconciliation and compensation create their own evidence and never overwrite the original attempt;
- the Effect Receipt and audit record are retrievable under the appropriate access controls; and
- the terminal owner records the final disposition, residual risk, follow-up, and reopening conditions.

## Deeper Record Triggers

Attach applicable core toolkit modules when the workflow:

- uses protected, personal, confidential, regulated, or cross-tenant data;
- accepts untrusted context or tool-returned instructions;
- delegates work or can choose among several consequential actions;
- creates durable state, notifications, financial effects, access changes, jobs, or external commitments;
- requires long-running execution, takeover, concurrent workers, or human approval;
- lacks a stable effect receipt or authoritative status lookup;
- relies on a broad execution credential or crosses trust boundaries;
- cannot fully reverse an effect or has a high consequence ceiling; or
- changes action contracts, tool versions, policy, population, autonomy, or release compatibility.

Typical additions are the AI Fit and Risk Assessment Worksheet, Harness Control-Loop Diagram, Tool Permission Matrix, AI Threat Model, Evaluation Plan, AI Release Manifest, AI Operations Runbook, and Principal Design Review Checklist and Record.

## Material Change and Reopening Triggers

Reopen affected records when workflow purpose, principal, target, environment, parameter schema, provenance, protected fields, action or tool contract, permission rule, approval rule, evidence snapshot, effect identity, idempotency window, commit semantics, retry policy, cancellation behavior, compensation path, output contract, terminal owner, autonomy, or consequence changes. Also reopen when a late receipt, duplicate effect, unauthorized target, invalid output, failed compensation, unreconciled state, or audit gap contradicts the recorded disposition.

# Completed Walkthrough: Approved Ticket Creation and Failed-Job Restart

Toolkit schema: `PAISEH-TK-1.0`

Scenario pack: `PAISEH-SC-TWA-1.0`

Example status: synthetic, completed, and vendor-neutral

This walkthrough follows one operator-approved workflow with two distinct effects: creating a maintenance ticket and restarting one failed data-processing job. The records keep the approvals, idempotency keys, effects, reconciliation, and terminal ownership separate.

## Common Artifact Header

| Field | Completed record |
| --- | --- |
| Artifact ID | `TWA-EX-032`, completed scenario, `1.0` |
| Purpose | Create one ticket for failed job `job-8041`, then restart that exact job after separate approval |
| System and environment | Batch operations assistant; production control plane |
| Consequence | Durable ticket plus bounded restart of an already failed job; no data mutation beyond normal job processing |
| Owners and authority | Workflow owner: Data Operations; operator: Inez; ticket approver: Kai; restart approver: Noor; terminal owner: Inez |
| Evidence | `EV-40` through `EV-52`; effect receipts `ER-401`, `ER-402` |
| State | Completed; both effects reconciled |
| Reopening triggers | Target, action payload, approval, dependency state, retry classification, or observed effect changes |

## 1. Completed Tool and Action Contract

Two action types were registered:

| Action | Admission and output contract | Effect and retry semantics |
| --- | --- | --- |
| `ticket.create/1` | fixed project, bounded title and description, severity enum, source incident reference; returns stable ticket ID and created-at time | durable effect; same idempotency key may be reconciled, never blindly recreated |
| `job.restart_failed/2` | exact job ID, expected current state `failed`, failure receipt, restart reason; returns attempt ID and authoritative job state | state-changing effect; unknown outcome requires reconciliation before retry |

Both contracts required a normalized canonical envelope, external input validation, permission decision, bound unexpired approval, idempotency key, deadline, audit reference, and postcondition check. Cancellation before dispatch ended the action; cancellation after dispatch triggered reconciliation.

The assistant could propose either action but could not mint approval, widen the target, interpret an unknown outcome as failure, or declare workflow completion.

## 2. Completed Permission Matrix

| Action | Effective capability | Approval | Explicit denial |
| --- | --- | --- | --- |
| Read failure receipt for `job-8041` | one-job read using workflow identity | not required | other jobs, payload data, configuration |
| Create maintenance ticket | create in `OPS-MAINT`; no edit, close, or attachment capability | exact payload approval by Kai | other projects, bulk create, user assignment |
| Restart failed job | restart only when authoritative state is `failed`; maximum one admitted restart | exact target and reason approval by Noor | running, completed, cancelled, or different jobs |

Pre-dispatch checks `EV-41` and `EV-42` confirmed least-authority grants, exact target, accepted consequence, and no delegation. No exception or scope expansion was requested.

## 3. Completed Bound Action Approval Records

### Approval `APR-401`: ticket creation

- Canonical action hash: `act:ticket:create:7d31`.
- Reviewed payload: project `OPS-MAINT`; title “Investigate transform failure for job-8041”; redacted failure class; incident reference `INC-8041`.
- Allowed decision: create exactly one ticket before 14:30 UTC.
- Approver: Kai, recorded ticket-triage authority.
- Invalidation: any title, project, incident, failure class, target, or expiry change.
- Consumption: atomically consumed by dispatch `DSP-401`.

### Approval `APR-402`: failed-job restart

- Canonical action hash: `act:job:restart:0b92`.
- Reviewed target: `job-8041`, expected state `failed`, failure receipt `FAIL-8041-3`, reason “operator-approved retry after transient dependency recovery.”
- Allowed decision: one restart before 14:35 UTC; no parameter or code change.
- Approver: Noor, recorded production restart authority.
- Invalidation: target state changes, failure receipt is superseded, dependency health regresses, or expiry arrives.
- Consumption: atomically consumed by dispatch `DSP-402` after a fresh failed-state check.

Neither approval authorized the other action.

## 4. Completed Workflow State Model

Authoritative workflow `WF-8041-7` used these transitions:

| From | Guard | To | Receipt |
| --- | --- | --- | --- |
| `proposed` | contracts and permissions valid | `awaiting_ticket_approval` | `EV-40`, `EV-41` |
| `awaiting_ticket_approval` | `APR-401` valid and bound | `ticket_dispatching` | `EV-43` |
| `ticket_dispatching` | effect confirmed | `awaiting_restart_approval` | `ER-401` |
| `awaiting_restart_approval` | `APR-402` valid; job still failed; dependency healthy | `restart_dispatching` | `EV-46` |
| `restart_dispatching` | dispatch response lost | `restart_outcome_unknown` | `EV-47` |
| `restart_outcome_unknown` | authoritative job lookup finds attempt `attempt-8041-4` running | `restart_confirmed` | `EV-48` |
| `restart_confirmed` | ticket link and job postconditions verified | `completed` | `ER-402`, `EV-51` |

The workflow made no second restart attempt while the outcome was unknown. A 15-minute terminal-owner timer routed unresolved state to Inez.

## 5. Completed Tool Effect Receipts

### `ER-401`: ticket

Dispatch `DSP-401` used idempotency key `idem:wf-8041-7:ticket`. The tool returned ticket `OPS-MAINT-218`, which the workflow retrieved independently and verified against project, title hash, and incident reference. Outcome: `confirmed`. No retry or compensation was needed.

### `ER-402`: restart

Dispatch `DSP-402` used idempotency key `idem:wf-8041-7:restart`. The client connection ended before a terminal response, so the workflow recorded `unknown` and blocked retry. Reconciliation queried the authoritative job history and found one new attempt, `attempt-8041-4`, created with the same workflow correlation reference. The job reached `running`, then `completed`, with no duplicate attempt. Outcome: `confirmed after reconciliation`.

| Postcondition | Evidence | Result |
| --- | --- | --- |
| Exactly one ticket exists | `EV-44`, ticket lookup | Pass |
| Ticket references the failed job and incident | `EV-45` | Pass |
| Exactly one restart attempt exists | `EV-48`, job history | Pass |
| Restart target was the approved failed job | `EV-46`, `EV-48` | Pass |
| Job reached an accepted terminal state | `EV-50` | Pass |
| Audit joins approvals, dispatches, effects, and workflow terminal state | `EV-52` | Pass |

Terminal disposition: `completed`, accepted by Inez in `WF-CLOSE-8041-7`. The assistant summary remained advisory; the receipts established the effects.

## Failure Path Demonstrated

The lost restart response activated the unknown-outcome and duplicate-effect runbook. Immediate action was to stop retry, preserve the dispatch record, and reconcile against authoritative job history. The workflow resumed only after it found the single effect and proved the target, correlation, and postcondition.

# Tool and Action Contract

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-TWA-1.0`

Complete `../../common-artifact-header.md` first. Define the semantic action independently of a provider endpoint. The execution boundary must enforce this contract; model instructions are not enforcement.

## 1. Action Identity and Ownership

- Workflow identity and version:
- Semantic action ID and version:
- Tool contract ID and version:
- Action owner:
- Tool owner:
- Workflow owner and terminal owner:
- Intended purpose and explicitly excluded purposes:
- Environment and tenancy boundary:
- Consequence and reversibility class:

## 2. Canonical Action Envelope

| Field | Type / meaning | Source and provenance | Model influence | Allowed values / constraints | Canonicalization | Protected / display rule |
| --- | --- | --- | --- | --- | --- | --- |
| initiating principal | | authoritative identity | none | | | protected |
| represented principal | | | none | | | protected |
| target | | | propose / select / none | | | |
| material parameter | | user / model / system / policy / tool | | | | |
| purpose | | | | | | |
| environment / tenant | | authoritative policy | none | | | protected |

- Canonical representation format and version:
- Material fields included in the action digest:
- Action digest algorithm and owner:
- Behavior when aliases, defaults, ignored fields, or conflicting values appear:
- Material-change rules that require a new action version, permission decision, or approval:

Reject the action when a protected value is model-supplied, a default widens scope, a material value is unresolved, or canonicalization changes the consequence beyond the admitted boundary.

## 3. Input Validation and Admission

| Input / relation | Validation rule | Authority or source of truth | Failure behavior | Evidence |
| --- | --- | --- | --- | --- |
| identity and represented principal | | | reject / escalate | |
| target and tenant | | | reject | |
| parameter type and bounds | | | reject / narrow | |
| cross-field invariant | | | reject | |
| current state / precondition | | | stop / refresh | |
| purpose and cumulative limit | | | reject / approval | |

- Validation location outside the model:
- Forbidden operations, fields, data classes, targets, and environments:
- Safe behavior when validation or current state is indeterminate:

## 4. Permission and Approval Consumption

- Authoritative policy decision identity, version, scope, and expiry:
- Required permission row:
- Approval trigger:
- Exact approval fields and evidence snapshot:
- Reviewer authority source:
- Allowed decisions:
- Approval expiry and freshness checks:
- Invalidation conditions:
- Pre-dispatch revalidation:

Tool availability and execution credentials do not establish permission. Dispatch only when the effective action is within the current decision and bound approval.

## 5. Dispatch and Effect Semantics

- Executing capability and least-authority credential:
- Dispatch boundary and responsible component:
- Effect identity / idempotency key owner:
- Derivation inputs, scope, retention window, and collision behavior:
- Commit point:
- Acknowledgement definition:
- Completion and expected postcondition:
- Partial-success states:
- Known-failure states that prove no effect:
- Unknown-outcome triggers:
- Authoritative status or reconciliation interface:
- Effect-aware retry rule:

Never repeat a dispatched-but-unconfirmed action until authoritative reconciliation proves the prior effect absent or the dependency safely deduplicates the same canonical action.

## 6. Cancellation and Compensation

- Cancellation before dispatch:
- Cancellation at or after the commit point:
- Late-result and supersession behavior:
- In-flight and queued-work treatment:
- Compensation action contract and authority:
- What compensation can and cannot reverse:
- Residual external or delayed effects:
- Reconciliation owner and deadline:

## 7. Tool Output Contract

| Output | Schema / type | Provenance and freshness | Trust / instruction treatment | Completeness marker | Validation | Downstream use |
| --- | --- | --- | --- | --- | --- | --- |
| | | | data only / authorized instruction | | | |

- Stable dependency operation or receipt identifier:
- Postcondition evidence:
- Missing, malformed, contradictory, partial, or untrusted output behavior:
- Protected-data and retention treatment:
- Validation owner:

Tool-returned text is data unless a separate authorized boundary promotes it. A plausible output does not prove the effect.

## 8. Audit and Compatibility

- Required proposal, canonicalization, authorization, approval, dispatch, acknowledgement, effect, reconciliation, compensation, validation, and terminal events:
- Correlation identities:
- Redaction, access, retention, and deletion rules:
- Compatible workflow, policy, adapter, and dependency versions:
- Breaking-change conditions:
- Monitoring and incident handoff:

## 9. Contract Acceptance

| Claim | Evidence | Owner | Status / finding |
| --- | --- | --- | --- |
| Inputs are validated outside the model | | | |
| Authority is least-privilege and current at dispatch | | | |
| Approval binds to the exact canonical action | | | |
| Effect identity and retry behavior prevent unsafe repeats | | | |
| Unknown outcomes have an authoritative reconciliation path | | | |
| Cancellation and compensation semantics are honest | | | |
| Outputs and postconditions are independently validated | | | |
| Every terminal outcome has an owner and receipt | | | |

# Tool-Using Workflow Permission Matrix

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-TWA-1.0`

Complete `../../common-artifact-header.md` and the Tool and Action Contract first. This record applies the Chapter 7 Tool Permission Matrix to one workflow. It records authority; it does not grant authority by itself.

## 1. Workflow Authority Boundary

- Workflow and version:
- Initiating-principal classes:
- Represented-principal rules:
- Allowed purpose:
- Policy authority and authoritative decision store:
- Executing identity / capability:
- Workflow owner:
- Safe behavior when identity, permission, or state is indeterminate:

## 2. Permission Matrix

| Action / contract | Principal and purpose | Allowed target / data scope | Parameter and cumulative limits | Explicit denies | Decision ID / version / expiry | Approval rule | Effect / retry rule | Terminal owner |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | | |

Keep each row narrower than the executing capability. Split actions when read, prepare, write, notify, execute, or compensate have different consequence or authority.

## 3. Least-Authority Capability Map

| Action | Required capability | Credential scope and lifetime | Protected fields | Broader capabilities technically available | External enforcement / evidence | Owner |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

- Credential acquisition and release:
- Tenant and environment binding:
- Quantity, rate, time, and cost ceilings:
- Emergency access authority, expiry, local checks, and audit:
- Conditions that revoke or quarantine the capability:

## 4. Pre-Dispatch Decision

| Check | Source of truth | Current evidence | Pass / deny / indeterminate | Failure behavior |
| --- | --- | --- | --- | --- |
| initiating and represented principal | | | | |
| purpose and target | | | | |
| parameter and cumulative limits | | | | |
| current resource state | | | | |
| permission version and expiry | | | | |
| required approval and binding | | | | |
| cancellation or supersession | | | | |
| prior effect / idempotency state | | | | |

Dispatch requires every material check to pass. An absent, stale, contradictory, or indeterminate decision blocks the action.

## 5. Delegation and Long-Running Authority

| Delegate / worker | Allowed action subset | Withheld authority | Data and resource scope | Budget / deadline / depth | Renewal rule | Revocation / takeover | Acceptance owner |
| --- | --- | --- | --- | --- | --- | --- | --- |
| | | | | | | | |

- Single-writer, lease, or fencing rule:
- Checkpoint and safe-resume boundary:
- Authority renewal cadence:
- Behavior when permission, approval, credential, or requester intent expires:

## 6. Exceptions and Findings

| Finding ID | Permission gap or excess | Evidence | Consequence | Owner | Required disposition / expiry | Status |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

This matrix produces evidence-indexed findings. It does not automatically approve an action or workflow.

# Bound Action Approval Record

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-TWA-1.0`

Complete `../../common-artifact-header.md` first. Use this record only when the action contract requires human or external approval. Approval covers the exact canonical action below; it is not a reusable instruction to “complete the task.”

## 1. Approval Identity

- Approval ID:
- Workflow, action, and action-version IDs:
- Tool contract ID and version:
- Requester:
- Initiating and represented principal:
- Action owner:
- Approver:
- Approver authority source, scope, version, and expiry:
- Decision time:
- Approval expiry:

## 2. Reviewed Canonical Action

| Field | Reviewed value / protected reference | Provenance | Material to digest? | Consequence |
| --- | --- | --- | --- | --- |
| semantic operation | | | yes | |
| target / tenant / environment | | | yes | |
| material parameter | | | yes | |
| purpose | | | yes | |
| effect identity | | | yes | |
| expected postcondition | | | yes | |

- Canonical action digest:
- Canonicalization version:
- Permission decision ID, version, scope, and expiry:
- Credential or capability class:
- Cumulative workflow effects and remaining limits:

## 3. Evidence and Consequence Preview

- Evidence snapshot ID and time:
- Current-state evidence:
- Expected effect:
- Affected resources, users, tenants, and downstream systems:
- Reversibility and commit point:
- Partial, delayed, and unknown-outcome possibilities:
- Cancellation and compensation limits:
- Material uncertainty and missing evidence:
- Alternatives, including no action:

## 4. Allowed Decision

Choose one:

- [ ] Approve this exact action once.
- [ ] Approve within the recorded quantity or time bound.
- [ ] Reject.
- [ ] Narrow or edit and require a new canonical action.
- [ ] Escalate to another authority.
- [ ] Request more evidence; no dispatch permitted.

- Decision:
- Conditions:
- Quantity, time, or attempt limit:
- Required supervision:
- Reason:

## 5. Binding, Freshness, and Invalidation

Approval is valid only while the action digest, principal, target, environment, permission decision, relevant evidence, consequence, and approver authority remain within the reviewed boundary.

Invalidate and re-review when:

- any material canonical field changes;
- a protected value, target resolution, default, or tool version changes the effect;
- permission, approver authority, evidence, or approval expires;
- the resource state or expected postcondition changes materially;
- cumulative limits, consequence, or affected population increase;
- the workflow is cancelled, superseded, delegated beyond the reviewed boundary, or resumed after its authority window; or
- a prior attempt is dispatched but its effect remains unknown.

## 6. Pre-Dispatch Consumption

| Check | Evidence | Result | Executor |
| --- | --- | --- | --- |
| action digest matches | | pass / deny | |
| permission remains current | | pass / deny | |
| approver authority covered the action | | pass / deny | |
| approval has not expired or been revoked | | pass / deny | |
| preconditions and evidence remain valid | | pass / deny | |
| no cancellation or supersession exists | | pass / deny | |
| prior effect state permits dispatch | | pass / deny | |

- Approval consumption event:
- Dispatch deadline:
- Receipt location:

No field may be silently edited during approval consumption. A mismatch creates a new proposal or rejection, not an implicit approval.

# Tool-Using Workflow State Model

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-TWA-1.0`

Complete `../../common-artifact-header.md` first. This record defines enforceable workflow and action states for durable, resumable execution. Chapter 6 remains authoritative for general harness design; this view records the action-specific states needed to keep external effects honest.

## 1. Workflow Identity and State Authority

- Workflow type and version:
- Workflow instance:
- Workflow owner:
- Authoritative state store:
- State writer / single-writer or fencing mechanism:
- Lease, heartbeat, and takeover rule:
- Checkpoint and safe-resume boundary:
- Cancellation and supersession source:
- Terminal owner:

## 2. Action Identity

- Action and action-version IDs:
- Attempt ID rules:
- Effect identity / idempotency key:
- Approval ID:
- Permission decision ID:
- Tool contract version:
- Receipt identity and location:

## 3. State Catalog

| State | Meaning / durable fact | Required entry evidence | Allowed next states | Owner | Deadline / expiry |
| --- | --- | --- | --- | --- | --- |
| proposed | candidate exists; no authority inferred | action proposal | canonicalized / rejected / cancelled | workflow | |
| canonicalized | material action is stable and digested | canonical envelope | authorized / rejected | action owner | |
| authorized | current policy permits this action | permission decision | approval-pending / dispatch-ready / rejected | policy boundary | |
| approval-pending | exact action awaits decision | approval packet | dispatch-ready / rejected / cancelled / expired | approver | |
| dispatch-ready | all gates pass now | authority and approval checks | dispatched / cancelled / expired | executor | |
| dispatched | request crossed the effect boundary | dispatch event | acknowledged / confirmed / partial / outcome-unknown / terminal-failed | executor | |
| acknowledged | dependency accepted work; completion unproved | acknowledgement | confirmed / partial / outcome-unknown / terminal-failed | executor | |
| outcome-unknown | effect cannot yet be established | ambiguity evidence | confirmed / partial / compensated / terminal-failed / owned-unresolved | reconciliation owner | |
| confirmed | expected postcondition is proved | effect and validation receipt | closed / compensation-pending | output verifier | |
| partial | only part of the effect is proved | partial-effect evidence | compensation-pending / confirmed / owned-unresolved | terminal owner | |
| cancellation-requested | stop requested; effect status unresolved | cancellation request | cancelled-before-dispatch / confirmed / partial / outcome-unknown | executor | |
| cancelled-before-dispatch | no dispatch occurred | authoritative ledger | closed | terminal owner | |
| compensation-pending | corrective action requires its own authority | compensation proposal | compensated / owned-unresolved | compensation authority | |
| compensated | corrective effect confirmed; original remains in history | compensation receipt | closed / owned-unresolved | output verifier | |
| rejected | action did not pass a gate | rejection receipt | closed / reproposed | relevant gate owner | |
| terminal-failed | known terminal failure with effect state proved | failure and no-effect or final-state evidence | closed / compensation-pending | terminal owner | |
| owned-unresolved | uncertainty is explicitly accepted and assigned | residual-risk decision | closed / reopened | terminal owner | |
| closed | final disposition recorded | effect receipt and owner decision | reopened | terminal owner | |

## 4. Transition Guards

| Transition | Required checks | Forbidden shortcut | Durable evidence |
| --- | --- | --- | --- |
| canonicalized → authorized | identity, target, parameter, purpose, state, policy | tool availability implies permission | |
| authorized → dispatch-ready | approval rule, binding, expiry, cancellation, prior effect | plan approval covers later values | |
| dispatch-ready → dispatched | same digest, active lease, effect identity, audit write | redispatch after lost local state | |
| dispatched → confirmed | dependency evidence plus postcondition validation | transport success equals completion | |
| dispatched → outcome-unknown | timeout, disconnect, contradictory or missing evidence | timeout equals failure | |
| outcome-unknown → redispatch | authoritative no-effect evidence or safe same-key deduplication | blind retry | |
| cancellation-requested → terminal | reconcile dispatch, commit, queues, late results | cancellation request equals cancellation | |
| partial / confirmed → compensated | separately authorized compensation and verified effect | overwrite original history | |

## 5. Effect-Aware Retry Table

| Prior effect knowledge | Retry disposition | Key behavior | Required authority | Evidence |
| --- | --- | --- | --- | --- |
| proved absent before dispatch | new attempt permitted | same semantic effect identity | current permission / approval | |
| dependency safely deduplicates exact action | same-key retry permitted | same canonical digest and key | current authority | |
| acknowledged but completion unresolved | reconcile first | no new effect identity | reconciliation authority | |
| partial effect | no blind retry | corrective or remaining action contract | new authority as required | |
| confirmed | repeat prohibited unless explicitly new intent | new action identity | new permission / approval | |
| unknown with no reliable status path | manual ownership only | frozen | terminal owner | |

## 6. Cancellation, Resume, and Concurrency

- Cancellation before dispatch:
- Cancellation after dispatch or commit:
- Late result after cancellation or supersession:
- In-flight and queued-work handling:
- Worker crash and safe resume:
- Concurrent attempt detection:
- Stale lease and takeover:
- Authority, approval, credential, and intent renewal:
- Dispatched-but-unconfirmed ledger reconciliation:

## 7. Terminal Ownership and Audit

| Terminal or unresolved state | Required owner | Decision / follow-up | Maximum unresolved window | Receipt |
| --- | --- | --- | --- | --- |
| rejected | | | | |
| cancelled | | | | |
| terminal failure | | | | |
| partial | | | | |
| outcome unknown | | | | |
| compensated with residual effect | | | | |
| confirmed | | | | |

Every terminal state must identify what happened, what remains unknown, who owns the consequence, and what evidence would reopen the workflow.

# Tool Effect Receipt

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-TWA-1.0`

Complete `../../common-artifact-header.md` first. Create one receipt for every material action, including rejection before dispatch and owned unknown outcomes. Free-form narration may accompany this record but cannot replace it.

## 1. Receipt and Correlation Identity

- Receipt ID and version:
- Workflow, execution, action, action-version, attempt, and effect IDs:
- Parent action or delegation chain:
- Correlation / trace reference:
- Initiating and represented principal:
- Workflow, action, and terminal owners:
- Tool contract and adapter versions:
- Environment and tenant:

## 2. Authorized Action

- Semantic operation:
- Canonical target:
- Material parameter digest and protected references:
- Purpose:
- Consequence / reversibility:
- Expected postcondition:
- Action digest:
- Permission decision ID, version, scope, and expiry:
- Approval ID, binding digest, decision, and expiry:
- Pre-dispatch validation evidence:

## 3. Dispatch and Effect Ledger

| Event | Time | Actor / component | Attempt / effect identity | Evidence / stable reference | State |
| --- | --- | --- | --- | --- | --- |
| proposal accepted | | | | | |
| dispatch attempted | | | | | |
| dependency acknowledged | | | | | |
| effect observed | | | | | |
| cancellation requested / observed | | | | | |
| reconciliation completed | | | | | |
| compensation dispatched / observed | | | | | |

- Commit point:
- Idempotency key, owner, scope, and retention window:
- Dependency operation or receipt ID:
- Attempts and retry dispositions:

## 4. Outcome Classification

Choose the most precise supported state:

- [ ] rejected before dispatch
- [ ] cancelled before dispatch
- [ ] confirmed
- [ ] partially completed
- [ ] outcome unknown
- [ ] terminally failed with no effect
- [ ] compensated
- [ ] owned unresolved

- Classification evidence:
- Known affected targets, users, records, jobs, or systems:
- Unknown or delayed effects:
- Duplicate-effect check:
- Reconciliation method, time, authority, and result:
- Compensation action and separate receipt:

Do not record `confirmed` from transport success alone. Use an authoritative receipt, status interface, observed postcondition, or another accepted effect proof.

## 5. Output and Postcondition Validation

| Claim or output | Schema / invariant | Evidence and provenance | Freshness / completeness | Result | Owner |
| --- | --- | --- | --- | --- | --- |
| dependency response | | | | pass / fail / indeterminate | |
| expected postcondition | | | | pass / fail / indeterminate | |
| downstream effect | | | | pass / fail / indeterminate | |

- Malformed, partial, contradictory, untrusted, or missing output:
- Protected-data handling:
- Downstream use permitted:
- Validation finding IDs:

## 6. Terminal Disposition

- Final workflow and action state:
- Terminal owner:
- Decision authority:
- Accepted use or follow-up:
- Residual risk and unresolved evidence:
- Next reconciliation deadline:
- User or affected-owner communication:
- Audit record location:
- Retention / deletion rule:
- Reopening triggers:

## 7. Receipt Integrity

- Receipt issuer:
- Issued time:
- Source event range:
- Integrity or signature reference:
- Redactions and access restrictions:
- Supersedes / superseded by:

# Runbook: Action Rejection or Scope Escape

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-TWA-1.0`

Complete `../../../common-artifact-header.md` first. Use this runbook when identity, input, target, permission, purpose, parameter, or current state fails validation, or when the proposed action exceeds its contract.

## Entry Conditions and Authority

- Workflow, action, version, principal, target, and attempt:
- Failed or indeterminate validation:
- Expected contract, permission row, and current evidence:
- Workflow owner, action owner, policy authority, and terminal owner:
- Authority to reject, narrow, quarantine, revoke capability, or request a new proposal:

The assistant may explain a finding. It cannot repair missing authority, substitute a broader target, or weaken a validator to make the action pass.

## Immediate Action

1. Prevent dispatch and mark the proposal `rejected` or `indeterminate`.
2. Preserve raw input, canonical form, provenance, protected fields, decision evidence, and validation output.
3. Quarantine the action or tool path when the failure may expose another tenant, environment, data class, or consequence.
4. Bound related proposals that share the same contract, policy decision, resolver, or validation defect.
5. Assign an owner to each potentially affected target or unresolved access.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Compare | Diff the proposed and canonical actions against contract and permission | Exact failed field or rule | Source-of-truth values conflict |
| Trace | Identify parameter provenance, defaults, alias resolution, and protected-field handling | Reconstructable canonicalization | A protected field was model-controlled |
| Bound | Determine affected principals, targets, tenants, attempts, and releases | Bounded population | Any action may already have dispatched |
| Correct | Narrow the proposal or repair the external validator, resolver, policy, or adapter | New versioned candidate and evidence | Correction changes purpose or consequence |
| Recheck | Re-run admission against current state and authority | Pass or explicit rejection | Evidence remains indeterminate |

## Verification and Stopping Conditions

Verify that the rejected action produced no dispatch event, the executing capability did not bypass the decision, protected fields remained protected, and a corrected candidate receives a new digest and any required permission or approval.

Stop and escalate when a cross-tenant, protected-data, destructive, or already-dispatched effect is possible, or when the system cannot prove that enforcement occurred outside the model.

## Reversal

- Revoke or narrow temporary credentials, grants, routes, or exceptions.
- Remove unsafe candidates from queues without erasing audit evidence.
- Reconcile any dispatch that may have crossed the boundary.
- Route any actual effect to the applicable cancellation, unknown-outcome, or compensation runbook.

## Evidence and Closure

Record the proposal, canonical form, failed rule, decision versions, denied dispatch, affected scope, corrective change, and revalidation.

Close when the action is safely rejected or a newly versioned candidate passes the unweakened boundary. Reopen on a related scope escape, late dispatch, validator bypass, or policy drift.

# Runbook: Approval Invalidated or Expired

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-TWA-1.0`

Complete `../../../common-artifact-header.md` first. Use this runbook when an action changes after review, approval or reviewer authority expires, binding evidence changes, or approval consumption cannot prove an exact match.

## Entry Conditions and Authority

- Approval, action, action-version, digest, and evidence snapshot:
- Changed field, expiry, revocation, or authority gap:
- Approver, approval authority source, executor, and workflow owner:
- Authority to invalidate, reject, request fresh evidence, or obtain a new review:
- Known dispatch or effect state:

## Immediate Action

1. Block dispatch and mark the approval invalid or expired.
2. Preserve the reviewed snapshot, current candidate, digests, permission decision, authority evidence, and consumption attempt.
3. Cancel queued work that depended on the approval when cancellation can still prevent dispatch.
4. If dispatch may have occurred, stop retries and reconcile effect state.
5. Notify the workflow and terminal owners of the blocked or ambiguous action.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Bind | Compare every material canonical field and digest | Exact match or material difference | Canonicalization version changed unexpectedly |
| Validate authority | Check approver role, scope, delegation, and expiry at decision time | Authoritative authority record | Authority cannot be reconstructed |
| Validate freshness | Check permission, resource state, evidence, and consequence | Current admissible snapshot | State or consequence increased |
| Reconcile | Determine whether any attempt crossed the dispatch boundary | No dispatch or known effect state | Outcome is unknown |
| Re-review | Create a new action version and approval packet | New independent decision | Reviewer would need broader authority |

## Verification and Stopping Conditions

Verify that no invalid approval can be consumed, old approval IDs cannot authorize a new digest, and any replacement approval uses current permission, evidence, consequence, and reviewer authority.

Stop and escalate when the stale approval may have authorized an external effect, the approver exceeded authority, evidence was concealed, or an irreversible consequence increased.

## Reversal

- Revoke stale approval tokens, temporary grants, and queued dispatch permissions.
- Restore any temporary execution route or exception.
- Reconcile effects from any dispatch that consumed the invalid approval.
- Use a separately authorized compensation path when an effect requires correction.

## Evidence and Closure

Record the original packet, decision, binding fields, invalidation reason, consumption attempts, cancellation, reconciliation, and replacement decision.

Close when the stale approval is unusable and the action is rejected, freshly approved, or assigned to an owner with a known unresolved effect. Reopen on a late dispatch, reused approval, or changed evidence.

# Runbook: Unknown Outcome or Duplicate Effect

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-TWA-1.0`

Complete `../../../common-artifact-header.md` first. Use this runbook when a timeout, disconnect, lost receipt, retry, concurrent worker, or late response leaves effect state unknown or suggests duplicate consequence.

## Entry Conditions and Authority

- Workflow, action, action-version, attempts, effect identity, and idempotency key:
- Dispatch, acknowledgement, timeout, retry, and dependency references:
- Possible targets and consequences:
- Reconciliation owner, tool owner, terminal owner, and incident route:
- Authority to pause admission, inspect status, cancel, correct, compensate, or notify:

The assistant cannot infer that a timeout means no effect or that matching prose means two attempts were equivalent.

## Immediate Action

1. Stop blind retries and new related effects.
2. Mark every dispatched-but-unconfirmed attempt `outcome-unknown`.
3. Preserve canonical digests, keys, request and dependency IDs, callbacks, ledgers, audit events, and target-state snapshots.
4. Pause or narrow the affected action class when duplicate consequence is material.
5. Assign explicit ownership and a reconciliation deadline to every unknown outcome.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Correlate | Join attempts by canonical digest, effect identity, dependency ID, target, and time | Complete attempt set | Keys were reused for different actions |
| Reconcile | Query an authoritative status or postcondition through a non-effecting path | Confirmed absent, partial, single, duplicate, or unknown effect | Observation needs broader authority |
| Bound | Identify users, targets, durable state, notifications, jobs, and downstream effects | Affected population | Irreversible or cross-tenant effect is possible |
| Contain | Disable repeat, fence stale workers, or hold related queues | Enforced pause | A late worker can still dispatch |
| Correct | Accept one effect, complete a partial effect, or invoke separately authorized compensation | New receipt and target-state evidence | No safe correction exists |

## Verification and Stopping Conditions

Verify every attempt, key, receipt, observed postcondition, late callback, queue entry, worker lease, and downstream effect. Confirm that future retries use the recorded effect-aware rule.

Stop and escalate when effect state cannot be authoritatively observed, duplication could cause protected-data or safety harm, or any unknown outcome lacks a terminal owner.

## Reversal

- Fence stale or concurrent executors.
- Cancel eligible queued or in-flight work without labeling cancellation as proof of no effect.
- Execute correction or compensation only under a new contract, authority, and receipt.
- Reconcile external observers and downstream systems that cannot be perfectly reversed.

## Evidence and Closure

Record attempts, action digests, keys, dependency evidence, observed states, duplicates, corrections, compensations, owners, and remaining uncertainty.

Close when every attempt is confirmed absent, confirmed once, classified partial, compensated, or accepted as explicitly owned residual risk. Reopen on a late receipt, delayed effect, or duplicate.

# Runbook: Cancellation Race or Late Result

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-TWA-1.0`

Complete `../../../common-artifact-header.md` first. Use this runbook when cancellation, supersession, lease expiry, or workflow closure races with dispatch, commit, background work, callback, or a late tool result.

## Entry Conditions and Authority

- Workflow, action, attempt, lease, cancellation, supersession, and effect identities:
- Cancellation request and observed state:
- Dispatch and commit-point evidence:
- Workflow owner, executor, reconciliation owner, and terminal owner:
- Authority to cancel, fence, discard, accept, compensate, or reopen:

## Immediate Action

1. Stop new workflow steps that depend on the cancelled or superseded action.
2. Fence stale workers and prevent new dispatches from obsolete state.
3. Preserve cancellation, queue, lease, dispatch, acknowledgement, callback, and target-state evidence.
4. Mark post-dispatch work indeterminate until reconciled.
5. Route any late result through validation; do not silently merge it into current state.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Order | Reconstruct proposal, lease, dispatch, commit, cancellation, callback, and supersession | Authoritative event order | Clocks or identities cannot be reconciled |
| Fence | Verify obsolete workers cannot write state or dispatch effects | Fencing or lease evidence | Multiple writers remain active |
| Reconcile | Determine whether the effect committed, completed, or remained absent | Known action state | Outcome remains unknown |
| Classify result | Validate provenance, version, target, completeness, and relevance | Accept, discard, or quarantine decision | Late output contains a new instruction or protected data |
| Correct | Reopen, supersede, or compensate through current authority | New state transition and receipt | Correction raises consequence |

## Verification and Stopping Conditions

Verify queue drainage, worker fencing, effect state, late callbacks, durable checkpoints, downstream consumers, and the current workflow's independence from stale output.

Stop and escalate when an obsolete worker can still create effects, cancellation state is being treated as effect proof, or a late result altered current state without a valid transition.

## Reversal

- Restore temporary queue, routing, or lease controls after the obsolete work is contained.
- Remove stale output from current decision inputs while preserving evidence.
- Compensate a late external effect only under separate authority.
- Notify affected owners when the effect cannot be fully reversed.

## Evidence and Closure

Record event ordering, cancellation and fencing receipts, result validation, effect reconciliation, corrective actions, and terminal ownership.

Close when obsolete execution cannot continue, every late effect or result has a disposition, and current workflow state is authoritative. Reopen on another callback, stale write, or delayed external effect.

# Runbook: Tool Output Validation Failure

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-TWA-1.0`

Complete `../../../common-artifact-header.md` first. Use this runbook when tool output is malformed, partial, stale, contradictory, untrusted, outside its schema, or inconsistent with the expected postcondition.

## Entry Conditions and Authority

- Workflow, action, attempt, effect, output, and schema identities:
- Failed schema, provenance, completeness, trust, or postcondition check:
- Known effect state:
- Tool owner, action owner, output verifier, and terminal owner:
- Authority to quarantine output, stop dependent steps, reconcile, correct, or compensate:

## Immediate Action

1. Prevent the output from driving another action or being presented as confirmed.
2. Mark affected claims and workflow transitions `indeterminate`.
3. Preserve the raw response under appropriate access controls, parsed form, validation errors, dependency receipt, and effect evidence.
4. Stop retries until effect state and retry safety are known.
5. Bound every downstream consumer that may have used the invalid output.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Validate | Re-run deterministic schema, provenance, freshness, completeness, and trust checks | Specific validation findings | Output contains protected or unsafe data |
| Separate | Distinguish response validity from effect completion | Independent effect state | Effect remains unknown |
| Trace | Identify adapter, schema, dependency, prompt, or parsing change | Versioned causal boundary | Multiple contracts are incompatible |
| Contain | Quarantine output and pause dependent transitions | Consumer inventory and enforced block | Invalid output already caused an effect |
| Correct | Repair adapter or request a safe read/status result within current authority | Validated replacement evidence | A repeat could duplicate effect |

## Verification and Stopping Conditions

Verify the output contract against representative valid, invalid, partial, stale, and adversarial results. Confirm that tool-returned text remains data and cannot issue new authority.

Stop and escalate when protected data was exposed, downstream effects occurred, effect state is unknown, or the authoritative output cannot be distinguished from generated interpretation.

## Reversal

- Remove invalid output from caches, queues, summaries, and decision packets without erasing audit history.
- Restore the last compatible adapter or schema under the release authority.
- Reconcile and, when separately authorized, correct any downstream effect.
- Notify affected owners when prior output cannot be withdrawn.

## Evidence and Closure

Record raw and parsed output references, validation findings, affected consumers, effect state, corrected contract or adapter, regression evidence, and owner decisions.

Close when valid output or an explicit unavailable state is recorded, downstream use is reconciled, and no action remains justified by invalid evidence. Reopen on recurrence or delayed consequence.

# Runbook: Compensation and Reconciliation

Toolkit schema: `PAISEH-TK-1.0`
Scenario pack: `PAISEH-SC-TWA-1.0`

Complete `../../../common-artifact-header.md` first. Use this runbook when a confirmed or partial effect must be corrected, offset, completed, or reconciled across systems. Compensation is a new action; it does not erase the original effect.

## Entry Conditions and Authority

- Original workflow, action, effect, receipt, and observed postcondition:
- Required correction, offset, completion, or reconciliation:
- Affected targets, users, systems, and delayed effects:
- Action owner, compensation authority, executor, output verifier, and terminal owner:
- Compensation action contract, permission, approval, effect identity, and limits:

## Immediate Action

1. Stop new dependent effects when the current state could compound harm.
2. Preserve the original action, authority, receipt, target state, and downstream evidence.
3. Bound what can be restored and what external observers or irreversible consequences remain.
4. Create a separate canonical compensation proposal; do not mutate the original receipt.
5. Assign ownership to gaps that compensation cannot resolve.

## Diagnosis and Response

| Step | Action | Expected evidence | Stop / escalate when |
| --- | --- | --- | --- |
| Establish state | Reconcile the original effect across authoritative systems | Confirmed current and desired states | State remains unknown |
| Design correction | Define semantic compensation, targets, limits, and postcondition | New action contract | No bounded correction exists |
| Authorize | Obtain current permission and any bound approval | Independent authority evidence | Original approval is being reused implicitly |
| Execute | Dispatch with a new effect identity and receipt | Compensation acknowledgement and effect evidence | Partial or unknown compensation occurs |
| Reconcile | Compare all affected systems and delayed consumers | Consistent final state and explicit residuals | Systems disagree or effects continue |

## Verification and Stopping Conditions

Verify the original and compensating receipts, target state, notifications, caches, jobs, access, financial or data consequences, downstream consumers, and delayed effects. Confirm that the correction did not exceed its authority.

Stop and escalate when compensation would widen affected scope, require destructive or privileged authority, conceal the original history, or create an unowned unknown outcome.

## Reversal

- A compensation reversal requires another independently authorized action.
- Revoke temporary grants, routes, or overrides used for correction.
- Restore paused admission only after reconciliation and verification.
- Preserve every original, compensation, and reversal receipt.

## Evidence and Closure

Record original state, compensation proposal, permission and approval, dispatch, effects, cross-system reconciliation, residual consequence, communications, and final owner decision.

Close when the desired state is verified or the terminal owner explicitly accepts the remaining consequence with scope, expiry, and follow-up. Reopen on disagreement, late effect, failed correction, or new affected scope.