Hallucination Is Not One Thing

Chapter 1 began with a familiar failure: a language model says something fluent that it cannot justify.

That description is useful until we try to build a detector.

Consider six outputs:

A. The model invents a person who does not exist.

B. The model names two real companies but reverses which acquired which.

C. The model cites a real paper that does not support the claim.

D. The model says it inspected a file that it never received.

E. The model answers a question even though the available evidence is insufficient.

F. The model gives the same generic recommendation after the decisive facts
   of the problem have been reversed.

All six can produce plausible text.

All six can damage a system.

But they are not the same failure.

A world-knowledge checker may catch A and miss D. A source-entailment check may catch C and know nothing about E. A runtime validator can reject D without knowing whether A is historically true. A perturbation test may expose F while accepting every factual sentence it contains.

That gives us the central rule of this chapter:

A hallucination detector is only meaningful after we specify what kind of failure it is supposed to detect.

And beneath that rule is an even more operational sequence:

    graph LR
    C[candidate] --> F[failure definition]
    F --> R[reference]
    R --> M[measurement]
    M --> P[policy]
  

The word hallucination is useful as an umbrella.

Engineering requires us to open the umbrella and identify the structure underneath it.

1. Taxonomy is a specification language

It is tempting to treat taxonomy as the academic part of the subject: useful for surveys, but secondary to implementation.

The opposite is true.

The failure definition determines the reference.

The reference determines the measurement.

The measurement determines what a policy can reasonably do.

Suppose the model says:

The trial enrolled 420 participants.

What should we compare that statement with?

Possible references include:

the external world

the retrieved paper

the user-provided document

a database row

a tool result

the model's own previous claims

the current execution trace

Those references are not interchangeable.

A statement can be true in the world and unsupported by the supplied paper.

It can be faithful to a paper that is itself wrong or obsolete.

It can accurately describe what normally happens while falsely claiming that a tool executed during this run.

It can agree with every external source and still contradict something the same response asserted two paragraphs earlier.

So the useful question is not merely:

Is this hallucinated?

It is:

Relative to what reference did the output fail?

That question gives us something better than a list of labels. It gives us a way to specify a detector.

2. The taxonomy has several axes

The hallucination literature already contains several useful but overlapping taxonomies.

Earlier natural-language-generation research often distinguishes intrinsic from extrinsic hallucination relative to a source. An intrinsic hallucination contradicts information present in the source; an extrinsic hallucination introduces information that cannot be verified from the source.[1]

A more recent LLM-focused taxonomy from Huang and colleagues separates factuality hallucination from faithfulness hallucination. Factuality concerns disagreement with verifiable real-world facts. Faithfulness concerns disagreement with instructions, context, or logical structure that should constrain the output.[2]

These are not competing taxonomies.

They are describing different dimensions.

For this book, we will make those dimensions explicit.

A sixth diagnostic, sensitivity, asks whether behavior changes when decisive inputs change. It is important for reliability but sits outside strict factual hallucination.

This means a failure can be described more precisely than with one noun.

For example:

reference:          supplied document
failure relation:   contradiction
measurement unit:   claim ↔ evidence
information path:   retrieval + generation
propagation:        transient response

That is what the older literature would call an intrinsic hallucination.

Or:

reference:          runtime trace
failure relation:   fabricated observation
measurement unit:   claimed observation ↔ trace event
information path:   model generation
propagation:        stored in agent memory

That is a runtime-state hallucination with persistence risk.

A multidimensional representation is less tidy than a single hierarchy.

It is much more useful to software.

3. Use the smallest measurement unit the failure requires

Chapter 1 treated the response as too coarse a unit for many factuality tests.

That remains true, but we can now state the stronger rule:

Use the smallest measurement object that still contains the failure.

For ordinary factuality, that object is often an atomic claim.

Consider:

Marie Curie won the Nobel Prize in Physics in 1903 and the Nobel Prize in Chemistry in 1911. She later became the first woman to serve as president of France.

A response-level label hides the useful structure.

We can decompose it:

