Jev timeout: dismiss the dialog on a late SAFE instead of making the user answer a gate that broke

Start by tracing the timeout failure path, the permission dialog lifecycle, and the in-flight judgment request. Review how timeout, real failures, user answers, and audit records are currently handled. Done means late SAFE, UNSAFE, and UNSURE outcomes follow the stated dialog behavior, user answers cancel the request, and the capped background wait is covered by tests.

The friction

When the judgment backend misses its deadline today, the gate treats it as UNAVAILABLE, fails closed, and prompts. Three problems with that:

1. The user eats the latency twice. They stare at nothing for timeoutMs, then get a dialog whose payload ("classifier unavailable") asks them to read and answer anyway.
2. The answer now exists but is thrown away. In practice the model finishes a beat later; we have no path to act on it.
3. It teaches users to distrust prompts. A prompt that says "the gate broke" trains the reflex to click through, which is the opposite of what every other part of this gate is building.

The idea: race the dialog, late-answer wins

Open the permission dialog immediately when the deadline fires, keep the judgment request alive in the background, and let a late verdict improve the dialog outcome:

• The dialog's reason says honestly: "judgment timed out after 8s; answering in the background — this dialog may resolve itself."
• If the late verdict arrives:
  • SAFE → dismiss the dialog and let the command run (the dialog never interrupted anything the user had already acted on — if they already clicked allow, nothing to do; if they were mid-read, the dismissal is a small win).
  • UNSAFE → the dialog is now backed by a real reason; swap the summary/danger line, keep it open. If the user already allowed because the gate failed, we log the race honestly (decision pair: unavailable → late UNSAFE) — we do not retroactively block what a human explicitly let through, but the audit line shows the late answer next to the human's, for calibration review.
  • UNSURE → leave the dialog as-is; attach the answer to the audit record.
• If the user answers first, cancel the in-flight judgment (abort the underlying signal) and proceed as today.

Why the safe-dismissal is sound

A late SAFE carries the same evidence weight (probabilities, hazards, blast radius) as an on-time SAFE — it is the same battery, just slow. The dialog was only opened because of a deadline we chose, not because the judgment said anything risky. Dismissing on late-SAFE is recovering the behavior the deadline had no right to take away. An allow the user gave while uninformed is the one case that needs care and is called out above.

Notes

• Applies only to the timeout failure mode. Real failures (HTTP error, invalid key, malformed body) still go straight to dialog with no background race, because retrying them has meaningfully lower EV and the error text matters.
• Needs a cap on how long past the deadline we keep listening (e.g. min(2×timeoutMs, 30s)), so the dialog can outlive the request when the provider is truly wedged.
• The late-answer mechanism is generic: it will also serve the case where the native LLM keyword fallback is slower than TypeSafe on the same battery.