Explainables
Judge

Grounding & Hallucination Indicators

system limitsprovenancecausal reasoninggenerative AI
User question

Can I trust what the system generated?

Consulting signal

Surfaces when a client's LLM-powered tool is being used in a domain where factual accuracy matters: legal, medical, compliance, research, and the team realizes there's no way to tell when the model has confabulated.

Overview

Why this pattern exists

A user asks an AI assistant a question. The answer comes back well-formatted, confidently stated, with a plausible citation. Some of it is accurate. Some of it is fabricated. From the interface, there is nothing to distinguish the two. The user acts on the answer.

This is the design problem: LLM-powered systems present accurate and inaccurate content identically. There is no visual or tonal signal that tells the user when the system is on solid ground versus when it is confabulating. Unlike a prediction model that can carry a confidence score, a language model does not have a meaningful probability attached to each factual claim: it generates text that sounds right, not text it has verified.

Grounding & Hallucination Indicators give the interface something it currently lacks: a visible signal of how well a response is anchored to real, retrievable information. This is not the same as Confidence & Uncertainty, which addresses statistical uncertainty in predictive models. That pattern applies when a risk score has an error band. This pattern applies when an AI-written sentence might simply not be true, and the interface needs to make that risk visible.

Design goal

Give users visible signals about the factual grounding of AI-generated content: distinguishing between responses that are well-supported by retrievable evidence and those that may contain fabricated, outdated, or unverifiable claims.

Usage guidance

When to use

  • The system uses a language model to generate free-text responses
  • The domain has material consequences for factual errors (medical, legal, financial, news, research)
  • The system retrieves sources at runtime (pair with Retrieved Source Attribution, pattern 21)
  • Users may not have the background knowledge to independently verify claims
  • The system may produce plausible-sounding but unverifiable content (dates, citations, names, statistics)

When not to use

  • The system is generating creative content where factuality is not the expectation (fiction, brainstorming)
  • The output is structured data with its own verification mechanism (e.g. form auto-fill confirmed by the user)
  • Adding verification signals would create false confidence in a verification process that doesn't actually exist: only show grounding indicators if they are backed by a real mechanism

Design

UI primitives

to be added soon
Inline Signal / Badge

Grounding status badge

A compact label attached to a response or section indicating its grounding state: - Grounded: claims verified against retrieved sources - Partially grounded: some claims supported, others not - Unverified: response generated without supporting source - Potentially outdated: sources retrieved are older than a threshold

to be added soon
Inline Signal / Marker

Claim-level verification markers

Inline highlights or markers on specific sentences or claims, not the entire response. Hallucination research distinguishes two types that warrant different visual treatments: - Intrinsic hallucination: the response contradicts a retrieved source. Higher severity; warrants a strong warning marker. - Extrinsic hallucination: the response contains claims that cannot be verified against any retrieved source, neither supported nor contradicted. Lower certainty; warrants an "unverified" marker rather than a contradiction warning. This distinction matters for design: a contradiction signal and an "unverifiable" signal look similar if treated identically, but carry very different implications for what the user should do next.

to be added soon
Inline Signal / Indicator

Confidence-grounding split

In systems that have both a retrieval step and a generation step, separating two signals: - Retrieval confidence: how well the sources matched the query - Generation faithfulness: how closely the output reflects what was retrieved These are different things and conflating them misleads users.

to be added soon
Contextual Overlay / State Display

I don't know design state

An explicit interface state for when the system has low grounding confidence and should say so, not produce a fluent but potentially wrong response. This is a product design decision, not just a model decision.

to be added soon
Contextual Overlay / Warning

Source mismatch warning

A visible warning when the generated response makes a claim that contradicts a retrieved source, or when the response contains specifics (dates, numbers, names) that don't appear in any retrieved document.

to be added soon
Inline Signal / Indicator

Recency indicator

For time-sensitive domains, a signal showing when the most recent supporting source was last updated: helping users assess whether the information is still current.

How to use

Don't use a single "confidence score" for grounding.

A 92% confidence score on a hallucinated response is meaningless and actively misleading. Grounding signals must be tied to a real external reference: a retrieved document, a verified database, a structured knowledge source.

Make the "unverified" state a first-class design state, not an error state.

Not all responses need to be grounded. But users need to know when they're not. An "unverified" badge is not a failure: it's honest design.

Distinguish fabrication risk by content type.

Specific claims carry different hallucination risk than general claims. Numbers, names, dates, citations, and statistics are the highest-risk content types in LLM output. Consider claim-level treatment for these specifically.

Don't add grounding indicators you can't back up.

A "verified" badge on a response that hasn't actually been verified against a source is worse than no badge at all. Only show this pattern if you have a real verification mechanism behind it.

Use progressive disclosure for detail.

Show a compact grounding state by default. Let users expand to see which specific claims are and aren't supported.

Use cases

flow a

High-stakes fact check

  1. 1. User asks a medical question.
  2. 2. System responds with a grounding badge: "Partially grounded: 2 of 4 claims verified."
  3. 3. User clicks the badge.
  4. 4. Panel expands showing which sentences are highlighted as verified (green) and which are unverified (amber).
  5. 5. User sees a warning: "The specific dosage mentioned could not be verified in retrieved sources."
  6. 6. User consults a verified reference or medical professional.
flow b

Citation check

  1. 1. User asks for a summary of a research area.
  2. 2. System produces a response with inline citation markers.
  3. 3. One citation is marked with a warning icon.
  4. 4. Tooltip: "This citation could not be verified in the retrieved documents. Check independently."
  5. 5. User removes the suspect citation from their own work.
flow c

"I don't know" state

  1. 1. User asks a highly specific question outside the system's knowledge scope.
  2. 2. System shows: "I couldn't find a reliable source to answer this. Here's what I do know: [general information]. For this specific question, please consult [recommended resource]."
  3. 3. User is not misled by a fluent but incorrect response.

Design trade-offs

Transparency vs. paralysis

If every response is covered in warning labels, users stop reading them. Reserve high-visibility grounding signals for genuinely uncertain or high-stakes content. Use progressive disclosure for detail.

Grounding vs. false assurance

A "grounded" badge can make users over-trust a response. Grounding means the output is consistent with a retrieved source: it doesn't mean the source itself is correct or current. Be precise about what grounding means in your specific system.

Flagging vs. refusal

Some systems respond to low grounding confidence by refusing to answer. Others respond by answering with a warning. Both are valid product decisions with different trade-offs for user experience and safety. Design the threshold deliberately.

Connections

Relation to other patterns

Attribution shows what was retrieved. Grounding signals how faithfully the output reflects it. These two patterns work together: attribution without grounding tells users the source but not whether it was accurately represented.

Sources

comprehensive taxonomy of hallucination types in NLP systems; distinguishes intrinsic hallucination (contradicts source) from extrinsic hallucination (unverifiable against source). Foundational for designing grounding signals at the claim level

decomposes generated text into atomic claims and evaluates each claim individually against a knowledge source, rather than scoring the response as a whole. Establishes the technical basis for claim-level grounding indicators rather than response-level confidence scores. Published at EMNLP 2023

introduces faithfulness as a measurable dimension separate from retrieval relevance. The faithfulness metric is the technical equivalent of what this pattern surfaces to users

Kroll et al. (2017) — Accountable Algorithms

while predating LLMs, establishes the accountability principle that systems making consequential decisions must be auditable and their reasoning examinable. Grounds the normative case for surfacing hallucination risk in high-stakes contexts