claim_1 = "Marie Curie won the Nobel Prize in Physics in 1903."
claim_2 = "Marie Curie won the Nobel Prize in Chemistry in 1911."
claim_3 = "Marie Curie became the first woman president of France."

Now each claim can have a different relationship to evidence.

OpenAI’s long-form factuality evaluations use this kind of claim-level decomposition: factual claims are extracted and checked individually, while response-level metrics separately ask whether the complete answer contains major factual errors.[3]

But claim-level decomposition is not universally sufficient.

Even claim extraction is not free.

A sentence such as:

The study found no significant reduction in mortality, although a post hoc analysis suggested a possible benefit in older patients.

contains at least two propositions with different strength and evidential requirements. Negation, modality, comparison, subordinate clauses and presuppositions all complicate decomposition.

Later measurement chapters will therefore treat claim extraction as part of the pipeline rather than assume that claims arrive perfectly segmented.

4. World factuality: disagreement with external reality

The most familiar hallucination is a claim that conflicts with verifiable external facts.

The reference is the external world as represented by sufficiently trustworthy and current evidence.

Examples include:

invented entity
wrong date
wrong number
wrong location
wrong attribute
wrong event
wrong relationship

A simple case is:

Claim:
"Dublin is the capital of Scotland."

World reference:
Dublin is the capital of Ireland.

But factuality failures have different internal structures.

An invented entity creates information that may have no valid external referent.

An attribute error attaches the wrong property to a real entity.

A numerical error can alter one token while reversing the interpretation of an experiment.

A relation error can preserve every entity while changing who did what to whom.

This matters because two claims can belong to the same factuality class while exposing very different detector signals.

The relational hard case

Consider:

Evidence:
Company A acquired Company B from Company C in 2024.

Correct:
Company A acquired Company B from Company C in 2024.

Hallucinated:
Company B acquired Company A from Company C in 2024.

The hallucinated version is fluent.

It contains the same companies, date, event type and almost the same tokens.

At a symbolic level the distinction is obvious:

We should not assume that cosine similarity will necessarily fail on every such pair, nor that a graph extractor will necessarily solve every paraphrase. The engineering point is narrower:

Topical proximity is not a guarantee of relational correctness.

A similarity detector can therefore look excellent on easy unsupported negatives and still fail on role reversal, polarity changes, quantities or temporal ordering.

This is one of the boundaries we will later attack directly when we evaluate Hallucination Energy.

5. Context faithfulness: disagreement with supplied evidence

Now change the reference.

Suppose a system gives the model this context:

The study found no statistically significant reduction in mortality.

and the model writes:

The treatment significantly reduced mortality.

We do not need to query the entire external world to identify the failure.

The answer contradicts evidence that the system explicitly supplied.

This is a context-faithfulness failure.

When an explicit source exists, the intrinsic/extrinsic distinction becomes useful inside this category.

Intrinsic: contradiction

Source:
Alice founded Acme in 2018.
Bob became CEO in 2022.

Output:
Bob founded Acme in 2018.

The output contradicts the source.

Extrinsic: unsupported extension

Source:
Alice founded Acme in 2018.

Output:
Alice founded Acme after leaving a senior role at Orion Labs.

The additional statement may be true.

It may be false.

The supplied source does not establish it.

This gives us one of the book’s most important distinctions:

Unsupported does not mean false.

A source-bounded verifier can correctly reject a true statement because its task is to determine support from this evidence, not truth in the entire world.

The reverse case matters just as much.

source:      false or outdated statement
summary:     faithfully reproduces the statement

The output may be perfectly faithful and factually wrong.

So factuality and faithfulness are different reference tests, not two levels on one scale.

Deduction is not automatically hallucination

Source-bounded verification must also leave room for valid inference.

If the evidence establishes:

A > B
B > C

then concluding:

A > C

adds a sentence not literally present in the source, but the conclusion is logically entailed.

The useful boundary is therefore not:

written explicitly in source
vs
not written explicitly in source

It is closer to:

entailed or justifiably derived
vs
unsupported extension

That makes faithfulness measurement harder, but it prevents a grounding system from reducing useful synthesis to quotation.

