The degradation order must be defined in advance

What it is

If the person on shift or the model itself “figures it out” at the moment of failure, the retreat is different every time. People cannot predict the next step and cannot rehearse it. A predefined degradation order writes the sequence into the product: generate → retrieval-augmented → rules/templates → manual → human. Which condition trips each step, and what is handed down, is fixed before release.

Order is a design object, not an incident response.

Why it happens

Improvised fallback fails in two modes. One is a cycle: generate fails, generate again, or retrieval fails and drops back into generate, and people are locked on one layer. The other is a skip: one miss throws them to a human or home, usable middle layers are jumped, and humans are flooded with noise. A ladder makes “who is next” a determinate state machine, so the evaluation loop knows what to wait for.

Predefinition also has a training value. Support and users can rehearse “at this layer I do this.” An unrehearsed retreat is felt, under pressure, as a new fault.

Studying it

Fault-inject the whole chain. Record whether layers actually visited match the document, and whether there are cycles or skips. Compare a documented ladder with “the model picks the retreat.” Dependent variables: time to recover, human-takeover rate, whether users can name the next step. Independent variables: depth of the ladder, whether in-layer retry is allowed, retry cap.

In-layer retries must be capped. An uncapped ladder degenerates in measurement to “always stuck on generate.”

Where it stops holding

A product with one retreat shrinks the ladder to a single step and this entry weighs less — the step still has to be written: failure → that layer. Long agent stacks can be long internally; users need not see every layer, but the system still needs order, and the outside only exposes two or three intelligible bands. Disaster recovery for a whole region may have a separate runbook; do not fuse it with in-product degradation into one machine. This entry does not argue that the retreat must be deterministic — that is the previous card — only that the order must not be invented on the spot.

Applying it

• Write a table: enter condition for each layer, max in-layer retries, timeout, exit. The table is on the release list and reviewed with the code.
• Ban “the model decides where to go next.” The next step is the state machine’s.
• Align outward copy with internal layers: people should hear the band they are standing on, not an internal tool name.
• Check: saturate each layer by the table and see whether arrival is the next layer written. A cycle or a skip means the table or the implementation is false. Then ask a colleague who has not seen the table what happens after failure — if they cannot say the order, the order still lives only in an engineer’s head.

Related

• Same group: L1.06.1 On failure, fall back to a deterministic path · 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: L4.13 Agent failure reporting and escalation · I2.13 Automatic retries · L4.05 Interruptibility and rollback
• Search terms: predefined degradation order · fallback ladder · degradation state machine