# Source list > The answer drew on eight pages, and the viewer needs to judge those pages before trusting it. - Canonical: https://patterns.konigi.com/ai-assistants/source-list - Group: Grounding and disclosure - Level: implementation - Status: published - Updated: September 12, 2026 - Also called: references panel, sources rail, retrieved documents --- ## Problem An answer is only as good as what it was built from. The reader can judge a set of sources in about four seconds, far faster than they can fact-check a paragraph, but only if the sources are visible as a set rather than scattered through the prose one marker at a time. ## Solution Show the material the answer was assembled from as a list, with enough per row to judge it without clicking: title, domain, and date. Domain does most of the work. A reader distinguishes a standards body from a vendor blog from a forum post instantly, and that single judgement calibrates how they read everything below. Placement is the decision that separates the two schools. Putting the list after the answer treats it as a bibliography, consulted by the small fraction of readers who go looking. Putting it before the answer treats it as a premise, and every reader sees it. The second is stronger for anything factual, because calibration is only useful in advance. A reader who learns after the fact that the answer came from three SEO listicles has already absorbed it. The list has to be honest about a distinction the system knows and the interface usually hides: what was retrieved against what was used. A retrieval step may pull twenty candidates and the generation may draw on four. Showing all twenty pads the appearance of rigour with material the answer ignored. Showing four hides how much was rejected and how thin the basis actually was. Naming both counts is cheap and more truthful than either alone. Rows need states as much as content. A dead link, a paywall, a document the viewer lacks permission to open, and a source behind a login are all common, and all of them should be visible before the click rather than after. In an enterprise retrieval system the permission case is the sharp one: an answer built on a document the reader can't open is unverifiable by them specifically, and saying so is better than a link that fails. NN/g's finding about site chatbots applies to the whole list: people came for an answer—not for a reading assignment. Four to eight rows, compact, with the rest behind an expander. ## Use when The system retrieves before generating, whether from the web, an attached document, or an internal corpus. ## Don't use when The answer is generated from the viewer's own supplied text or from the model's parameters alone. A list of sources under a rewrite of the viewer's paragraph is theatre. ## Trade-offs Sources before the answer delay the thing people came for and make the product feel like a search engine, which is correct for an answer engine and wrong for an assistant drafting an email. Rich rows with snippets support judgement and take vertical space proportional to source count. Showing the full retrieved set is more honest and reads as noise. And the list creates an obligation: once a product displays its sources it'll be judged on their quality, which is a good pressure and a real cost. ## Checklist - Is the list visible before the answer is read, or only after? - Does each row carry a domain and a date without a click? - Can the reader tell what was retrieved against what was actually used? - Are paywalled, dead, and permission-restricted sources marked before the click? - How many rows show before an expander, and what's the ordering? - Does the ordering reflect how much each source contributed, or arrival order? - What does the list look like when retrieval returned nothing good? - Does the answer say when it went beyond its sources? - Is the list included when the answer is copied or shared? - Do the rows survive a narrow viewport without truncating the domain? ## Compare **Perplexity** puts the sources above the prose as a horizontal strip and treats them as the primary object. The answer reads as a synthesis of a visible corpus rather than an opinion with footnotes. **ChatGPT** attaches sources when a search ran and keeps them subordinate to the answer, preserving the assistant framing at the cost of later calibration. **Claude** surfaces project knowledge and attached documents as the basis, so the list describes a corpus the viewer assembled rather than one the system found. **Microsoft Copilot** lists internal files from the tenant, where a row's real information is often whether the reader can open it at all. ## Related Citation chip is the per-claim form and answers the narrower question. Tool call trace is the record of the retrieval that produced the list. Attachment tray is the viewer-supplied end of the same pipeline. Scoped context is what determines which corpus was searched. Reasoning disclosure covers the step between retrieving and writing. ## Related patterns - [Citation chip](https://patterns.konigi.com/ai-assistants/citation-chip) — A well-sourced paragraph and a fabricated one read identically until the viewer can see where each claim came from. - [Tool call trace](https://patterns.konigi.com/ai-assistants/tool-call-trace) — The assistant did something in the world, and the viewer only sees the sentence describing it afterwards. - [Attachment tray](https://patterns.konigi.com/ai-assistants/attachment-tray) — The viewer adds a file to the question and needs to see what the model will actually read. - [Scoped context](https://patterns.konigi.com/ai-assistants/scoped-context) — The assistant sits inside a product full of data and the viewer cannot tell how much of it is in scope. - [Reasoning disclosure](https://patterns.konigi.com/ai-assistants/reasoning-disclosure) — The model worked for thirty seconds and the viewer wants to know whether it understood the question. ## Sources - [Google PAIR, Explainability and Trust](https://pair.withgoogle.com/chapter/explainability-trust/) - [Nielsen Norman Group, Less Chat, More Answer](https://www.nngroup.com/articles/less-chat-more-answer/) - [Microsoft HAX Toolkit, Guideline 11, Make clear why the system did what it did](https://www.microsoft.com/en-us/haxtoolkit/guideline/make-clear-why-the-system-did-what-it-did/) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.