Retrieval needs a source trail

Start with a question you can inspect

Imagine asking an internal assistant which policy applies to a refund. The answer sounds plausible, but the interface does not show the policy, its version, or the passage that supports the conclusion. The reader has no quick way to check it.

A useful retrieval interface should carry evidence through the entire request, from the selected documents to the displayed answer.

Keep a small evidence record

For each retrieved passage, store a document identifier, a section identifier, the source URL, and a revision or retrieval timestamp. Give the model short citation identifiers and retain the full mapping in application code. The UI can turn those identifiers into links without asking the model to invent URLs.

For a linked Markdown collection, the record could look like this:

{
  "source_id": "refund-policy",
  "section": "Exceptions",
  "revision": "2026-11-13",
  "citation": "S1"
}

Treat missing evidence as a result

If retrieval returns nothing useful, ask for clarification or say which information is missing. If two documents disagree, surface the conflict. More confident wording does not resolve an evidence gap.

Keep a few deliberately difficult questions in a small evaluation set: an answer absent from the documents, an outdated policy, two conflicting sections, and a question that needs several sources. Inspect which passages were selected before changing the model prompt.

Where this fits

This is a design pattern for systems such as the DataGraph project, where linked knowledge supports generated output. It is a proposed evaluation approach, not a claim of measured accuracy or a production benchmark.

Further reading

The W3C PROV overview explains provenance: recording the entities and processes behind information. A retrieval application can begin with a small source record without implementing the full PROV model.