Recoverability
The ability of a system to move from partial or divergent execution states back to a coherent and usable outcome.
What it refers to
Recoverability refers to the ability of a system to return to a coherent, usable state when execution does not proceed as expected.
It does not mean that failures never occur. It does not mean that all outcomes succeed. It means that when something diverges from the intended path, the system can move forward in a controlled way.
Recoverability includes situations such as:
- An intermediate step completing while another remains pending
- Liquidity conditions changing during execution
- Timing differences causing partial progress
- A user needing to continue from a known state
Recoverability is about preserving clarity and forward movement when ideal flows break.
Why this concept exists
In simple systems, execution is often atomic. An action either succeeds or fails entirely.
In multi-network environments:
- Execution unfolds across systems
- Timing differs between environments
- Liquidity may change mid-process
- Partial completion is normal
Because execution is distributed and asynchronous, fully reverting to a clean starting state is not always possible or even desirable.
Without recoverability:
- Users experience stuck funds
- Systems accumulate inconsistent state
- Confidence erodes quickly
We need the concept of recoverability because partial progress and unexpected divergence are structural realities, not edge cases.
What this changes for system design
If divergence is normal, systems must be designed to manage it explicitly.
System design must:
- Represent intermediate states clearly
- Allow continuation from known states
- Preserve user intent even when execution paths shift
- Maintain coherence across environments
Recoverability shifts the goal from “never fail” to “fail in a controlled and understandable way.”
It treats resilience as a design property, not an afterthought.
