A clinical word, borrowed with its whole frame attached
"Hallucination" came into this field from clinical language, and it did not arrive alone. It brought its frame.
A hallucination is an episode. It interrupts a faculty that is otherwise sound. It is involuntary, it is exceptional against a baseline of ordinary perception, and it is understood as something happening inside a person rather than something the room did to them. Those implications are not decoration. They are what the word means, and they transfer intact every time an engineer types it into a ticket.
Applied to a language model, all of them are wrong. Generating a confident, ungrounded sentence is not an interruption of normal function — it is normal function, running correctly, on an input where nothing in the mechanism happened to keep it tethered. There is no sound baseline that the episode deviates from. And the fault is not located inside the model in any sense that helps you, because the model is not a party that can be held responsible for anything.
So the word is not merely imprecise. It is load-bearing in the wrong direction. It assigns the failure to a component with no obligations, and it does so before anyone has looked at the system that shipped the output. By the time you are debating whether a given answer counts as a hallucination, the vocabulary has already decided the most important question for you: whose problem this is.
The model has no category for "claim"
Here is the part the clinical frame obscures. A fluent false sentence and a fluent true sentence are the same kind of object to the thing that produced them.
The mechanism produces well-formed continuations. Groundedness — whether a sentence corresponds to something that exists, whether it can be traced to a source a person could check — is a separate property that lives outside the generation step. Nothing in the path distinguishes them, so the output arrives with no marker for which one you got.
The consequence is uncomfortable and worth sitting with: when the answer is correct, it did not arrive with any more warrant than when the answer is wrong. It arrived the same way. You found out it was correct afterwards, by knowing the answer already or by checking, and neither of those is a property of the system. A team that only inspects outputs that turned out false will study the wrong sample forever, because the true ones came out of the same process carrying the same amount of evidence, which is none.
This is why "reducing hallucinations" is such a satisfying and such an empty goal. It describes a change in how often the failure becomes visible, not a change in what the system can vouch for. A system that cannot attach a source to a claim cannot attach one to its good answers either. The category error is not in the model. It is in treating fluent output as a claim when the thing that produced it has no concept of one.
The word bills a department that cannot pay
Watch where the work goes once someone writes "the model hallucinated" in a bug report.
It goes to the model layer. Swap the model. Rewrite the prompt. Add an instruction telling the system to be accurate and to say when it does not know. Turn a knob. Wait for the next release and hope the problem ages out. Every one of these is a plausible move, several are worth doing, and not one of them changes the structural fact that an unverifiable sentence is being handed to someone who will act on it.
The organizational effect is worse than the technical one. "Hallucination" is nobody's ticket. It belongs to the vendor, or to the field, or to next quarter's model. It is spoken about the way people speak about weather — a condition you plan around, not a decision anyone made. Meanwhile the thing that shipped is yours. The surface that displayed the sentence is yours. The choice to display it without a check is yours, and it was a choice, made by someone, probably in an afternoon, probably without anyone noticing it was a choice.
The refusal list published on the studio names work that depends on fabricated proof. That refusal is easy when the fabrication is deliberate. The hard version is the ambient one, where nobody fabricated anything on purpose and the vocabulary quietly converts a design failure into a natural phenomenon. A word that makes fabrication sound like weather leaves no one responsible for the forecast.
Rename the failure after the decision that caused it
Replace the noun with a sentence about what happened: the system displayed a claim it could not attach to a source.
That sentence is longer and it is worth the characters, because it has three things the old word lacked. It names an action rather than a condition. It names a surface — the place the claim was displayed. And it implies an owner, because someone decided that surface could carry unattributed text.
This is the same move as refusing the word "agent" and stating instead what the system may decide. In both cases the fix is to stop describing the system's alleged nature and start describing its permissions. A noun invites an argument about what the thing really is. A permission statement invites a review, and a review can end.
The rename also changes the unit of work. Incidents are an infinite queue; you can triage them forever and never converge, because the supply is generated fresh by the same mechanism every day. Surfaces are finite. Every place your product shows model-generated text either carries a verification path or it does not, and that is an inventory you can actually complete. You walk the surfaces, you write down what each one asserts, you write down what check stands behind it, and you find the rows where the second column is empty. Those empty rows are the real bug list. They existed before any user complained, and they will outlive whichever model you are currently blaming.
The question the old word never let you ask
Once the failure is named after a decision, the design question becomes obvious and answerable: which assertions may this system make with nothing attached, and who agreed to that?
For some surfaces the honest answer is that unchecked output is fine. A draft, a rewrite, a list of options, a first pass at naming something — the user reads every word before it goes anywhere, and the user is the verification step. That is a legitimate design, and it becomes stronger when you say it out loud, because saying it out loud is what keeps the surface from silently growing into something else. Surfaces drift. The brainstorm box gets a "send" button eventually.
For other surfaces the answer is unacceptable and the old word was hiding it. Anything a person will forward, sign, bill against, or repeat to a customer needs a claim that can be traced. Not a more reliable model — a traceable claim. These are different projects with different costs, and the word "hallucination" makes the first one look like the solution to the second.
The cheaper path is usually to narrow what the system asserts rather than to chase reliability across an open-ended surface. This is the same economics as preferring a verdict to a dashboard: a smaller promise is easier to keep, and — the part that matters here — it is easier to check. A system that answers a bounded question against a known source can be verified. A system that answers anything cannot, and no amount of tuning converts one into the other.
There is a simple test for whether your vocabulary is doing its job. Nobody outside the building says "the model hallucinated." They say it told them something that was not true, and they mean it the way they would mean it about a product that printed the wrong price. That is the accurate description. It stays attached to a thing someone built and can therefore change. Use the user's version internally too, and notice how much harder it becomes to close the ticket without fixing anything.