# Plant a real citation beside an unsupported exception

A useful citation test uses a relevant source and a subtly wrong answer. This exposes failures that broken-link checks cannot find.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Build a small source with a clear rule

Create a synthetic policy containing a general rule and one exception. For example, equipment purchases below a stated amount may use a standard process, while restricted equipment always requires approval. Make the distinction unambiguous and keep the document short enough that a reviewer can verify the expected answer without interpretation.

Ask a question about restricted equipment below the amount. The correct answer needs both parts of the policy. A system that retrieves only the spending rule may produce a confident answer with a perfectly valid citation. That is the failure this test is designed to reveal.

Record the expected claims rather than a single exact response string. Wording can vary while meaning remains correct. The fixture should require the approval exception and prohibit the claim that low cost removes it.

## Introduce failures one boundary at a time

Run the question with the complete passage, then with the exception omitted by retrieval. These runs distinguish a generation failure from missing evidence. If the model overstates the rule despite receiving the exception, inspect the prompt and support check. If the exception never arrives, investigate extraction, chunking and retrieval.

Next, replace the reference identifier with an unknown value. The application should reject that reference independently of whether the answer text is sensible. Then attach the identifier of a real but unrelated passage. This should pass identifier validation and fail support review.

Keep these cases separate in the test report. A single overall pass rate can hide the fact that the system catches invented links but accepts unsupported claims attached to legitimate documents.

## Test the reader's route to the source

Open the citation as a user who can read the answer. Check that the destination contains the passage used during generation. A link to the latest policy may look healthy while presenting a different rule from the version recorded with the answer.

Repeat after revoking the user's source access. The expected behaviour should follow the product's access policy, including stored excerpts. A disabled link alone is not enough if the answer page still exposes the restricted passage.

Also test an unavailable source. The interface should distinguish temporary unavailability from missing evidence. Replacing the link with a different document because it has the same name can make an old answer appear verified against material it never used.

## Turn the failure into a durable fixture

Save the source versions, expected claims, retrieval output and validation decisions. Use identifiers for sensitive material rather than copying production documents into unrestricted test logs. Synthetic fixtures are usually enough to establish the mechanism.

A regression test should tell an engineer which boundary failed. Assertions such as "unknown evidence identifier rejected" and "restricted equipment exception preserved" are more actionable than "answer quality below threshold". Keep a few reviewed answer examples beside those assertions so changes to the evaluator can be judged against the same meaning.

## Sources

- [Microsoft Learn: groundedness evaluation](https://learn.microsoft.com/en-us/python/api/azure-ai-evaluation/azure.ai.evaluation.groundednessevaluator?view=azure-python)
- [OWASP: logging guidance](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)