Fallbacks should be visible.
A fallback changes the path and the evidence, so reliable products make that change explicit.
- Published
- Updated
Topics
A fallback changes what happened
When a direct connection becomes a relay, a WebGPU run becomes a WASM run, or a physical trial becomes a replay, the system may still be useful. But the path has changed, so the evidence and the risks have changed with it.
Calling every path simply successful hides the very information that should guide the next decision.
The user should see the active path
A good interface distinguishes waiting, direct, relay, rescue, unavailable and expired states. It also explains when a result is a local computation, a cached artifact or a live exchange.
This is not unnecessary technical detail. It tells the user what was actually entrusted to the system and what will happen if the current path ends.
Stop instead of upgrading incomplete evidence
If a required source, hash, calibration, model or verification step is missing, the safe response is to stop or mark the result as incomplete. A graceful visual fallback should not become a silent evidence upgrade.
The product can still offer a useful next action: retry, inspect the missing input, switch to an explicitly labelled mode or record the run as not ready.
When a fallback runs, say what changed
The strongest fallback design is the one that remains understandable when a connection breaks, a model is unavailable or a physical assumption fails. The system does not need to pretend that nothing happened.
It needs to preserve the boundary, tell the truth about the current state and make recovery or abandonment a deliberate choice.
Each page states what the project covers, what evidence is public and what has not yet been verified.
Browse all engineering notes