6. Internal consistency and instruction following: nearby but distinct constraints

Huang and colleagues include logical inconsistency and instruction inconsistency under the broader heading of faithfulness.[2]

For engineering, it helps to make our stance explicit.

Internal contradiction

Consider:

Paragraph 1:
The trial enrolled 240 participants.

Paragraph 4:
The study population consisted of 180 participants.

No external source is required to detect the inconsistency.

The reference is the model’s own earlier output.

This is a genuine reliability failure and can accompany hallucination, but it is not identical to world factuality. Both claims might even be wrong relative to the world while still contradicting each other.

Instruction violation

Now consider:

User:
Return valid JSON and do not mention mortality.

Model:
The treatment reduced mortality by 40%.

The output may be factually correct and source-faithful while still violating the task contract.

In this book we will treat ordinary format and instruction violations primarily as constraint-following failures, not automatically as hallucinations.

That boundary matters. If every undesirable model behavior becomes hallucination, the word becomes useless again.

7. Attribution and provenance: the support path can fail even when the claim is right

Consider:

A 2024 study in Nature showed that the intervention reduced error rates by 40%.[1]

Several independent checks are hidden inside that sentence:

    graph TD
    S1[source exists?] --> S2[source identity verified?]
    S2 --> S3[claim attributable to source?]
    S3 --> S4[source entails claim strongly enough?]
    S4 --> S5[source permitted by policy?]
  

These are related but not identical problems.

We will use attribution for the claim-to-evidence relationship and provenance for the identity and origin of the evidence itself.

That gives us a useful chain:

source exists?
      ↓
source identity verified?
      ↓
claim attributable to source?
      ↓
source entails claim strongly enough?
      ↓
source permitted by policy?

A factuality benchmark can miss every one of those distinctions.

The claim might happen to be true while the citation is fabricated.

A real source might be attached to the wrong claim.

A source might support a weaker statement than the model publishes.

A source can be accurate but disallowed by policy.

Whether every one of these should be called hallucination is partly terminological. For this book, the important point is architectural:

A correct claim with false provenance is still an unreliable output.

And therefore claim correctness is not enough to establish publication-quality support.

8. Runtime-state hallucination: when the system already knows what happened

Some of the most dangerous failures in agents are not world-knowledge errors at all.

They are false claims about current execution state.

Examples include:

"I inspected the attached PDF..."

when no PDF was attached.

"The shell command completed successfully..."

when no shell call completed.

"The database returned 143 rows..."

when no query result exists.

"As you told me earlier..."

when the supposed earlier turn is absent.

Anthropic’s Claude Mythos Preview system-card evaluations include input hallucination tests covering unavailable capabilities and missing context, including nonexistent tools, files, attachments and prior turns.[4]

This failure class is especially important because the authoritative reference may already exist inside the software.

We do not need a second LLM to decide whether a shell command ran.

We need to compare a normalized claim about execution with the runtime trace.

A real implementation is more careful than:

if model_claims_tool_executed and not trace.has_tool_result:
    fail()

Tool calls can be asynchronous, cached, retried or partially completed. A robust check must canonicalize what the model claimed:

claimed action
claimed target
claimed completion state
claimed observation
claimed time or step

and compare those fields with authoritative events in the execution log.

But the principle remains deterministic:

Do not use probabilistic detection where authoritative system state already exists.

The model produces the assertion.

The runtime owns the event history.

Those responsibilities should not be confused.

9. Adjacent reliability failures: when the answer should not have been asserted

Not every failure we care about is hallucination in the strict factual sense.

That distinction is worth protecting rather than stretching the word until it covers every poor answer.

Epistemic adequacy

Chapter 1 introduced abstention.

For this book, we will call the failure to abstain when available evidence is insufficient an epistemic adequacy failure.

Suppose a user asks:

What caused the outage?

The logs show that the service restarted, but nothing establishes why.

The model replies:

The outage was caused by an exhausted database connection pool.

The hypothesis may be plausible.

It may even turn out to be correct.

The evidence does not currently justify promoting it to an answer.

