フォールバックは見えるべきだ。
フォールバックは経路と証拠を変えるため、信頼できるプロダクトはその変更を明示する。
- 公開
- 更新
トピック
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.
ここでは検証可能なエンジニアリングの範囲と考察を公開しています。共有できる状態になった段階でプロジェクトの証拠を追加します。
すべてのエンジニアリングノートを見る