What Hallucination Actually Is
A language model generates text by predicting the next token given all previous tokens. That's the whole mechanism. The model was trained on a massive corpus, and through that training it learned statistical patterns: what words follow what other words, what structures follow what other structures, what a plausible answer to a question looks like given the question's phrasing and context.
There is no separate fact-checking module. There is no internal database the model queries before committing to a claim. The "knowledge" is distributed across billions of numerical weights that encode statistical relationships — not a lookup table, not a verified record. When the model generates a regulation's effective date, a case number, a person's title, it is generating what a correct answer to that kind of question looks like, based on patterns it absorbed during training.
The model cannot distinguish between "I learned this accurately" and "I'm generating something that fits the pattern of knowing this." Both produce the same output format, the same confident tone, the same citation style. There is no internal flag that fires when the model is wrong. It doesn't know it's wrong. It's doing exactly what it was trained to do.
A software update won't fix this. Newer models hallucinate less frequently on well-represented topics, but the mechanism that produces the error is the same mechanism that produces the correct answer. Evaluations of frontier models on factual benchmarks consistently show error rates in the range of 5–20% depending on domain and question type — lower for common knowledge, substantially higher for specialized, recent, or narrow topics. Those numbers shift with model generations, but the underlying mechanism does not.
Grounding: Mitigation, Not Cure
Grounding is the family of techniques that reduce hallucination by giving the model external information to work from rather than relying entirely on what it learned during training.
Retrieval-augmented generation (RAG) retrieves relevant documents at inference time and includes them in the model's context window. The model generates its answer using that material. Citations ask the model to attribute specific claims to specific sources. Tool use lets the model call external systems — databases, APIs, calculators — and incorporate the results. Each approach narrows the surface area where hallucination can occur.
None of them eliminate it. A grounded model can misread the document it was given. It can conflate retrieved content with training-data patterns. It can produce a plausible synthesis that doesn't accurately represent either source. In evaluations of retrieval-augmented systems on factual tasks, grounding typically reduces hallucination rates from the 20–30% range to the 5–10% range. That's a meaningful improvement. It also means roughly one in ten outputs may still contain a fabricated or misattributed claim, and the output will not tell you which one.
The vendor who says "we've grounded it on your policy documents" is telling you something true and something incomplete. The grounding reduced the problem. It did not close the verification gap.
Okta Concept Mapping
The closest IDAM analogue is IdP assertion trust. When your identity provider asserts a claim — "this user holds the compliance-auditor role" — your application trusts that assertion because of a trust relationship established at configuration time, backed by a cryptographic signature you can verify. The model makes assertions the same way: confidently, in the correct format, with the right structural markers of authority. The break is that there is no trust anchor. The model's "I am confident" signal is indistinguishable from its "I am wrong but the pattern fits" signal. In IDAM, you can verify the signature. In LLM outputs, there is no cryptographic equivalent for factual accuracy — and grounding does not create one.
The Calibrated Trust Model
Treat model outputs the way you treat unverified identity claims. You wouldn't grant access based on a self-asserted role with no backing credential. You'd require the claim to be verified against an authoritative source before it carries weight. The same logic applies here.
Outputs that are low-stakes and reversible — a draft email, a summary of a meeting transcript, a first pass at a requirements document — can move forward without a verification step. The cost of a mistake is low and the correction path is short.
Outputs that are high-stakes or irreversible require a verification path. A model-generated summary of a federal regulation that will inform a procurement decision. A compliance flag on a contract clause. A recommended access policy for a sensitive system. These need a human or an authoritative system in the loop before they act as inputs to anything consequential.
In any procurement or deployment conversation, the operative question is: what is the verification path when the model is wrong, and who owns it? Every model hallucinates. That part is settled. If the answer to the verification question is vague, the architecture isn't finished yet.
Grounding narrows the problem. It does not transfer the accountability. That part stays with whoever deployed the system.