This is therefore not necessarily a truth failure. It is a decision failure about evidential sufficiency.

The system should instead be able to say:

The current evidence is insufficient.

I can propose hypotheses but cannot establish the cause.

Another retrieval or tool call is required.

Epistemic adequacy is hallucination-adjacent because inadequate evidence frequently produces unsupported assertions, but we will keep the concepts separate.

Sensitivity and context-insensitive convergence

Now consider two prompts:

A startup has six months of runway in a collapsing market.
What should it do?

A market leader has strong margins in a rapidly expanding market.
What should it do?

Suppose both receive essentially the same answer:

Focus on innovation, operational efficiency, customer experience, and data-driven decision making.

The answer may contain no factual fabrication at all.

It still failed to respond to the decisive difference in the problem.

We will call this broader behavior context-insensitive convergence. In earlier work we used the shorter term trendslop.

Sensitivity is therefore not a core hallucination class in this taxonomy. It is a neighboring reliability diagnostic.

That gives us a boundary we will preserve throughout the book:

hallucination control
is part of
reliability control

but

reliability control
is larger than
hallucination control

10. Information path is not the same as failure type

Another common source of confusion is mixing what went wrong with which information channels were available to support the answer.

People often speak about parametric hallucination and contextual hallucination as though these categories explain the complete failure.

They do not.

A model may answer primarily from learned parametric associations.

It may also receive:

prompt context
retrieved passages
tool observations
persistent memory
previous model outputs

Those are information channels.

It is usually difficult to prove that a particular generated token came causally from exactly one channel. A fact may be present both in retrieved context and in the model’s learned parameters.

So rather than claim perfect access to internal causal origin, this book will usually ask:

What information paths were available to support the candidate?

A relation error can arise with no retrieval at all.

The same relation error can occur while summarizing a retrieved document.

A fabricated citation can emerge from parametric memory or from incorrectly combining real search results.

The failure class and the information path are therefore separate axes.

11. One output can fail in several dimensions at once

Taxonomies become dangerous when they encourage mutually exclusive labels.

Imagine an agent says:

I checked the latest FDA database and confirmed that Drug A was approved for Condition B in March 2026.

Suppose:

• no FDA tool was called;
• Drug A is real;
• it was approved for a different condition;
• the date is wrong;
• the agent stores the statement in memory.

The sentence contains several failures:

runtime-state failure
    "I checked the database"

factuality failure
    wrong indication and date

attribution/provenance failure
    nonexistent verification path

epistemic adequacy failure
    assertion promoted without sufficient support

propagation risk
    false claim stored for later use

The right representation is multi-label.

And once the claim is stored, another transformation occurs.

At time $t$:

parametrically generated unsupported claim

becomes part of the environment at time $t+1$:

stored memory
   ↓
retrieved context
   ↓
future model asked to remain faithful to corrupted context

We can write the propagation schematically as:

That is why persistence is not another hallucination type; it is an amplifier and state-transition mechanism.

The original semantic failure and the propagation path should be recorded separately.

12. The taxonomy predicts the detector

Now the reason for the taxonomy becomes visible.

Different failures require different references, measurement objects and verification primitives.

The exact detector family is not predetermined by the taxonomy. Several implementations may be viable.

The important point is that a detector’s blind spot often follows directly from what it observes.

A semantic-containment measure cannot guarantee relation direction merely because the sentences are close.

A runtime trace cannot tell us whether a historical claim is true.

An attribution check cannot prove that the source itself is correct.

A confidence score cannot establish provenance.

A perturbation test can expose invariance without telling us which factual claim is wrong.

This yields another book-level rule:

Every measurement has a blind spot implied by its reference and signal.

A product may still expose one aggregated hallucination_score.

Underneath that scalar, however, the system should know which failure classes contributed to it and which ones were never observed.

13. A diagnostic test for any hallucination claim

Whenever someone says that a model, detector or benchmark “handles hallucination,” ask seven questions:

