Compensating Action Protocol¶
Workflow — instantiates Declared Effect Boundary Enforcement
Provides a known repair path when an unauthorized or irreversible effect has already occurred.
Compensating Action Protocol is the pre-designed repair path for effects that have already escaped — a message sent, a payment moved, a downstream record propagated — where a clean rollback is no longer possible. Its defining premise is that some effects cannot be undone, only counteracted: for each committed step you cannot reverse, you define a semantic repair that restores an acceptable state (a refund for a charge, a retraction for a notice, a reversal entry for a posting). And when no repair suffices, the protocol does not pretend otherwise — it escalates the effect out of the automated boundary to a human or incident channel that can handle it.
Example¶
A trip-booking service reserves a flight and then a hotel as one logical booking. On one request the flight is ticketed successfully, but the hotel reservation fails — and the airline ticket has already been issued, complete with a cancellation fee. A database rollback is useless here: the ticket exists in the airline's system, outside any transaction the booking service controls.
The Compensating Action Protocol takes over. Because ticketing was registered as a committed, non-reversible step, it carries a defined compensator: issue a cancellation and refund request against that exact ticket, then notify the traveler that the booking could not be completed. The compensation runs, idempotently, so a retry after a network blip does not double-cancel. If the refund itself fails — the fare class is non-refundable — the protocol stops guessing and routes the case to a support queue with the full context attached, rather than leaving a silent orphaned charge. The effect escaped; the protocol is what makes the escape recoverable.
How it works¶
- Per-step compensators. Every committed effect that cannot be rolled back is paired, in advance, with a defined action that counteracts it. No compensator, no permission to run the risky step.
- Reverse-order unwind. When a sequence partially completes, compensations execute in the reverse of commit order, so later effects are undone before the earlier ones they depended on.
- Idempotent repair. Compensators are safe to re-run, because failures happen mid-repair and the workflow must be able to resume without doubling the fix.
- Escalate the irreparable. When compensation is impossible or itself fails, the case is handed to a named human or incident channel rather than logged and abandoned.
Tuning parameters¶
- Reversibility classification — how each effect is sorted into rollback-able, compensable, or escalate-only. Finer classification catches irreversible effects early; coarse classification lets them slip past as "probably fine."
- Compensation completeness — how fully the repair restores the prior state (a refund returns money but not the traveler's lost afternoon). More complete compensation costs more to build and run.
- Escalation threshold — how quickly a stuck repair jumps to a human. Aggressive escalation is safe but noisy; conservative escalation risks silent orphaned effects.
- Retry policy — attempts and backoff before a compensator is declared failed and escalated.
When it helps, and when it misleads¶
Its strength is graceful recovery precisely where atomic rollback cannot reach: distributed steps, real-world actions, and cross-system commitments that a transaction can neither hold nor undo.[1]
Its central failure is the rollback illusion — designing as if an effect can be undone after it has already propagated, so no real compensator exists when the moment comes and the system is left with an orphaned charge or an unretractable notice. A related trap is treating a partial compensation as a full one: a refund closes the ledger but not the harm. The guarding discipline is to forbid high-consequence irreversible effects unless their repair path is defined first, and to classify reversibility up front rather than discovering it during the incident.
How it implements the components¶
rollback_or_compensation_path— supplies the compensation half of the archetype's repair path: defined, ordered, idempotent counter-actions for effects that escaped and cannot be cleanly rolled back.externality_escalation_channel— when repair is impossible or fails, it routes the case out of the automated boundary to a human or incident channel with full context.
It does NOT implement isolation_context or effect_observability_record — it repairs effects that already reached shared state rather than containing them beforehand or recording them; those are Sandbox or Staging Execution and Audit Log and Trace.
Related¶
- Instantiates: Declared Effect Boundary Enforcement — the repair-and-escalate machinery for effects that crossed the boundary before they could be stopped.
- Consumes: Audit Log and Trace supplies the record of exactly which effect escaped, so the right compensator can be aimed at it.
- Sibling mechanisms: Audit Log and Trace · Command–Query Separation · Effect Contract Annotation · Effect Review Checklist · Immutable Data or Copy-on-Write · Permission Scope or Capability Token · Sandbox or Staging Execution · State Diff Test · Transaction Boundary
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Provides a known repair path when an unauthorized or irreversible effect has already occurred, making its operative form a live operational control that automatically routes, enforces, adapts, or responds during execution.
Independent corroboration: The frozen evidence defines Compensating Action Protocol as 'Provides a known repair path when an unauthorized or irreversible effect has already occurred', so its operative form is Control, Automation & Runtime.
Nearest alternative: Protocol, Workflow & Routine — Predefined reverse-order, idempotent compensators execute as live recovery control when a partial workflow fails.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Distributed-database research cohered the Saga pattern, pairing irreversible local steps with compensating actions when atomic rollback is unavailable.
Review resolution: Both reviewers agree on computer_science as primary. Reading the source mechanism confirms that its defining operation belongs to that lineage; the final record retains no independently formative alternate lineage only where it materially formed the mechanism and keeps present-day application breadth separate from provenance.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Compensation and transactional rollback are complements, not rivals: a Transaction Boundary cleanly undoes reversible state inside its scope, and this protocol takes over exactly where that scope ends — the sent email, the moved money, the propagated record a rollback can never reach.
References¶
[1] The Saga pattern (Hector Garcia-Molina and Kenneth Salem, 1987) handles long-lived operations that cannot be held in one atomic transaction by pairing each committed step with a compensating action, run in reverse if the sequence fails. It is the canonical model for repairing effects that have already been made durable. withdrawn registry ↩