Build an Evidence Table From Sources With AI
Ask AI to "summarize these sources and list the findings" and one interview becomes "customers," a real disagreement disappears, and no claim shows its source. Build an evidence table instead: one row per claim, with its source, exact quote, and how strong the support really is.
Build the Evidence-Table PromptThe summary that hides where every claim came from
You hand the AI three interview excerpts — or three policy sections, or a stack of research notes — and ask it to summarize them and give you the key findings. Back comes a clean line: "Customers find onboarding easy but want better reporting and clearer pricing." It reads like a finding. But you can't see which interview said onboarding was easy — maybe only one did. You can't tell whether "better reporting" was a real pattern or a single offhand remark, or whether two sources actually disagreed and the model quietly split the difference. The claims and their evidence have been welded together into prose, and to check any one of them you'd have to go back and reread all three sources yourself — which is exactly the work you were trying to skip.
The fix is to put a step between the sources and the summary. Before you let the AI write findings, make it build an evidence table: one row per claim or finding, each carrying the source it came from, the exact quote behind it, where in the source that quote lives, whether the claim is directly supported, single-source, conflicting, or unsupported, and whether it's cleared to enter the final answer at all. The table isn't the answer — it's the working layer where every claim is reviewable before it hardens into a sentence you'd stake something on. This guide is how to build an evidence table from sources with AI. NewPrompt's Markdown Output Builder does the central job here: it builds a prompt that makes the model return that table in a fixed set of columns instead of free-form prose. The real limit: NewPrompt gives you the prompt and the structure; you run it on your own sources in your own AI tool, and it doesn't upload, parse, or fact-check those sources — an evidence table makes the claims easy to check, it doesn't check them for you.
Why a direct summary buries its own evidence
When you ask for findings directly, the model optimizes for a fluent, confident summary — and fluency and evidence pull in opposite directions. A good summary reads smoothly, which means it hides the joins: which source, how many sources, how strong. The model isn't lying; it's compressing, and compression is what erases attribution. Here is how the evidence goes missing:
- One source becomes "customers." A single interview saying onboarding was easy turns into "customers find onboarding easy," and a sample of one is now phrased like a consensus.
- Conflicts get averaged, not shown. Two sources disagree about reporting; the summary picks the middle or the louder one, and the disagreement — often the most useful thing in the pile — disappears.
- The quote vanishes behind the paraphrase. "Wants better reporting" might be the model's gloss on "reports are fine for now" — but you can't tell, because the actual words aren't in front of you.
- Inference wears the costume of fact. The model's reasonable guess ("they'd probably pay more for this") sits in the same sentence as things a source literally said, with nothing marking the difference.
- Unsupported claims ride along. A plausible-sounding point no source actually made gets included because it fits the narrative, and nothing flags that it has no evidence behind it.
- There's no way to review without rereading. Because no claim carries its source, checking the summary means going back to the raw sources one by one — so most people don't, and the smooth version quietly becomes the record.
Step 1: Package the sources so each stays labeled and quotable
Before the table, the sources have to arrive in a shape the model can attribute. Dumped together as one blob, they blur — the model can't cite Source B for a claim if it can't tell where Source A ended. So label each source, keep them separated, and give the model a rule that every claim has to name its source and, where wording matters, quote it. Assign each source a stable id (Source A, Source B, or the real filename), and if the sources have sections or paragraphs worth citing, keep those visible so a row can point at a location, not just a document.
The Long Input Formatter does this packaging deterministically: it wraps your material in explicit delimiters, adds citable section labels, and attaches grounding rules that keep the sources separate — so when a table row later cites a section marker, it's pointing at something real. The Package Research Material resource is a worked example of the same setup: several sources loaded so findings stay attributed — exact quotes preferred over paraphrase, a citation per claim, disagreements reported rather than resolved, and your own inferences labeled as yours. Both give you a packaged prompt you run in your own AI tool; they organize the sources for citation, they don't check whether the sources are right.
Step 2: Ask for the table before the findings — one row per claim
The core move is a sequencing rule: no findings until the table exists. Tell the model, in the prompt, that its first job is not to summarize but to build an evidence table — one row per claim or finding — and that it must not write the narrative summary yet. Define the columns so every row carries its evidence: the claim, its type (a direct fact, a pattern across sources, an inference, a conflict, or unsupported), the source id, the exact quote, the location, a support status, an interpretation note, and whether the claim is allowed in the final answer. The support status is the column that does the work — directly_supported, partially_supported, single_source, conflicting, unsupported, needs_review — because it's where the model has to commit to how strong each claim actually is instead of hiding that in prose.
Getting the same set of columns back is exactly what the Markdown Output Builder is for: it builds a prompt that pins the output to a table with the columns you define, so the evidence table doesn't come back as a paragraph on one run and a loose bullet list the next. You describe the columns and the rules once; it assembles the prompt, and you run it on your packaged sources in your own AI tool — it shapes what the model returns, it doesn't produce the table itself.
Step 3: Keep the exact quote separate from the paraphrase and the inference
The single most important rule in the table is the wall between three things a summary usually blends: what a source literally said (the exact quote), how you'd restate it (paraphrase), and what you conclude from it (inference). Require the exact_quote column to hold verbatim source wording — the model's own words never go there — and put any restatement or conclusion in the interpretation_note column, explicitly marked as interpretation, not source. This is what lets you audit a row in seconds: you read the quote, then read the claim, and decide for yourself whether the claim is actually what the quote supports. A claim whose quote doesn't back it is the most common problem an evidence table surfaces, and you can only spot it when the two live in different columns.
The discipline here is the one the Stop AI Summaries from Making Things Up resource demonstrates for summaries: a fidelity battery that bans invention and unsupported inference, preserves numbers and names exactly as written, and refuses to fill a gap with plausible context. Applied to the table, those rules keep the exact_quote column trustworthy — no smoothing, no paraphrase creep, no numbers quietly rounded — so the evidence a claim rests on is the real evidence, not a tidied version of it. The resource is a template you adapt to your own sources.
Step 4: Give conflicts and gaps their own rows — don't let them resolve silently
A summary's instinct is to make the sources agree; an evidence table's job is to show where they don't. Tell the model that when two sources disagree it must not pick a winner or average them — it creates a conflict row that cites both, with both quotes, marked conflicting, and it writes the open question the conflict raises rather than answering it. Reporting "reporting is too limited" (Source B) next to "reports are enough for us" (Source C) as a single conflicting row, with the review question "is this segment-specific?", is far more useful than a bland "reporting is a mixed bag" or a confident pick of one side. The conflict is often the finding.
The same rule covers what's missing. When a claim has no quote behind it — the model inferred it, or it simply sounds right — it goes in as unsupported, and the allowed_in_final column reads no. When a claim needs a source you haven't provided, it's marked needs_review instead of being quietly dropped or quietly asserted. And a location the model can't actually find is not invented: an evidence table is worthless if the model fabricates a line number to fill the cell, so the rule is to leave the location blank and flag it, never guess. Making gaps and conflicts visible as their own rows is the whole point — they're the things a smooth summary is built to hide.
Step 5: Gate what reaches the final answer — then review the table against the sources
The allowed_in_final column is the gate between the table and the answer, and the rule is strict: a claim marked unsupported does not go into the final summary, full stop; a single_source claim can go in only if it's framed as single-source ("one of three interviewees found onboarding easy," not "customers found onboarding easy"); a conflicting claim goes in only as the conflict, never as a resolved fact; and anything marked needs_review waits for you. This turns "should this be in the findings?" from a judgment the model makes invisibly into a column you can scan, so the final answer is built only from claims that earned their place.
Then you review — because a candidate evidence table is a draft, not a verdict, and it's the evidence layer you're checking here, not a finished prose answer. Read down the exact_quote column against the actual sources: did the model quote accurately, attribute to the right source, mark the support status honestly, catch the conflicts? The AI can misquote, mis-attribute, or call something directly_supported that its own quote only partially backs, and it's your read of the sources that catches that. NewPrompt gives you the prompt and the order; running it, checking the quotes, and deciding which claims are solid enough to build on happen on your side. The AI Research Synthesis Workflow is the larger process this table lives inside — package the sources kept separate, summarize each faithfully, then synthesize across them with each point traced to a source — a prompt sequence you run yourself, where the evidence table is the reviewable layer you build before you trust any synthesis. And for high-stakes material — legal, medical, financial, policy, security, compliance — the table organizes the evidence for review; it doesn't replace the domain expert who has to sign off on it.
Common mistakes
The habits that let the evidence slip back out of an evidence table:
- Letting the model write findings first. If the summary comes before the table, the table becomes a justification for conclusions already drawn — demand the table first, and the findings only from it.
- Allowing the model's words into the quote column. The exact_quote column must be verbatim source text; the moment a paraphrase lands there, the audit trail breaks and you can't tell the claim from its evidence.
- Treating single-source as consensus. One interview is one data point; if a claim rides on a single source, it has to be labeled that way in the answer, not promoted to "customers" or "users."
- Letting conflicts resolve into an average. Two sources disagreeing is a finding; a model that quietly splits the difference has deleted it — make disagreement its own row with both citations.
- Accepting an invented location. A fabricated line number or section is worse than a blank one; require the model to leave the cell empty and flag it rather than guess.
- Trusting the table without reading the sources. The table makes claims checkable, but it doesn't check them — NewPrompt doesn't fact-check or verify your sources, and a plausible table can still misquote or mis-attribute until you read it against the originals.
A worked example: three customer interviews, evidence-first
Watch a one-line "summarize and list the findings" flatten three interviews into a false consensus, then an evidence-table-first prompt pull the same material apart into claims you can actually check.
A one-line "summarize and list the findings" flattens three interviews into a false consensus ("customers" drawn from one source, a real disagreement averaged away); an evidence-table-first prompt returns one row per claim with source id, exact quote, support status, and an allowed-in-final gate — a candidate table you check against the sources before any finding is writtenTHE SOURCES:
Source A, Source B, Source C -- three customer interview excerpts.
THE WEAK ASK, AND WHAT IT GIVES BACK:
ask: "Summarize these interviews and list the top findings."
answer: "Customers find onboarding easy but want better reporting
and clearer pricing."
why it hides the evidence:
- "customers" -- but only Source A mentioned onboarding
- reporting: Source B and Source C disagree; averaged away
- pricing came from one interview, phrased as a general finding
- no quotes, no source ids, no sense of how strong any claim is
AN EVIDENCE-TABLE-FIRST PROMPT:
Before writing any findings, build an evidence table -- one row per
claim. Do not write the summary yet.
Sources: Source A, Source B, Source C (kept separate, cited by id).
Columns:
claim | claim_type (direct_fact | pattern | inference | conflict |
unsupported) | source_id | exact_quote | source_location |
support_status (directly_supported | partially_supported |
single_source | conflicting | unsupported | needs_review) |
interpretation_note | allowed_in_final (yes | no | needs_review)
| review_question
Rules:
- exact_quote is verbatim source text only; never your paraphrase.
- Do not merge sources into a consensus unless two or more support
the same claim.
- If sources disagree, make one conflicting row that cites both.
- A claim with no quote is unsupported; allowed_in_final = no.
- Never invent a source_location; leave it blank and flag it.
PART OF THE TABLE THAT COMES BACK (a candidate you review):
claim: one customer found onboarding easy
source_id: A
exact_quote: "Setup was straightforward once the template loaded."
support_status: single_source
allowed_in_final: needs_review
note: cannot say "customers found onboarding easy" -- n=1
claim: reporting needs differ across customers
source_id: B, C
exact_quote: B: "Reporting is too limited."
C: "Reports are enough for us right now."
support_status: conflicting
allowed_in_final: yes, as a conflict only
review_question: is reporting a segment-specific need?
claim: customers want clearer pricing
source_id: C
support_status: single_source
allowed_in_final: needs_review
note: one source; do not present as a broad finding
NEXT: you read each exact_quote against the real interview, confirm the
support_status is honest, and decide which rows are solid enough to
become findings -- the summary is built from the table, not before it.Where this fits in NewPrompt
Building an evidence table is a structuring job, and NewPrompt gives you the pieces for it, not a source-checking service. The Markdown Output Builder pins the table to a fixed set of columns so it doesn't drift into free-form prose; the Long Input Formatter packages your sources with delimiters and citable labels so each claim can point at a real location; the Package Research Material resource shows the same source-attribution discipline on a worked multi-source example; and the Stop AI Summaries from Making Things Up resource supplies the fidelity rules that keep the quote column trustworthy. Each builds a prompt or packaged input you run in your own AI tool; none reads, uploads, or verifies your sources.
This guide sits next to the other source-handling guides as the one about the working layer before the answer. Making AI cite the source line for every claim adds a citation to each line of a finished answer; this builds the reviewable table before the answer exists, so the citations aren't retrofitted onto conclusions already written. Stopping AI from mixing facts from different sources is the attribution rule this table depends on — keep the sources separate, and the evidence table has clean ids to work with. And reviewing AI output against a source document checks an existing draft against its source after the fact; here you build the claim-by-claim evidence up front, so there's less to catch later. The through-line: get the evidence visible and checkable before it sets into an answer you'd act on.
An evidence table is closer to a lab notebook than a report. A report states conclusions; a notebook records what was observed, where, and how confident you were — so that anyone, including you next month, can retrace the reasoning and challenge a specific step instead of the whole story. Writing the findings first and citing later is writing the report before the notebook: the conclusions look authoritative precisely because the messy evidence that would let you question them has been cleaned away. The AI is genuinely good at the notebook work — pulling the quote, tagging the source, flagging the single-source claim — faster than you'd do it by hand. But which claims are solid, which conflict matters, and what the sources actually add up to is a reading you do yourself, against the real sources. The table lays the evidence out where you can see it; it doesn't tell you what's true.