Falling back to a deterministic path presupposes that path is maintained, not that it exists only during an incident

What it is

The design doc says “on generate failure, return to the form.” If the form is only compiled into the page during an incident — nobody clicks it in peacetime, nobody tests it, the data model has already forked from the generate pipe — the day of the incident it is a dead road. A fallback must be maintained in peacetime: the deterministic path is part of the main product, not an emergency kit in a drawer.

“Has a fallback” is a runtime property, not an arrow on an architecture slide.

Why it happens

Once generate is the main path, traffic, tests, and design attention follow it. Fields, permissions, and copy on the retreat stop syncing with the main model and rot in the dark. Failure pushes people onto the retreat for the first time and exposes months of drift: missing fields, submit 500, missing permission, copy that still says coming soon.

People are worse at unfamiliar UI under pressure. A path that never shows in peacetime never grows skill. Spare instruments in aviation are powered on a schedule; software retreats need power-on too, or the spare itself is untested code.

Studying it

Look at real traffic on the retreat, date of last test, schema diff against the main path. Drill: on a working day turn generate off, and watch completion on the retreat, defect count, whether users can find the entry. Independent variables: whether the retreat is also reachable on the success path (a standing “skip smart, fill the form”), whether it is in every release’s regression. Dependent variables: drill completion, age of defects.

A retreat with long-run zero traffic should be treated as already rotten unless automated contract tests are running.

Where it stops holding

Paper or offline flows that regulation requires kept, even at zero traffic, still have to be maintained; cost them separately, do not delete them because “nobody uses this.” Prototypes may allow a crude retreat; once generate carries real tasks, crude becomes an incident. In multi-tenant setups some tenants never turned generate on — their “main path” is everyone else’s retreat, and the maintenance duty is heavier. This entry does not rank the ladder. It asks whether a layer already ranked will rot in a drawer.

Applying it

• Put a standing “don’t use smart, use the original form” on the success path so the retreat has daily traffic.
• Put the retreat in the same regression as the main path: schema, permission, submit. When the generate pipe changes a field, the same submit on the retreat must stay green.
• Turn generate off on a schedule and drill. A failed drill blocks release; it is not “bad luck that day.”
• Check: successful submits on the retreat in the last thirty days. If zero, look at contract tests. If both are missing, treat the retreat as absent and delete “on failure you can return to the form” from the product story. Then watch a drill recording and count how many people cannot find the entry.

Related

• Same group: L1.06.1 On failure, fall back to a deterministic path · 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.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: L4.09 Skill degradation · L4.05 Interruptibility and rollback · L1.02 Expressing capability boundaries
• Search terms: rotting fallback · peacetime maintenance · manual path regression