The short answer
A recovery receipt links a detected failure to the response taken, such as fencing, pausing, reassignment, replanning or terminal failure. It makes the recovery path inspectable instead of leaving operators to infer success from a restarted process or a later model response.
Start with the failure that triggered the response
The recovery receipt reference connects detection to the chosen response. Without that connection, a system may show a new worker running while losing the reason the original work stopped.
For an illustrative research task, distinguish a lost peer from an expired lease or a capability failure. The eventual output may look similar, but the permitted recovery and the evidence needed to resume can differ.
Follow the actions in the recovery loop
The runtime recovery semantics describe authenticated detection, fencing invalid work, preservation of predecessors, re-evaluation and bounded reassignment or replanning. Resumption follows readiness and authority checks.
A receipt should be read with that sequence in mind. Locate what was stopped, which evidence was retained and why a replacement became eligible. Missing evidence should remain visible rather than being summarized as a successful restart.
Separate a response from a completed objective
A valid pause can be the correct recovery response even when the mission remains incomplete. A terminal failure can also be an explicit, evidenced outcome rather than a silent loss.
In an operator report, name the response and the resulting work state separately. “Recovery ran” is too broad to tell whether the mission resumed, safely stopped or exhausted its configured budget. Avoid counting every retry as an independently successful recovery.
Retain the context needed for comparison
To compare recovery behavior across runs, record the injected fault, source version, configuration and relevant work identities. The evaluation methodology calls for registering those conditions before measurement.
A shorter recovery duration under a different fault profile is not automatically an improvement. Preserve the raw receipts alongside the interpretation so another reviewer can see whether the same boundary and acceptance criteria were tested.
Use receipts in a focused incident review
- Identify the original failure signal and affected work.
- Locate the recorded fence, pause or other response.
- Inspect predecessor and eligibility evidence.
- Find the resulting resumed, replaced or terminal state.
- Compare that outcome with the scenario's declared acceptance criteria.
The replay guidance supports reconstructing this path without repeating its external effects. A good recovery explanation identifies what the system knew and did, including the point where it could not safely continue.
Sources and further reading
Documentation reviewed . Consult the linked documentation for current implementation details.