Grounded answer citations
Carry source identifiers through answer generation
Build citations from records owned by the application. Keep a generated answer from deciding which URLs or document versions count as its evidence.
In this article
Start with the evidence record
Before assembling a prompt, assign a request-local identifier to each passage. Store the identifier alongside the document key, immutable version where available, passage location and text supplied to the model. The reference needs to describe the evidence actually used, not whatever happens to be at the same URL later.
Keep access decisions separate from the citation label. A short label such as E3 is convenient for generation, but possession of that label must not grant access to a document. Resolve it within the answer request or an authorised answer record, never through an unrestricted global lookup.
A useful initial implementation can use a simple map. It does not require a separate evidence platform. The important property is that the application can distinguish known passages from identifiers the model invented or copied from document text.
Return claims in a constrained shape
Ask for a structured result that associates claims with evidence identifiers. Validate the shape before rendering. The schema should make missing references visible, while allowing the application to represent an answer that lacks sufficient evidence.
{
"claims": [{
"text": "Bookings above the policy threshold require approval.",
"evidenceIds": ["E3"]
}],
"unanswered": ["The supplied policy does not identify the current approver."]
}This is an illustrative contract, not a complete output-validation scheme. Check maximum lengths, list sizes and allowed fields as well. If a returned identifier is absent from the evidence map, reject or regenerate the affected result. Do not repair it by choosing a source with a similar title. That would manufacture an evidence relationship after the answer was written.
Separate reference validation from support review
First confirm that each identifier refers to a supplied passage. Then examine whether that passage supports the claim. These are different checks with different failure messages. An unknown identifier is an integrity problem. A known identifier attached to an overstatement is a grounding problem.
Start the support review with a small, manually reviewed set. Include negation, monetary limits, effective dates and exceptions. These examples expose mistakes that keyword overlap will miss. If an automated evaluator is added, compare its decisions with the reviewed set and retain a way to inspect disagreements.
Do not let a validation failure disappear into a generic success response. Return a limited answer, request more evidence or explain that the claim could not be checked. The correct behaviour depends on the product, but it should be an explicit choice.
Render references without trusting generated markup
Use normal application components to create links from the validated evidence map. Display model text as text unless the rendering path applies a deliberate, tested sanitisation policy. Generated HTML is not needed to produce useful citations.
Finally, exercise an answer end to end with a source that has multiple versions. Confirm that the displayed excerpt, reference target and recorded evidence all agree. Repeat with an unauthorised reader and with a deleted source. These checks reveal whether the implementation has preserved provenance or merely added numbered links to a paragraph.
Primary sources
Microsoft Learn: groundedness evaluationOWASP: authorisation guidanceReferences checked 11 September 2026.