A retry re-attempts an action; it does not undo one. When a workflow fails terminally after some steps have already committed side effects to external systems, those writes still stand — and the only correct behavior is to reverse them in the order they were made. That is the Saga pattern, and in this plane it is engine behavior, not a runbook.
The partial-commit problem
DD02 ──▶ DD05 ──▶ DD08 ──▶ DD11
write write write ✕ fails terminally
committed side effects standSteps DD02, DD05, and DD08 have written to external systems. DD11 fails terminally. The workflow is now half-executed — the exact state that audit and downstream consumers cannot tolerate. Retry of DD11 does nothing about the three standing writes.
The compensation sequence
| Stage | Action |
|---|---|
| 1 | Terminal failure confirmed — budget exhausted, breaker tripped, or structural failure |
| 2 | Workflow halts immediately; no further steps dispatch |
| 3 | Completed steps iterate in reverse dependency order |
| 4 | Each compensatable step executes its declared compensation |
| 5 | State resets to the last valid checkpoint |
| 6 | The full sequence records to the Evidence Ledger as it happens |
Compensatable vs supersede
| Side-effect class | Compensation semantics |
|---|---|
| Compensatable | The step declares an inverse action; the engine executes it during rollback |
| Supersede | The side effect is a later version of an earlier state; rollback marks it superseded rather than removing it |
| Read-only | Nothing to undo; the step records as non-compensatable by construction |
The side-effect class is part of the step's declaration, not a runtime judgment. A step that cannot be compensated says so at authoring time, and the ledger records the class on every execution.
Why sagas, not retries
| Failure | Retry answers | Compensation answers |
|---|---|---|
| Transient tool outage | Yes — the state is unchanged | Not required |
| Schema deviation | No — deterministic; the retry fails identically | Yes — undo the committed prefix |
| Policy DENY | No — the call is disallowed | Yes — and the park explains why |
| Hallucinated output | No — the model will often repeat it | Yes — nothing valid stands |
Deterministic failures are the heart of the argument: a retry loop against a deterministic failure produces a storm, not a recovery. The engine bounds that loop with the budget hierarchy and finishes with compensation.
What the auditor sees
Every compensation is a ledger event carrying the step identifier, the compensation action, and its outcome — appended to the same checksum-chained trail as the original writes. The audit question "what stood after the failure" has a single answer source: the ledger, read in order, original events followed by compensation events in reverse. The event structures are specified in ledger and artifact formats.