Grounded answer citations

A citation can be real and still support the wrong claim

Linking to a genuine document does not prove an answer is correct. The evidence must support the particular claim, including its conditions and exceptions.

In this article

Check what the sentence actually says

Imagine an assistant answering a question about travel expenses. It says that every domestic flight can be booked without approval and cites the travel policy. The policy exists, the link opens and the document discusses domestic flights. It also says that only flights below a spending threshold qualify. The citation is real. The answer is still misleading.

This distinction matters because citation checks often stop at the easiest property to test: whether the source identifier appears in the retrieved material. That catches invented references, but it does not establish that the reference supports the words beside it. A system needs both reference integrity and claim support.

Treat a claim as a statement a reader might act on. A paragraph can contain several claims with different evidence. Combining a price, an eligibility condition and an approval rule under one reference makes it difficult to see which parts are justified.

Carry evidence through the pipeline

Give each retrieved passage an identifier created by the application. Keep its document version, location and access context outside the model's control. Ask the model to refer to those identifiers, then resolve them back to source links in application code. A model should not invent the URL used by the interface.

This design reduces reference errors without promising that every answer is grounded. The model can still attach the wrong passage to a claim. A separate check needs to compare the claim with the cited text, including surrounding conditions needed to interpret it.

A traceable answerApplication-owned evidence identifiers connect generated claims to the passages actually retrieved.
  1. RetrieveCapture passage, source version and location
  2. GenerateReturn claims with evidence identifiers
  3. CheckReject unknown references and inspect support
  4. PresentShow the supported claim beside an accessible source

Match the check to the consequence

For a low-risk discovery tool, showing the source excerpt and clearly separating unsupported suggestions may be sufficient. For a workflow that changes an entitlement or approves a payment, a plausible explanation should not become the authorisation mechanism. Use explicit business rules and the required approval process for that action.

An automated support evaluator can help identify contradictions and missing evidence. It is another model-based judgement, however, so measure it against reviewed examples before relying on its score. Include cases where the reference mentions the same subject but supports a narrower statement. Those are harder than entirely unrelated sources.

When the evidence is incomplete, the answer should say what remains unknown. Removing an unsupported qualification to make the prose sound confident defeats the purpose of the check. A shorter answer with a visible limitation is often more useful than a complete-looking answer that silently fills gaps.

Let readers inspect the evidence

Place the reference near the claim it supports. Open a relevant passage or page where possible, rather than sending the reader to the beginning of a long document. Show the source version or effective date when it affects interpretation.

Test the full reading path. Can an authorised user open the reference? Does the highlighted passage justify the statement? Does a later document revision change what the link displays? These questions connect citation quality to a reader's actual ability to verify the answer.

Primary sources

Microsoft Learn: groundedness evaluationMicrosoft Learn: document chunking approaches

References checked 11 September 2026.