On failure, fall back to a deterministic path

What it is

Once the generative path cannot produce a usable result, people need a road that does not sample: rules, retrieval, a manual form, a human, last successful template. Deterministic fallback is not drawing again. It is leaving the probability channel.

Regenerate is another draw on the same road. Fallback is a different road. The two must not impersonate each other.

Why it happens

Generative failure leaves people in a clearing with no legal next step. The cheapest act in a clearing is to press the same button, so failure is fed to the same noise process again. A deterministic path’s value is cutting that loop: output no longer depends on temperature, and the evaluation loop can close.

Fallback can exist because the task usually had a way through before generation arrived. Those ways were covered by the generate surface, not destroyed. Failure lifts the cover, and people return to operations they already knew. If generate is the only door, failure is the feature vanishing.

Studying it

Plant a generate failure (empty, timeout, clearly unusable) and compare three aftermaths: regenerate only, a deterministic substitute, both. Dependent variables: task completion, path used to complete, time from failure to recovery, reports of “there is nothing I can do.” Independent variables: whether the substitute aims at the same goal, whether it demands the input be retyped.

Completion must be scored against the original goal. Doing something else is not recovery.

Where it stops holding

A pure generate task with no prior deterministic path (write a poem from nothing) can only degrade to “save the draft and leave”; it cannot pretend a rules engine will write the same poem. High-stakes tasks should default to the deterministic path and treat generate as a draft — on failure they should not even “fall,” because the person should not have been on generate. This entry only argues that failure must change onto a determinate channel. It does not rank the channels, and it does not treat silent failure.

Applying it

• For every generate entry, write its determinate retreat at design time: a manual editor, retrieval, a human, the previous version. An entry with no retreat must not be the only way to finish.
• On the failure panel the primary button is the retreat; regenerate is secondary. Do not make regenerate the only act.
• The retreat must catch the same goal, not dump people on the home screen.
• Check: turn the model off and walk the main task. People must still be able to finish. If they cannot, the feature does not exist at failure.

Related

• Same group: L1.06.2 The degradation order must be defined in advance · L1.06.3 Silent failure is more harmful than explicit failure · L1.06.4 Empty, wrong, and partial output need different fallbacks · L1.06.5 Fluent wrong output is the most dangerous; it trips no degradation · L1.06.6 A deterministic fallback must be maintained in peacetime · L1.06.7 Degradation must keep what the user already entered · L1.06.8 Timeouts and rate limits are expected failures and need different copy from model errors
• Nearby: L1.02 Expressing capability boundaries · L4.05 Interruptibility and rollback · L4.13 Agent failure reporting and escalation
• Search terms: deterministic fallback · graceful degradation · leave the sampling path