Four responsibilities
Design the handoff and the recovery together.
The normal path should be easy to state: what event happened, which record moves, what another system receives, and which outcome confirms success. The difficult work starts when one of those conditions is not true.
A useful operating model gives the person on recovery duty enough evidence to decide whether to retry, repair the record, route an exception, or stop the flow.
Contract: expected fields, states, and ownership.
Signal: the event, log, metric, or queue that makes failure visible.
Retry: a safe rule for repeated delivery and duplicate side effects.
Recovery: a named owner and an actionable exception path.
Pre-launch test
Test the failure path before it has a customer attached.
01
Specify the record
Write which fields and state transitions the receiving system may rely on.
02
Inject a bad case
Try a missing field, unexpected state, delayed event, and duplicate delivery.
03
Inspect the signal
Confirm the failure is visible where the recovery owner will actually see it.
04
Recover deliberately
Decide whether to retry, repair, route, or reject without creating a second side effect.
Bring the handoff that only gets attention once it breaks.
We can define the record, signal, retry rule, and recovery owner before the next failure becomes a manual investigation.
Bring the page, report, or workflow as it is now.
We reply with the clearest next step, or an honest no.
