Empty, wrong, and partial output are different failures and need different fallbacks

What it is

Empty, wrong, and half-built are not one accident. Empty is nothing. Wrong is a completed state that cannot be used. Partial is usable fragments plus a named hole. Typed degradation gives the three failures three roads: empty starts over or changes channel; wrong is isolated and a determinate substitute is offered; partial keeps what is done and only fills the hole.

A generic “something went wrong, try again” treats all three as empty. That is the usual type error.

Why it happens

The user’s assets differ in the three situations. Empty: the spend is the prompt, and retry costs another wait. Wrong: an object that looks complete already occupies the result slot; without isolation it mixes into later edits. Partial: generated rows and filled fields are sunk labour that can still be saved; throwing them away punishes partial success.

Detection signals differ too. Empty is timeout and empty packets; wrong is a check, a tool return, or a user mark; partial is whether the structure closed and whether required slots are vacant. One detector feeding one retreat will mismatch: treating partial as empty dumps assets; treating wrong as partial leaves poisoned data in the draft.

Studying it

Inject the three faults separately and compare unified retry with typed paths. Dependent variables: asset keep (are partial fields still there), isolation of poison (can a wrong completed state still one-click send), time to recover. Independent variables: whether the user can re-tag “wrong” as “partial” (sometimes only one figure in a sentence is fake).

The gold standard for typing is post-hoc labels, not the model’s self-report. Self-report will call wrong partial in order to look salvageable.

Where it stops holding

A stream aborted by the user and a model that stopped mid-way are the same kind of asset for the person, and can share “keep and continue/export.” In open prose that cannot be checked, “wrong” is hard to split automatically; offer a user mark, and if unmarked prefer to keep it as a completed state with a weak hint rather than silently delete it as empty. This entry does not treat “wrong that looks entirely normal” — that is a detector blind spot, not the case where wrong has already been spotted.

Applying it

• The failure panel has three primary buttons: empty → change channel or retry; wrong → discard this result and open the determinate path, clear the result slot; partial → keep the visible fragments, mark the holes, allow filling only the holes.
• A wrong result must not copy into “done” or send outward unless the user explicitly says “treat this as a draft.”
• Mark partial holes with structure, not a vague “may be incomplete.”
• Check: on the same feature, inject an empty packet, a complete JSON that fails a check, and a JSON missing a field. If the three surfaces look the same, typing does not exist. Then see whether partial fields survive degradation and whether the bad JSON can still be sent in one click.

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.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: L3.11 Streaming the generation process · L4.13 Agent failure reporting and escalation · L3.12 Editing and taking over generated content
• Search terms: typed degradation · empty vs wrong vs partial · failure taxonomy