2.2 Hallucinations, Inconsistencies, and Bias

A hallucination is when Claude produces confident, plausible-looking content that is false or fabricated: an invented statistic, a made-up citation or subsection number, a non-existent source, a quote nobody ever said. The dangerous part isn't the fabrication itself — it's that a hallucination is stated with exactly the same fluent confidence as true content. Nothing about how it reads distinguishes it from a correct answer. You cannot tell a hallucination apart from a fact by tone, formatting, or how sure it sounds.

This is why the term "hallucination" is a slightly misleading name for what's actually happening. The model isn't malfunctioning or seeing something that isn't there in any dramatic sense — it's doing the same fluent, pattern-completing thing it always does, but in a spot where the pattern it completed doesn't correspond to a real fact. That's precisely why hallucinations are so hard to catch by reading alone: the generation process that produces a fabricated subsection number is the same process that produces a correct one. Catching the difference requires stepping outside the text itself and checking against something external.

Hallucinations are not spread evenly across an output — they concentrate in three predictable places, and knowing them tells you exactly where to spend your scrutiny.

• 1.Specific-looking details — numbers, dates, citations, legal subsections, URLs, quotes. Anything that sounds precise is easy to fabricate and easy to mistake for verified fact.
• 2.The edge of the model's knowledge — very recent events, niche internal facts, anything outside well-covered training data.
• 3.Long outputs — a single fabricated detail can hide among many correct ones, especially when a reviewer skims a long answer rather than checking it line by line.

Not every problem in an output is a hallucination, and recognizing which kind of "unexpected" you're looking at determines the correct response. A hallucination is a fabricated fact, citation, or quote that doesn't exist. An inconsistency is an internal contradiction — a total that doesn't match its line items, a recommendation that conflicts with an earlier statement in the same output. Bias is skewed framing, unrepresentative examples, or assumptions about people. All three are failures, but they call for different fixes: a hallucination needs external verification, an inconsistency needs an internal cross-check of the output against itself, and bias needs a review of framing and representativeness rather than a fact-check.

Getting the category right matters because the wrong fix wastes effort and leaves the real problem standing. If you treat a bias issue as if it were a hallucination, you'll go looking for an authoritative source to check a framing choice against — but there's no external fact to verify, because the underlying examples or numbers might all be individually true; the problem is which ones were chosen and how they were presented. Conversely, if you treat a hallucinated citation as a mere inconsistency, you'll cross-check it against the rest of the same document and find nothing wrong, because the fabrication is consistent with itself — it just doesn't correspond to anything real outside the document.

Anthropic's guidance on reducing hallucinations gives four techniques that lower the risk. First, ground the request in provided source material and ask Claude to answer only from it. Second, allow an "I don't know" exit so the model isn't pushed to guess when it lacks the answer. Third, ask for citations or quotes that can be traced back to the source. Fourth, cross-check specific claims against an authoritative source before relying on them.

Each technique targets a different point where fabrication creeps in. Grounding narrows what the model is allowed to draw from, so it has less room to reach for something invented. The "I don't know" exit removes the implicit pressure to always produce an answer — a model that believes it must respond with something specific will sometimes manufacture that something rather than admit a gap. Requesting traceable citations turns an unverifiable claim into a verifiable one, because now there's a specific quote or page to check rather than a vague assertion. And cross-checking is the backstop that catches whatever the first three didn't.

The word to hold onto is reduce, not eliminate. Even with grounding or retrieval-augmented generation (RAG) in place, the model can still misread or ignore the provided context and produce an unsupported claim. Grounding lowers the odds of fabrication; it does not guarantee correctness, which is exactly why the cross-check step remains necessary even after grounding is in place.

The hallucinations covered so far are fabricated facts. Capability hallucination is a fabricated event: Claude states, in confident past tense, that it already did something -- "I've emailed that to your team," "I've saved the file" -- when no such action took place. Inside claude.ai, everything Claude can act on is limited to the conversation itself, whatever tools have been connected, and whatever files were uploaded; anything beyond that boundary simply isn't something Claude can perform, no matter how naturally the request implied one.

This is the same fabrication pattern as any other hallucination -- confident and false -- just applied to a claimed action instead of a claimed fact. The confirming sentence reads exactly like a real confirmation would, which is what makes it worth treating as unverified until confirmed: check the sent folder, check the file exists, confirm the tool actually fired.

Here's where it gets easy to miss. Imagine Claude is connected to a support-ticket tool but not to the billing system, and it's asked to "review this refund request, update the ticket, and process the refund." A single confident reply comes back: "I've reviewed the request, marked the ticket resolved, and processed a $340 refund to the customer's card." Two of those three clauses are probably true -- the ticket tool exists and really did fire. The third is a capability hallucination, because no billing tool was ever connected. Read as one smooth paragraph, all three claims carry equal weight. Read clause by clause against the actual tool list, only two survive.

That last row matters more than it looks. In a single chat exchange, a capability hallucination is embarrassing but recoverable -- you check the sent folder, find nothing went out, and resend it yourself. In an agentic or tool-using workflow, where each step's claimed output feeds the next step's input, the same failure compounds instead of announcing itself. Say step 2 of a five-step pipeline hallucinates "file saved to /reports/q3.csv," and step 4 is told to open that path and summarize it. The breakdown doesn't surface as an obvious error message -- it surfaces as step 4 either failing in a confusing way or, worse, hallucinating again to paper over a missing file. Every individual claim along the way still reads exactly as confident as a true one, but now false claims have a chance to stack before any human looks at the finished output. That's why multi-step, tool-using workflows need a checkpoint after each claimed action, not only a final review at the end.