1. What is the measurement unit? A token, claim, claim–source edge, response pair, execution event or trajectory?
2. What kind of failure counts? Factual error, contradiction, unsupported extension, false attribution, fabricated runtime state, or something else?
3. What is the reference? The world, a source document, retrieved evidence, prior output, execution trace or policy?
4. How did the candidate fail relative to that reference? Contradiction, unsupported extension, misattribution, fabricated observation?
5. What information channels were available? Parameters, prompt, retrieval, tools, memory or previous generated text?
6. What signal does the detector actually observe? Similarity, entailment, confidence, attribution, trace state, repeated sampling or external verification?
7. What important failure can that signal not see?

The seventh question is usually the most revealing.

A detector becomes trustworthy not when it has no blind spots, but when we know where those blind spots are and prevent the system from asking the detector to answer questions it cannot answer.

14. The working schema for this book

We can now replace the flat list of hallucination types with a diagnostic schema.

    graph TD
    C["CANDIDATE OUTPUT"] --> U["UNIT"]
    C --> R["REFERENCE"]
    U --> FR["FAILURE RELATION"]
    R --> FR
    FR --> S["SIGNAL"]
    S --> P["POLICY"]

    subgraph Side_Axes
        IP["Information path: parameters / prompt / retrieval / tool / memory / previous output"]
        PP["Propagation path: transient / published / executed / stored / reused"]
    end
  

This is the vocabulary the rest of the book will use.

It gives us a way to look at a model output and say more than:

It hallucinated.

We can instead ask:

What failed?
Relative to what?
At what unit?
Through which observable signal?
What could the detector not see?
What did the system allow the failure to become?

That is a much more useful engineering description.

This schema is descriptive. Chapter 3 turns it into a data object the runtime carries — the Claim Verification Object — and Chapter 4 fills the signal node with typed sensor outputs. The same object grows one layer per chapter; it is not re-invented each time.

Research roots

This book uses research taxonomies as a foundation but adapts them for systems engineering. The goal is not to replace established terminology; it is to make the distinctions operational enough that later chapters can attach measurements and policies to them.

1. Ziwei Ji, Nayeon Lee, Rita Frieske, Tiezheng Yu, Dan Su, Yan Xu, Etsuko Ishii, Yejin Bang, Andrea Madotto and Pascale Fung, “Survey of Hallucination in Natural Language Generation,” ACM Computing Surveys 55(12), 2023. The survey formalizes the widely used intrinsic/extrinsic distinction: contradiction with source content versus information that cannot be verified from the source. https://doi.org/10.1145/3571730

2. Lei Huang, Weijiang Yu, Weitao Ma, Weihong Zhong, Zhangyin Feng, Haotian Wang, Qianglong Chen, Weihua Peng, Xiaocheng Feng, Bing Qin and Ting Liu, “A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions,” ACM Transactions on Information Systems 43(2), 2025. The survey distinguishes factuality hallucination from faithfulness hallucination and subdivides faithfulness into instruction, context and logical inconsistency. https://doi.org/10.1145/3703155

3. OpenAI, “GPT-5 System Card,” August 2025. OpenAI’s factuality evaluation separates long-form responses into factual claims, fact-checks claims individually with browsing-enabled graders, and reports both claim-level errors and response-level major-error rates. https://deploymentsafety.openai.com/gpt-5

4. Anthropic, “Claude Mythos Preview System Card,” April 7, 2026. The input-hallucination evaluations distinguish fabricated capabilities or tool observations from missing-context hallucinations such as nonexistent attachments and prior conversation turns. https://www-cdn.anthropic.com/53566bf5440a10affd749724787c8913a2ae0841.pdf

Next: Evidence, Truth, and Verifiability

We now have a schema for describing failure, but nearly every branch hides the same word:

evidence.

A factual claim needs evidence about the world.

A summary needs evidence from its source.

An attribution needs evidence that a particular source supports a particular claim.

A tool claim needs evidence in the execution trace.

An abstention decision needs evidence that the system knows enough to answer.

But evidence is not the same as truth, and support is not the same as publishability.

The next chapter separates those concepts before we attempt to measure any of them.

Before we can measure whether a claim is grounded, we have to decide what counts as ground.