Fluent wrong output is the most dangerous kind of failure; it trips no degradation
Aliases: undetected wrong output · false-success content · degradation blind spot
What it is
Degradation is woken by a failure signal. A grammatically whole, calmly toned, well-formed wrong — a fake citation, a wrong amount, a statute that does not exist — produces no empty packet, no exception, no “incomplete” mark. A fluent error therefore walks around degradation and is used as success.
It is more dangerous than a silent blank. A blank at least sometimes looks blank. This error looks exactly like the completed state the user asked for.
Why it happens
Checkers know structure, not the world. JSON parses, required fields have values, the tone sounds like support — the gate opens. Factual error sits inside the fields, invisible to the gate. Training objectives that favour fluency and format-following are exactly the factory for objects the gate loves and the world does not.
Human detection is weak in the same place. Fluency lowers suspicion; correct format lowers the motive to look again, especially when the user does not own the domain (which is why they asked). System detection and human detection are then both absent, and the whole net of degradation is empty.
Studying it
Plant world-level errors (wrong numbers, fake sources) while keeping structure and fluency. Watch: whether any degradation trips, user detection, outbound rate. Add a condition with a cheap world check (open the source, compute twice, resolve the citation). Dependent variables: mechanism trip, human detection, outbound send.
Do not use grammatical wrecks as materials. Grammar trips the structure gate and will not measure this card.
Where it stops holding
Closed tasks wired to an authority check (stock against inventory, amounts against a ledger, ids against a directory) will catch fluent errors and this claim’s edge dulls — provided the check actually runs, not “the service exists.” Open generation and assertions that cannot be sourced will barely support a gate; the remaining moves are to lower the trusted look of fluency, or to position the output as a draft that must be checked by a person. This is not “wrong should take a different road from empty and partial” — that assumes wrong has been detected. This is the stretch that cannot be detected.
Applying it
- Wire fields that have a world truth to an independent check, and only then call degradation. Do not use “the model says it is sure” as a check.
- For output with no truth, remove completed-state appearance: a draft watermark, no one-click outward, a checklist that must be opened. Fluency must no longer equal sendable.
- Lift numbers, dates, names, and clause ids into their own blocks so they can be sampled. Do not bury them in paragraphs.
- Check: in staging, insert a perfectly formed fake citation or a wrong amount. If no gate lights and a person still sends it, the degradation system is blind on the dearest kind of miss. Treat that miss as an incident, not as “the occasional hallucination.”
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.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.03 Hallucination and the fact-checking burden · L1.04 Presenting confidence · L4.02 Automation bias
- Search terms:
fluent error·undetected wrong output·degradation blind spot
Cards in the same group
- L1.06.1On failure, fall back to a deterministic path
- L1.06.2The degradation order must be defined in advance
- L1.06.3Silent failure is more harmful than explicit failure
- L1.06.4Empty, wrong, and partial output are different failures and need different fallbacks
- L1.06.6Falling back to a deterministic path presupposes that path is maintained, not that it exists only during an incident
- L1.06.7Degradation must keep what the user already entered; starting over is the most common fallback failure
- L1.06.8Timeouts and rate limits are expected failures; their copy must be distinct from model error