Error messages for open input stay vague because the system does not know what the user meant to do

What it is

A form check can say “the phone number is a digit short” because the legal set for that field is known in advance. When open input fails, the system often knows only that this run did not produce an acceptable artifact, not what an acceptable artifact would have been. An underspecified NL error cannot point at the missing goal. It can only point at the process (timeout, refusal, broken format) or at the user (“try asking another way”). The loss of specificity is not lazy copy. The target variable was never observed.

People blaming their own wording is an attribution bias. This is the other end: even when the product wants to explain the miss, it lacks the X in “you wanted X.”

Why it happens

Errors in deterministic UI are deviations from a known pattern: types, required fields, permissions. “Errors” in generative UI are often a failed evaluation function, or a model deciding to refuse, and the gold standard for that function is not in the user’s sentence. Without a gold standard, diagnosis cannot name the dimension of failure — wrong object, wrong grain, or generation should never have been the path. Copy retreats to universal quantifiers: “something went wrong,” “I may have misunderstood.”

Worse, fluent wrong answers never enter the error channel. The error module can speak only when the system admits failure; most harm in open input is unadmitted failure. The few true errors that remain cannot speak cleanly for lack of intent, and trust in the error channel drops another notch.

Studying it

Collect three miss classes: explicit refusal, format or tool-call crash, and outputs humans mark unacceptable that the system handed over as success. A second group, seeing only the product’s error copy (or “no error” for the third class), reconstructs “what the user meant to do” and “what to change next.” Independent variables: whether copy includes the assumption the system actually used, whether it lists two or three possible intents, whether it shows checks already tried. Dependent variables: accuracy of reconstructed intent, success of the user’s next sentence, rate of spotting an un-errored wrong answer as a miss.

The gold standard must come from a task brief, not be reverse-engineered from the failure copy — otherwise you are testing reading, not the error channel.

Where it stops holding

When the UI pins the task (“translate into German,” “sum this column”), intent is known and errors can be specific again; the claim weakens. Tool calls that return structured codes (permission, quota, schema) can be very specific on the process side and still fail to say “which kind of summary you wanted.” Creative exploration has no “wrong,” and the error channel should not appear. This entry also does not cover how help docs or examples display capability.

Applying it

• Restate the assumption the system actually used (object, format, success criterion) before talking about the miss. Do not fake a diagnosis when there was no assumption.
• When intent cannot be unique, offer two or three mutually exclusive possible goals to tap, rather than asking people to “be clearer.” The tap is filling in the missing X.
• Route “looks like success, fails evaluation” into the same failure channel. Do not speak only at crashes.
• Check: ten real failures, original prompt hidden, only the error left. People uninvolved in the design write “what the user wanted, what to change.” If most cannot name an action more specific than “try again,” the error channel still does not know that X.

Related

• Same group: L2.01.1 Open input does not cue the range of capability · L2.01.2 Not knowing how to say it is the main barrier · L2.01.3 Differences in wording produce differences in results · L2.01.4 An empty box conveys no boundary; the first sentence is a guess · L2.01.5 Open input steers failure attribution toward “I said it badly” · L2.01.6 Synonymous phrasings yield different results, so users invent phrases to memorize · L2.01.7 Openness makes functions non-enumerable; the product can no longer show a complete capability list
• Nearby: L1.06 Graceful Degradation of AI Failure · L2.15 Ambiguity and Clarifying Follow-ups · L4.13 Agent Failure Reporting and Escalation
• Search terms: underspecified NL error · intent-unknown failure · generative error message