The first time I heard a senior engineer say “the model hallucinated” without flinching, I knew the conversation had turned. Two years ago that sentence carried a faint embarrassment, the way “the kernel panicked” used to carry one in the late 1990s before operating-system engineering matured. Today it is a class of defect with a name, a taxonomy, and a growing literature of mitigations. The punchline became a design constraint. That is what naming does to a failure mode.

I am seeing this clean shift in the technical writing I track. Hallucination has stopped being a debate (“do they?”) and started being an engineering category (“which kind, originating where, caught how”). The canonical reference is still Ji et al.’s 2022 “Survey of Hallucination in Natural Language Generation”, which split the field into intrinsic and extrinsic hallucinations. The practitioner literature is adding a third class, systemic, for the failures that originate not in the model but in the surrounding system. Those three labels are how mature teams talk about the failure in 2026, and the mitigations split along a clean second axis: symbolic grounding (provable, anchored against an external truth source) and semantic peer review (probabilistic, one model judging another). The grown-up stack uses both, and knows which is which.

This guide names the three kinds, draws the mitigation stack, and points to the deeper pieces that go one level down on each.

1. Why the taxonomy matters before the mitigations

A bedroom producer who hears a problem in the mix has one word for it: “weird.” A mastering engineer hears the same problem and says “200 hertz buildup from the cardioid placement on the kick, the room is loading the bass.” Same defect; different vocabulary; only one of them can fix it. The whole point of a taxonomy is to make the defect addressable. You cannot wire a control against a problem you have not named.

For the first two years of production LLM work, hallucination was the “weird” of language models. Teams reported it, leadership got worried about it, vendors promised to reduce it, and almost no one could say which kind of hallucination they had just shipped. The conversations I sat in often ended the same way: “we will tune the prompt.” That is the LLM-engineering equivalent of telling the mastering engineer to “fix it in post.” It does not work because the diagnosis came before the vocabulary.

Ji et al.’s taxonomy gave the field its first vocabulary. Intrinsic and extrinsic are the two original classes. Systemic is the third class the practitioner literature has been adding, and once you have all three on the table the conversation changes. You stop asking “did the model hallucinate” and start asking “which of the three did we just produce, and where in the system did it originate.” That second question is the one with an engineering answer.

2. The three classes, with worked examples

Intrinsic hallucinations contradict the input the model was given. The summary says the contract expires in 2027 when the contract in the prompt says 2025. The translation flips a negation. The structured extract gets a numeric field wrong even though the number is verbatim in the source. The model had everything it needed and still produced a contradiction. This is the class that benchmark designers measure with metrics like faithfulness, and it is the most tractable, because the ground truth lives in the prompt itself.

Extrinsic hallucinations add claims that go beyond what the input supports. The biography includes a board seat that exists nowhere in the source documents. The product description invents a feature. The legal brief cites a case that never existed (a 2023 incident that put hallucination on a courtroom docket and into the public vocabulary). The model is not contradicting anything; it is extrapolating with full grammatical confidence. Extrinsic hallucinations are harder to catch in the moment because they read as coherent additions to plausible content. They require checking against an external truth, not just an internal consistency pass.

Systemic hallucinations are the third class, the one Ji et al. did not formalise in 2022 because the practitioner literature was not there yet. The model produces a wrong answer, but the originator of the error is not the model. The retrieval layer returned irrelevant or stale documents and the model dutifully answered from what it was given. The context window filled up and an eviction policy dropped the document the answer depended on, but the model kept answering as if the document was still there (the parent pillar names this one “hallucination by amnesia”). The system prompt was ambiguous and the model interpolated. The post-processing layer failed to enforce a refusal pattern and a wrong answer reached the user. In every systemic case the model behaved exactly as a probabilistic engine should; the harness around it failed.

I want to flag the third class explicitly. “Systemic” is a label the practitioner literature is converging on but the term is not yet canonical in the Ji et al. sense, and I am using it deliberately as the working name for the failure class that originates outside the model. The deep dive on the taxonomy goes further into the boundary cases and the labelling debate.

Deep dive on the three-class taxonomy

3. The two-axis mitigation stack

The mitigations split along two clean axes that most teams confuse. The first axis is what kind of truth you can check against: symbolic (a structured, curated source you can query deterministically) or semantic (another model’s judgement). The second axis is where in the pipeline you intervene: prevent the failure before it leaves the model, or catch it after.

Symbolic mitigations anchor the output against a structured truth source that can be queried deterministically. The simplest version is retrieval-augmented generation itself: the corpus you retrieve from is the symbolic anchor, and the test of whether the model stayed within it is the faithfulness metric. The stronger version is grounding entity claims against an external knowledge graph. Wikidata is the public example everyone knows, a curated graph with stable identifiers (the EU AI Act has its own Q-number, every named drug has one, every public company has one) that lets you check whether the entities a model named exist, are spelled correctly, and stand in the relationships the output claims. When symbolic ground truth exists for a domain, hallucination becomes catchable, not just preventable. The harness component is deterministic, which is exactly what an auditor wants to see.

