Build an Evidence Table Before You Draft

A research assistant can return a polished brief that feels sourced and still leaves you unable to answer a basic question: where did this particular claim come from? Links at the bottom are not enough. A paragraph may blend a retrieved fact, a reasonable inference, and a made-up connective sentence until a reviewer has to redo the search to separate them.

The practical move is to build a small evidence table before synthesis. First retrieve material. Then turn only the passages you can point to into compact rows: the claim you intend to make, the exact supporting excerpt, the source, and any limit on what the excerpt proves. Draft from those rows rather than from an undifferentiated pile of documents.

This is a workflow choice, not a request to make the model “be more accurate.” Anthropic’s citations feature returns the passages supporting a response’s claims and identifies their locations in supplied documents.^[1] OpenAI’s file-search tool can retrieve from uploaded knowledge bases and return file citations in the model’s response.^[2] Those features are useful because they expose a handle for checking a statement. An evidence table makes that same handle part of your own process, whether or not a specific API feature is available.

Separate evidence, interpretation, and recommendation

Start by deciding what kind of sentence you are about to publish or act on. A direct fact needs a source passage. An interpretation should name the evidence it rests on and be labeled as an interpretation. A recommendation should explain the tradeoff or decision rule, rather than pretending the source made the decision for you.

For example, suppose you are writing an internal note about a product’s document-search behavior. “The tool can search uploaded files with semantic and keyword search” is a factual claim you can anchor to documentation. “It is a good fit for our compliance workflow” is your judgment, which needs the workflow’s constraints as well as the capability. “Pilot it with two document sets and compare review time” is a recommendation. All three can belong in the same brief, but only the first should be worded as something the source directly says.

This distinction prevents a common failure: a model finds a relevant fragment, then writes a broader conclusion than the fragment supports. A table makes the gap visible before fluent prose covers it up.

Copy this evidence-table template

Use one row per load-bearing claim. A spreadsheet, Markdown table, database record, or JSON object all work. Keep the excerpt short enough that a reviewer can read it without reopening the whole source.

QUESTION: [What decision or explanation is this brief for?]
AUDIENCE: [Who will use it, and what can they do with it?]

ROW ID: E-01
CLAIM: [One factual statement you expect to use]
SOURCE: [stable URL, document title, or file ID]
EXCERPT: [exact quote or tightly bounded retrieved passage]
LOCATION: [section, page, paragraph, or character range]
SUPPORTS: [the exact sentence or field this evidence can support]
LIMIT: [what this does NOT establish]
STATUS: verified | needs a second source | omit

DRAFTING RULES
- Write a factual sentence only when it maps to a verified row.
- Put the source link beside or immediately after the supported claim.
- Mark interpretations as interpretations; do not phrase them as source facts.
- If no row supports a useful claim, say what is unknown or remove it.
- Before publishing, sample each factual sentence and trace it back to one row.

The LIMIT column is the quiet safeguard. A vendor guide can establish that a feature exists; it usually cannot prove the feature is accurate enough for your use case, secure in every configuration, or cheaper than an alternative. Write that boundary while the source is open. It is much easier than reconstructing it after a draft has accumulated confident-sounding transitions.

Retrieve narrowly, then preserve the trail

Search with a question that would change the decision, not a vague request for “everything about” a topic. Save the URL or stable document ID, the document title, and the excerpt at the moment you retrieve it. Do not rely on a model’s later paraphrase to recover the location.

For file-based research, also preserve which version of the source you used. OpenAI’s documentation describes file search as operating over files uploaded to vector stores; a new upload or changed corpus can produce a different basis for a later answer.^[2] For supplied documents, Anthropic’s citation response can include source locations such as page, character, or content-block ranges depending on document type.^[1] Even if your tooling gives less detail, record the best available locator: page 7, a heading, or the original retrieval query.

Then draft in two passes. In pass one, turn verified rows into plain factual sentences with visible links. In pass two, add the interpretation, recommendation, and transitions—without quietly upgrading the evidence. If a transition adds a new factual assertion, it needs its own row.

Failure mode: collecting receipts after the conclusion

An evidence table can become theater when a team decides the answer first and hunts for supporting snippets afterward. It can also create false confidence when a quote is technically real but irrelevant, stale, or stripped of its qualifying context. Citations show provenance; they do not automatically prove that a conclusion follows.

Keep the table small, use primary material where possible, and read enough surrounding context to understand a quote. For high-stakes claims, add an independent source or a human reviewer. When evidence is mixed or missing, the honest output is a bounded uncertainty—not a source-shaped footnote attached to a guess.