Degradation must keep what the user already entered; starting over is the most common fallback failure

What it is

Failure jumps to a form or a human, and the box is empty. The three paragraphs of background just written, the two images, the four constraints, must be typed again. Losing input on degradation is the usual fallback failure: the retreat exists as a function and fines the user as labour. Keep the input, and degradation is continuation, not a new game.

Input is cost already paid by the user. Failure is the system’s. It should not be paid twice.

Why it happens

State for a generate request often lives only inside that one API call. On failure the client tears the call down and opens another route that has no contract to receive a draft. The “retreat” is, in information architecture, another application. What people feel is not degradation; it is an interrupt and a re-enrolment.

A labour fine changes strategy: people start writing less context so it will not be wasted, or they abandon after failure. The first lowers later success; the second punches through degradation’s completion rate. Form research already knows “fields cleared after a failed check” as a classic defect. Generate surfaces magnify it with much larger text blocks.

Studying it

Have people invest unmemorable material (a random order id, a specified tone), then fail and degrade. Measure: is the material still there, retype time, abandon rate. Independent variables: same-page switch versus full-page jump, whether attachments travel, whether the jump crosses a session. Dependent variables: completeness of assets, completion.

Cross-session is the stress test. Refresh, login expiry, jumping from generate to a ticket tool in another product line — those drop drafts most readily.

Where it stops holding

Sensitive input left on screen after failure may be non-compliant (shared device, shared screen). Keep it anyway, but lock it to the session and clear on timeout; do not “for safety, don’t pass it to the retreat.” Content the user explicitly deleted must not resurrect. If the retreat channel cannot take huge attachments, say which parts travel; do not drop them silently. This entry does not treat keeping partial model output. It treats what the person already handed the system.

Applying it

• The degradation route’s contract includes the draft: text, options, attachment refs. Jump with the same draft object, not only a URL.
• On same-page degradation the input region does not move; only the execution engine and the result well change.
• Failure copy should say “what you just submitted is still here,” and let people see it, not promise it in the background.
• Check: type a unique nonsense string and attach an image, force failure. Both must be on the retreat. After a refresh they must still be there (within your session policy). Missing either, this degradation is fining labour.

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.6 A deterministic fallback must be maintained in peacetime · L1.06.8 Timeouts and rate limits are expected failures and need different copy from model errors
• Nearby: L2.14 Carrying and clearing context · L3.12 Editing and taking over generated content · L4.05 Interruptibility and rollback
• Search terms: keep user input on fallback · draft preservation · degradation labour penalty