Compensating Transaction¶
When atomic rollback is impossible, apply compensating actions that restore an acceptable state after partial completion.
The Diagnostic Story¶
Symptom: A multi-step process partially completes, fails, and leaves accounts, records, inventory, obligations, or expectations out of balance. The team says it was rolled back, but customers, counterparties, or downstream systems still experience effects. Refunds, credits, manual fixes, and apologies are improvised with no consistent rule. Compensation is applied twice, not at all, or in the wrong order because ownership and triggers are unclear.
Pivot: Define compensation steps, triggering conditions, ownership, reconciliation targets, an audit trail, and verification criteria — making governed counteraction the explicit response for cases where exact rollback cannot repair partial or irreversible effects.
Resolution: Recovery from partial failure becomes more predictable because compensation triggers and owners are defined before failure occurs rather than improvised during it. Affected parties receive appropriate notice and correction. The original failure and compensation path are documented and verifiable, and recurring compensation events reveal where stronger design is needed.
Reach for this when you hear…¶
[e-commerce operations] “The payment went through but fulfillment failed three steps later — we need a defined refund path, not a ticket to customer support each time.”
[distributed systems] “We cannot roll back the external API call, so we need a compensating action that puts the system into an acceptable state instead of pretending we can undo it.”
[legal transactions] “The contract was partially executed when the deal fell through — we need a clear rescission process that actually makes both parties whole, not just a signature on a cancellation form.”
When This Archetype Applies¶
No catalog groundingNone of the structural conditions is currently represented by an accepted prime or domain-specific abstraction.
Diagnostic problem
A multi-step or grouped process can partially complete in ways that cannot be exactly reversed, leaving the system, parties, records, or obligations in an unacceptable intermediate state.
What this problem means
The structural problem is irreversible partial completion. A process crosses a boundary before the whole process succeeds. Once that boundary is crossed, a simple abort cannot remove all effects. Someone may have relied on the action, a record may need to remain traceable, a legal duty may have arisen, or a human experience may already have occurred.
This creates a residue: the system is neither simply successful nor cleanly failed. Without a compensating structure, that residue becomes manual cleanup, hidden support debt, dispute, unfairness, data inconsistency, or unresolved harm.
Show the applicability expression
Applicability expression5 distinct conditions
groundedpartly groundedopen
5 conditions, all required.
5Required in every casenumbered 1–5
These hold no matter which pattern applies.
Irreversible committed effects · open
A process has committed side effects, consumed resources, disclosures, legal consequences, or human impacts that cannot be erased.
The source archetype describes the situation as follows: A process has local commits, external side effects, consumed resources, disclosed information, legal consequences, or human impacts that cannot be erased. The normalized requirement above isolates the load-bearing portion used in this condition set.
Decentralized reversal limits · open
The process crosses boundaries where no one actor can centrally reverse every effect.
The source archetype describes the situation as follows: The system crosses organizational, technical, legal, temporal, or physical boundaries where one actor cannot centrally roll back every effect. The normalized requirement above isolates the load-bearing portion used in this condition set.
Late failure after commitment · open
A later step can fail after an earlier step has become visible, binding, recorded, or relied upon.
The source archetype describes the situation as follows: A later step can fail after an earlier step has already become visible, binding, recorded, or relied upon. The normalized requirement above isolates the load-bearing portion used in this condition set.
Snapshot restoration inadequate · open
Restoring a saved state would lose legitimate subsequent work, violate obligations, or fail to repair the affected party.
The source archetype describes the situation as follows: A saved-state rollback would lose legitimate subsequent work, violate obligations, or fail to repair the affected party. The normalized requirement above isolates the load-bearing portion used in this condition set.
Durable obligations require compensation · open
Partial completion creates durable external obligations that require a semantically compensating action because exact rollback is impossible.
This condition preserves a load-bearing part of the diagnostic problem that was not captured by a source-condition atom. It remains explicit because omitting it would weaken the sufficient condition set.
Other requirements and context (1)
Why these sit outside the expression
Goal — a goal states an intended outcome or evaluation criterion, not a pre-existing situation that independently summons the archetype.
GoalOperational reality requires repair, cure, credit, reversal, reconciliation, or remediation rather than pure abort.
Use Compensating Transaction when the repair must be a counteraction, cure, offset, or reconciliation rather than an exact rewind. In this archetype, the relevant goal is: Operational reality requires repair, cure, credit, reversal, reconciliation, or remediation rather than pure abort. It supplies a criterion for evaluating what the intervention should accomplish or preserve.
Coverage
0 of 5 conditions grounded · 5 open.
Mechanisms / Implementations¶
- Saga Pattern (
saga_pattern):: This workflow protocol implements the archetype when it implements long-running distributed work as a chain of local actions with defined compensating actions when later steps fail. - Financial Reversal or Credit (
financial_reversal_or_credit):: This procedure implements the archetype when it uses refund, credit, chargeback, reversal, adjustment, or balancing entry to offset a completed financial effect that cannot simply vanish. - Contract Cure Provision (
contract_cure_provision):: This legal clause implements the archetype when it defines how a party can repair a breach or incomplete performance through notice, correction, replacement, payment, or other cure. - Service Recovery Playbook (
service_recovery_playbook):: This procedure implements the archetype when it guides apology, escalation, replacement, refund, credit, repair, and follow-up after a service failure has already affected someone. - Remediation Plan (
remediation_plan):: This plan implements the archetype when it specifies corrective work, owners, deadlines, evidence, and acceptance criteria for restoring acceptable condition after harm or noncompliance. - Corrective Action Request (
corrective_action_request):: This document implements the archetype when it creates a formal request to correct a defect, nonconformance, incident, or partial failure and to verify that the cure is complete. - Operational Reconciliation Workflow (
operational_reconciliation_workflow):: This workflow implements the archetype when it compares expected and actual states after partial completion, then applies adjustments until records, obligations, inventory, or accounts balance acceptably. - Clinical Correction Protocol (
clinical_correction_protocol):: This protocol implements the archetype when it coordinates disclosure, corrective care, monitoring, record amendment, and follow-up when a clinical action cannot be undone exactly. - Customer Make-Whole Credit (
customer_make_whole_credit):: This policy implements the archetype when it offers replacement, account credit, restitution, or extra service to restore customer acceptability after a failed or incomplete transaction. - Incident Corrective Action Register (
incident_corrective_action_register):: This artifact implements the archetype when it tracks compensating actions, residual risks, owners, due dates, evidence, and closure status across incidents.
- Clinical Correction Protocol: Coordinates disclosure, corrective care, and monitoring after a clinical action that cannot be undone — restoring safety where possible and making the residual harm explicit where it isn't.
- Contract Cure Provision: A contract clause that gives a breaching party a defined right and window to repair a breach — by correction, replacement, or payment — before the counterparty may escalate to termination or damages.
- Corrective Action Request: A formal request raised against a defect or nonconformance that drives it to root cause, demands a corrective action, and stays open until the cure is verified effective.
- Customer Make-Whole Credit: A standing policy that defines what to offer a customer — credit, replacement, extra service — to restore acceptability after a failed transaction, how much is enough, and where the ceiling sits.
- Financial Reversal or Credit: Offsets a completed financial effect that cannot simply vanish by posting an equal-and-opposite entry — a refund, credit, chargeback, or reversal — linked back to the original.
- Incident Corrective Action Register: A living register that tracks compensating actions across incidents — each with an owner, due date, evidence, and closure status — surfacing residual risk and recurring patterns that should feed prevention.
- Operational Reconciliation Workflow: Compares expected against actual after partial completion and applies adjustments until records, inventory, or accounts balance within tolerance — logging every correction it makes.
- Remediation Plan: A scoped plan that specifies the corrective work, owners, deadlines, and acceptance criteria for restoring an acceptable condition after harm or noncompliance — and the evidence that proves it was reached.
- Saga Pattern: Runs a long, multi-service process as a chain of local commits, each paired with a defined compensating action that fires in reverse order when a later step fails.
- Service Recovery Playbook: A frontline script for the moments after a service failure — acknowledge and apologize, empower someone to act, then run the ordered recovery of fix, compensate, and follow up.
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (3)
- Irreversibility: Cannot revert state.
- State and State Transition: Captures system condition and evolution.
- Transaction: All-or-nothing operations.
Also references 10 related abstractions
- Accountability: Responsibility for actions.
- Causality: Cause-effect relationships.
- Closure: Ensures operations remain within a set.
- Constraint: Limits possibilities to guide outcomes.
- Continuity: Smooth change without jumps.
- Data Integrity: Accuracy and consistency preserved.
- Fault Tolerance: Continue operating under failure.
- Observability: Infer internal state externally.
- Procedural Fairness (Due Process): Due process.
- Resilience: Absorb shocks and adapt.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Saga-Based Compensation · implementation variant · recognized
Coordinate a distributed multi-step process through local commits paired with compensating actions for later failure.
Contractual Cure Compensation · domain variant · recognized
Use notice, cure periods, replacement performance, payment, amendment, or waiver to repair a breached or incomplete obligation.
Service Recovery Compensation · domain variant · recognized
Restore customer, client, patient, or participant acceptability after a service failure through apology, correction, credit, replacement, or follow-up.
Operational Reconciliation Compensation · mechanism family variant · recognized
Compare expected and actual states after partial completion, then apply balancing or corrective entries until the process is acceptable.
Editorial Notes¶
Problem Classification¶
Classification: Correctness, Conformance & Formal Validity Failure → State Transition & Transaction Integrity
Problem kernel: partial irreversible completion leaves an invalid intermediate state
Rationale: A grouped process cannot atomically succeed or exactly undo, so failure can strand parties, records, and obligations between legal states.
Independent corroboration: The earliest necessary condition in the frozen evidence is: A multi-step or grouped process can partially complete in ways that cannot be exactly reversed, leaving the system, parties, records, or obligations in an unacceptable intermediate state. That is a state transition and transaction integrity problem because State changes admit illegal successors, broken invariants, partial completion, order effects, ambiguous absence, or inconsistent observations across concurrent participants.
Review outcome: Independent reviewer agreement; high confidence.