Skip to content

Compensating-Event Correction

Correction protocol — instantiates Event-Log-Centered Modeling

Corrects a mistaken event not by editing it but by appending a new reversing or adjusting event, so the erroneous record and its correction both remain in the history.

In an append-only world you cannot reach back and fix a wrong event — mutation is forbidden by construction. Compensating-Event Correction is the protocol for correcting anyway, honestly: to undo or amend a mistaken event, you append a new event that carries the reversing or adjusting change and points back at what it corrects. The original stays exactly where it was; the correction sits after it; the net state derived from the pair is right. Its defining move is that a correction is itself an event — history is amended by addition, never by erasure — so the record shows not a clean fiction but the truth: a mistake was made, and here is how and when it was put right. This is the accountant's reversing entry generalized: you don't rub out the error, you post an equal and opposite line beside it.

Example

A travel platform books a trip as a saga across three services: it appends FlightBooked, HotelReserved, then attempts CarReserved — which fails because the rental agency is sold out. The trip cannot stand half-booked, but the flight and hotel events are already in the log and cannot be edited away. So the platform issues compensating events: FlightBookingCancelled and HotelReservationReleased, each carrying the reversing transformation delta (release the seat, free the room) and a reference to the exact event it compensates.

Derived state now correctly shows no active trip — the bookings and their cancellations net to nothing. But the history tells the full story: booked at 14:02, released at 14:05 because the car failed. Weeks later, when finance reconciles a near-miss charge or support explains a transient hold on the customer's card, the answer is right there in the log. Contrast an edit-in-place system that would have simply deleted the two bookings: its current state would match, but it would have destroyed the evidence that anything happened at all. The compensating protocol keeps the system correctable without making it dishonest.

How it works

The protocol's distinctive discipline is correction-by-addition, done referentially:

  • Never mutate — append a reversal. The correction is a new event whose transformation delta undoes or adjusts the effect of the target event.
  • Point back at what it corrects. The compensating event references the specific prior event (by its identity/position), so the correction relationship is explicit, not inferred.
  • Choose reversal vs. adjustment. A full reversal negates the original; a partial adjustment amends it (correcting an amount, not voiding the whole transaction).
  • Let derived state net the pair. Projections fold original and compensator together to yield correct current state, while the history retains both.

Tuning parameters

  • Reversal vs. adjustment — whether a correction fully negates or partially amends. Full reversal is unambiguous but coarse; adjustment is precise but requires the delta math to be exactly right.
  • Compensation scope — correcting a single event versus cascading to every downstream event it caused. Narrow scope is simple but can leave dependent state stale; cascading is thorough but complex to orchestrate.
  • Reference strictness — how firmly the compensator is tied to its target. A hard reference makes the correction auditable and reversible; a loose one is easier to write but blurs what was corrected.
  • Timing tolerance — how long after the fact a compensation may be issued. Generous tolerance handles late-discovered errors; tight tolerance keeps the correctable window bounded and predictable.
  • Net-effect visibility — whether projections show only the corrected result or surface the original-plus-compensation pair. Showing only the net is cleaner for readers; surfacing the pair preserves the audit trail in views.

When it helps, and when it misleads

Its strength is that it reconciles two things that seem opposed — immutability and correctability. The log stays append-only and audit-honest, yet errors still get fixed, and the fix is itself a first-class, traceable fact. It is the event-log expression of the compensating-transaction idea used to unwind distributed work that cannot be rolled back atomically.[1]

It misleads when compensation is used to hide rather than correct. Because the original event survives, a poorly-designed system can leave stale downstream state that never got the compensator, so current views quietly disagree with the corrected history. Cascades are the hard part: reversing one event without reversing what it triggered produces a half-corrected mess. And the tempting misuse is to reach for a "silent fix" — deleting the bad event after all — which restores tidiness by destroying the very audit trail the archetype exists to protect. The discipline is to correct only by appended, referential compensators, to trace and reverse the full causal fan-out of an error, and to treat any in-place deletion of history as a violation, not a shortcut.

How it implements the components

Compensating-Event Correction realizes the correction side of the archetype — the components that let an immutable history still be put right:

  • correction_and_supersession_rule — it defines the rule that errors are superseded by appended reversing events, never by mutation.
  • transformation_delta — each compensator carries the explicit reversing or adjusting change that nets against the original.

It corrects by appending but does not keep the dual-clock record of belief that shows what was thought true before the fix — that as-of history is Bitemporal Event Register — and it does not deduplicate the replay of those corrections, which is Event Replay Deduplication.

Notes

Compensating correction and bitemporal recording are complementary, not redundant. The compensator fixes the forward history in the log (a reversing event nets the error to zero); the bitemporal register captures the belief dimension (what the system held true before the correction landed). A system that needs both a correctable log and faithful as-of-belief queries uses the two together — the compensator to amend, the register to remember what was believed before it did.

References

[1] A compensating transaction undoes the effect of a completed operation that cannot be rolled back atomically — the basis of the Saga pattern, where a long-running process is a sequence of local steps each paired with a compensating action to unwind it on failure. ↩