Open input steers failure attribution toward “I said it badly”
Aliases: user-blaming open input · prompt self-blame · internal attribution of NL failure
What it is
A search with no hits gets “it isn’t in the collection.” A button that does nothing gets “this feature is broken.” An open-input miss more often starts with “maybe I asked it wrong.” Self-attribution of prompt failure is a responsibility tilt peculiar to an open channel: because the input looks like the user’s own language, a bad output is read as a writing failure, not as the system missing that class of task.
This is not about error copy being vague — that is the system failing to speak. This is about which side people park the cause on.
Why it happens
In Weiner’s attribution theory, controllable internal causes are the easiest handle on failure. Wording is more controllable than model weights, and more internal. The interface cooperates: caret, draft, send all insist “these are your words.” The model side usually has no matching “this time I used capability X and did not have Y.” The only editable object left is the prompt. People rewrite, add words, swap honorifics, as if marking up an essay, not switching tools.
Self-blame has short-run adaptive value: rephrasing sometimes does save the turn. The cost is that capability failures get systematically coded as user-skill problems. Product logs show “low prompt quality” and hide “this task class already has a low hit rate.” Users stop filing defects, having settled them privately as not knowing how to speak.
Studying it
After a controlled miss, run an attribution interview or a forced choice: my wording, the system cannot, the task is unreasonable, random fluctuation. Manufacture the miss with the same downstream refusal so true capability differences do not confound. Independent variables: entry form (open box vs task picker), whether failure copy mentions a capability limit, whether the user already had one success. Dependent variables: internal versus external attribution share, whether they keep rewriting the same sentence, whether they look for another feature, whether they file feedback.
A standing experimenter pushes attribution toward “I wasn’t clear” via social desirability. Remote, no experimenter, neutral failure copy, is closer to the private settlement in the product.
Where it stops holding
Experts and prompt engineers already treat “tune the prompt” as a real skill; self-attribution is method, not necessarily injury. If the system marks the miss as a capability refusal — “I cannot do X” — attribution moves outward. In products mixed with graphical controls, people may still blame the button. In high-stakes professional settings (medical, legal), external attribution is stronger because the cost of “try another sentence” is unacceptable. This entry does not cover the superstition that forms after synonymous sentences fork.
Applying it
- Split failure replies into two classes: capability refusal (“I cannot take this kind of request”) and uncertain parse (“I took this as A; if you wanted B…”). The first must not suggest “try saying it differently.”
- Do not put “better prompts, better results” as the only story in empty or error states. That pre-assigns the miss to the user.
- Offer “this is not what I wanted” without requiring a rewrite: switch task type, narrow scope, or route to a human or rule path.
- Check: one request you know you cannot fulfill. Watch the first move after failure — rephrase, change entry, or quit. If rephrasing dominates and later interviews still say “I didn’t ask it right,” open input has absorbed the attribution.
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.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 · L2.01.8 Error messages for open input stay vague because the system does not know what the user meant to do
- Nearby: L1.06 Graceful Degradation of AI Failure · L5.03 Trust Calibration · L2.15 Ambiguity and Clarifying Follow-ups
- Search terms:
self-attribution of prompt failure·causal attribution·user-blaming interface
Cards in the same group
- L2.01.1Open input does not cue the range of capability
- L2.01.2Not knowing how to say it is the main barrier
- L2.01.3Differences in wording produce differences in results
- L2.01.4An empty box conveys no boundary; the first sentence is a guess
- L2.01.6Synonymous phrasings yield different results, so users invent phrases to memorize
- L2.01.7Openness makes functions non-enumerable; the product can no longer show a complete capability list
- L2.01.8Error messages for open input stay vague because the system does not know what the user meant to do