An AI hallucination is an output that presents incorrect or unsupported material as though it were reliable. NIST describes the related risk as confabulation: a generative system can confidently produce false content, including material that conflicts with its source. Fluent writing and a detailed citation are therefore not enough to establish that a claim is true.
This page explains how to recognise the verification task. Use the separate checking guide for the full review workflow. The goal here is to understand what kind of claim you are dealing with and what evidence would be needed before using it.
Confidence, detail and agreement are not source evidence
An answer can sound certain, contain a precise date and agree with another generated answer while still being wrong. Those features describe the response, not the evidence behind its claims. Asking for a confident tone or a second rewrite does not supply the missing source.
Treat a citation as a route to inspect, not a certificate. Open the original document, confirm that its title and author are real, and find the passage that supports the specific statement. If a system cannot access the document, it may still produce plausible-looking bibliographic details. Mark that reference as unverified rather than repairing it with another plausible title.
Separate the claim from the type of evidence it needs
A date, quotation, number, instruction and recommendation need different checks. For a date, identify the event and authoritative record. For a quotation, inspect the actual wording and context. For a number, check the unit, denominator, period and calculation. For software instructions, check the relevant product and version. For a recommendation, separate the underlying facts from the judgment about what to do.
Write a small claim list before searching. “This feature launched recently and doubles productivity” contains at least two claims with different evidence needs. You may be able to verify the release date while finding no support for the productivity statement. Do not let one accurate detail validate the entire sentence.
Unsupported, contradicted and uncertain are different findings
Unsupported means the material available to you does not establish the claim. Contradicted means a relevant source provides evidence against it. Uncertain means the information is incomplete or there is a genuine limitation you have not resolved. These are useful review labels for this guide; they are not a diagnostic test for the internal cause of a model’s output.
A statement that is absent from your notes might be true elsewhere. You still cannot attribute it to those notes. Conversely, a real document can contain a statement that is outdated for the task. Record exactly what you found and avoid turning “not checked” into either “definitely false” or “safe to publish.”
Prompting can organise a check, but it cannot guarantee truth
Ask the assistant to extract factual claims, keep source material separate from inference and state where evidence is missing. That can make a draft easier to review. It does not make every self-reported source label accurate, and it does not replace opening the actual references.
When you give a model source text, require it to identify the supporting passage for a claim. Compare its selection with the document yourself. When there is no support, remove the assertion, narrow it to what the source establishes or leave it explicitly unresolved. Do not repeatedly ask for a more persuasive answer to the same unsupported statement.
Make the verification record useful to the next reader
For each claim you keep, record the source location, what it supports, any relevant date or scope, and the reviewer’s decision. A link alone may not explain why the claim is justified. Someone checking a software instruction, for example, needs to know whether the source describes the same product version and workflow.
For consequential decisions, use the appropriate qualified person and authoritative material rather than treating an AI audit as approval. For ordinary drafting, a lightweight record can still prevent a convenient assumption from being repeated as a fact. The fictional case below demonstrates the record; it does not describe a real product.
Start with this workflow.
- Extract the factual claims
Separate dates, numbers, quotations, instructions and recommendations into checkable statements.
- Match each claim to evidence
Open the original source and compare its wording, scope and date with the statement.
- Record what survives the check
Keep supported claims, narrow overstatements and leave unresolved claims visibly unresolved.
WORKED EXAMPLE
One true date does not prove a performance claim
Fictional example: an AI draft says a note-taking feature launched in April and made every team twice as productive.
STARTING POINTThe draft gives a precise month and sounds professional, so keep the full sentence.
AFTER CHECKINGThe release note supports the April launch. It contains no measurement of team productivity. Keep the verified launch information with its source and remove the performance claim. If performance matters, define the measure and obtain relevant evidence separately.
What changed
The review treats two statements as two evidence tasks. It does not use the accuracy of the date to justify the unsupported result.
Make your own working brief.
Claim: Claim type: Original source and exact location: What the source actually supports: Relevant date, scope and units: Missing evidence or contradiction: Reviewer’s decision: Revised wording: What remains unresolved:
Further reading.
NIST supports the description of confabulation risk. The review labels, claim log and fictional release-note example are LifestyleGlide working tools, not a model reliability certification.