Semantic mitigations use another model’s judgement as the truth source. The canonical pattern is LLM-as-judge, formalised in Zheng et al.’s 2023 MT-Bench paper. A judge model reads the candidate output, scores it against a rubric (faithfulness, helpfulness, refusal correctness, hallucination presence), and either gates it or flags it for review. Semantic mitigations are probabilistic by construction: the judge inherits the biases of its training, the verdict caps at the judge’s own capability, and a strong judge can still be fooled by a confident-wrong output. Where they earn their keep is in large-N comparative evaluation (which of these ten responses is best), in rubric-bounded gating (does this output break any of these ten rules), and in cheap pre-screening before human review.

The mature stack uses both axes. Symbolic grounding for the claims that have ground truth available (named entities, regulated facts, structured data). Semantic peer review for the claims that do not (judgment calls, summarisation quality, refusal correctness). Confusing the two is the most common mistake I see. A team will reach for LLM-as-judge to catch a fact error a Wikidata lookup would have caught for free, or reach for a knowledge-graph check on a tone or helpfulness judgement that has no symbolic ground truth. The axis split is the discipline.

The middle of the article going deeper on the “stack, not three tricks” framing is the next piece down.

Deep dive on how the response layer actually reduces hallucinations

4. When the hallucination is the design, not the bug

There is a contrarian frame senior practitioners are starting to adopt and it is worth naming here. For some workloads, hallucination is the feature. A creative writing assistant that never extrapolates beyond its input is a transcription tool, not a creative assistant. A brainstorming partner that refuses every claim it cannot ground is dead weight in an ideation session. The question is not “did the model hallucinate” but “is hallucination acceptable for this workload, in this context, with these stakes.”

The design move is to push the question up one level. Decide, per workload, what kind of output the system is allowed to produce, and wire the harness to that decision. A legal-research assistant gets symbolic grounding plus an extrinsic-hallucination catcher and refuses on any unverifiable claim. A marketing copywriter gets a semantic judge for tone, no symbolic check, and high tolerance for extrapolation. A clinical decision-support tool gets all of the above plus a hard stop. The harness is not a single configuration; it is a set of profiles tuned to the workload’s tolerance for each class of hallucination.

Deep dive on hallucination as a design constraint

5. The two grown-up mitigation patterns

The two deepest pieces sit on the two ends of the symbolic-versus-semantic axis. Both are worth their own article because both are under-built in most enterprise stacks, and both reward careful design.

Wikidata and external knowledge graphs as ground truth. Anchoring entity claims against a curated external graph is the most under-used symbolic mitigation. Wikidata is the public starting point; an internal ontology or a domain-specific knowledge graph is the stronger version. The pattern is simple in shape and disciplined in execution: extract the entity claims from the model’s output, query the graph for each, and flag any that fail (entity does not exist, relationship does not match, attribute is wrong). When the symbolic ground truth exists, this turns a probabilistic problem into a deterministic one, which is exactly the kind of mitigation an audit log can defend.

Deep dive on Wikidata-grounded output checks

LLM-as-judge. The semantic mitigation pattern, where one model evaluates another. The honest read on this pattern is that it works in places people often miss and fails in places people often trust it. It works for large-N comparative evaluation (rank these ten responses) and rubric-bounded scoring (does this output break these ten rules). It fails when teams treat the judge’s verdict as ground truth instead of a probabilistic signal, when the judge is weaker than the candidate model, when the rubric encodes biases the judge inherits and amplifies. The discipline is in scoping the judge to what semantic review can actually do, and combining it with symbolic checks for everything that has a deterministic answer.

Deep dive on LLM-as-judge: where it works and where not to trust the verdict

6. A short note on what this guide does not cover

This guide names the failure mode and the mitigations. It does not cover the four other sides of the harness, each of which has its own taxonomy and its own depth. Retrieval and grounding (where the corpus comes from, how chunks are scored, how citations are surfaced) is the upstream dependency that determines how many hallucinations the model gets the chance to produce in the first place. Guardrails and runtime controls are the policy layer that gates the output. Evaluation and benchmarking is the discipline that measures whether the mitigations actually hold. Observability and audit is the surface a regulator or an incident-review board reviews afterwards. The taxonomy above sits inside that larger frame; the parent piece draws the whole wrapper.

Back to the parent: Hallucinations, Guardrails, and the LLM Harness

7. Resources

• The three classes of hallucination: intrinsic, extrinsic, systemic (deep dive)
• Reducing hallucinations: the response layer as a stack (deep dive)
• When hallucination is a design constraint, not a bug (deep dive)
• Wikidata and knowledge-graph grounding for output checks (deep dive)
• LLM-as-judge: where it works, where the verdict fails (deep dive)
• Retrieval and grounding
• Guardrails and runtime controls
• Evaluation and benchmarking
• Observability and audit
• Primary source: Ji et al., “Survey of Hallucination in Natural Language Generation” (2022)
• Primary source: Zheng et al., “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena” (2023)
• Reference graph: Wikidata (Wikimedia Foundation)
• Regulatory reference: NIST AI 600-1, Generative AI Profile of the AI Risk Management Framework