Los fallbacks deben ser visibles.

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.

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.

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.

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.