How to Build a Claim-to-Source Table Before Asking AI to Write a Report
Summary
- A claim-to-source table is a structured way to tie every report statement to a specific source location before you ask AI to draft.
- Separate what the source literally says (original text) from your paraphrase, your interpretation, and your final report-ready claim.
- Track verification status per claim so you do not mix confirmed facts with assumptions, estimates, or open questions.
- Use a consistent record format (one row per claim) so you can audit, revise, and reuse evidence without re-reading everything.
- A worked example shows how to build the table, then convert it into an AI prompt that stays grounded in your sources.
When you ask AI to write a report, the fastest way to end up with shaky statements is to start drafting before you have a clean map from claims to exact source locations. A claim-to-source table solves that: it forces you to decide what you can actually support, what needs verification, and what is interpretation.
This article walks you through the evidence-handling task step by step, with a worked example and a reusable table format you can copy into a spreadsheet or document. The goal is simple: every sentence in the final report should be traceable to a source (or clearly marked as interpretation or unknown).
What a claim-to-source table is (and why you build it before drafting)
A claim-to-source table is a structured inventory of the statements you plan to make in a report, paired with:
- Where the support comes from (source name + exact location such as page/section/paragraph/timecode).
- What the source literally says (original text excerpt, copied exactly).
- Your paraphrase (same meaning, rewritten).
- Your interpretation (what you think it implies, with assumptions made explicit).
- Verification status (confirmed, needs verification, contradicted, etc.).
Building this table first helps you:
- Prevent accidental quote invention or “source drift” (where a paraphrase slowly becomes a stronger claim than the source supports).
- Keep AI drafting grounded: you can instruct the model to use only the table rows marked verified.
- Spot gaps early (missing citations, conflicting sources, unclear definitions).
- Speed up review: reviewers can check the table instead of re-reading the entire source set.
The four layers you must keep separate
Many evidence problems happen because these layers get blended. Your table should keep them distinct.
1) Original text (verbatim excerpt)
What it is: The exact words from the source, copied without changes.
Rules: Use quotation marks in your table, preserve punctuation, and include enough surrounding context to avoid misleading snippets.
2) Paraphrase (same meaning, new wording)
What it is: A rewrite that keeps the meaning and scope the same.
Common failure mode: Paraphrase becomes stronger than the original (adds certainty, adds numbers, adds causality, adds universality).
3) Interpretation (your reasoning)
What it is: Your analysis of what the excerpt implies, including assumptions and domain reasoning.
Rule: Interpretations can be useful, but they are not “what the source says.” They should be labeled as such.
4) Verification status (what you can safely claim)
What it is: A per-claim label that tells you whether the claim is supported by the cited source(s) as written.
Rule: Verification status is about the claim, not about whether the source is “good.” Even a credible source may not support a specific claim you want to make.
A reusable claim-to-source record format (copy/paste template)
You can implement this as a spreadsheet, a database table, or a document table. The key is consistency: one row per claim.
| Field | What to put here | Why it matters |
|---|---|---|
| Claim ID | Unique ID (e.g., C-001) | Makes it easy to reference claims in drafts and reviews. |
| Report section | Where it will appear (e.g., “Findings: Performance”) | Helps you assemble the report later. |
| Draft claim (report-ready) | The sentence you want in the report | This is what must be supported (or explicitly labeled as interpretation). |
| Claim type | Fact / Definition / Quantitative / Quote / Interpretation / Recommendation | Different claim types need different evidence standards. |
| Source | Document name, URL, interview name, dataset name | Identifies where support comes from. |
| Exact location | Page, section heading, paragraph number, timestamp, row/column | Lets someone else verify quickly. |
| Original text (verbatim) | Exact excerpt in quotes | Prevents accidental invention and scope creep. |
| Paraphrase | Your rewrite with same meaning | Useful for drafting while staying faithful. |
| Interpretation / notes | Your reasoning, assumptions, caveats | Keeps analysis separate from what was stated. |
| Verification status | Verified / Partially verified / Needs verification / Contradicted / Out of scope | Controls what AI is allowed to use as “fact.” |
| Confidence | High / Medium / Low (your internal rating) | Helps prioritize review time. |
| Follow-up needed | What to check next (e.g., “Find primary source for metric”) | Turns gaps into an action list. |
Verification statuses that work in real reporting
Pick a small set of statuses and use them consistently. Here is a practical set that covers most workflows:
- Verified: The source directly supports the claim as written.
- Partially verified: The source supports part of the claim, but not all of it (scope, timeframe, population, or causality differs).
- Needs verification: You have a plausible claim, but no supporting source excerpt yet.
- Contradicted: Another source conflicts with this claim (record both).
- Out of scope: The source is real but does not address the claim you are making.
Keep “Verified” strict. If you allow “Verified” to include interpretation, your table stops protecting you.
Worked example: building a claim-to-source table from two short sources
Below is a fully self-contained example using two fictional internal sources. The point is to demonstrate the method, not to provide real-world facts.
Example sources (fictional)
- Source A: “Q2 Support Summary” (internal memo), Section 2 “Response times,” paragraph 3.
- Source B: “Incident Log Export” (CSV), filtered to April-June, column “Severity,” column “ResolutionHours.”
Example excerpts (verbatim)
- Source A excerpt: “Median first response time decreased from 9 hours in April to 6 hours in June.”
- Source A excerpt: “We introduced a new on-call rotation on May 15.”
- Source B excerpt (derived observation you can reproduce): “In the filtered dataset, the median ResolutionHours for Severity=High is 14.”
Notice that Source B’s “excerpt” is not a quote from prose; it is a reproducible calculation. In your table, you can treat that as evidence if you record the exact filter and computation steps.
Claim-to-source table (worked rows)
| Claim ID | Draft claim (report-ready) | Source | Exact location | Original text (verbatim) / reproducible evidence | Paraphrase | Interpretation / notes | Verification status |
|---|---|---|---|---|---|---|---|
| C-001 | Median first response time fell from 9 hours in April to 6 hours in June. | Q2 Support Summary | Section 2, para 3 | "Median first response time decreased from 9 hours in April to 6 hours in June." | The median first response time improved by 3 hours from April to June. | Keep units (hours) and months (April, June) unchanged. Do not generalize beyond median first response time. | Verified |
| C-002 | The team introduced a new on-call rotation on May 15. | Q2 Support Summary | Section 2, para 4 | "We introduced a new on-call rotation on May 15." | A new on-call rotation started on May 15. | This is a factual event claim. It does not say anything about impact. | Verified |
| C-003 | The on-call rotation caused the response-time improvement. | Q2 Support Summary | Section 2, paras 3-4 | "Median first response time decreased from 9 hours in April to 6 hours in June." + "We introduced a new on-call rotation on May 15." | Response times improved after the on-call change. | This is a causality claim. The source shows timing, not causation. If you want to keep it, rewrite as correlation/sequence or add stronger evidence (experiment, analysis, explicit statement). | Partially verified |
| C-004 | In Q2, high-severity incidents had a median resolution time of 14 hours. | Incident Log Export (CSV) | Filter: Date=Apr-Jun; Severity=High; Metric: median(ResolutionHours) | Reproducible calculation: median ResolutionHours (Severity=High, Apr-Jun) = 14. | The median time to resolve high-severity incidents in Q2 was 14 hours. | Record the exact filter and calculation steps so another person can reproduce it. If the dataset changes, the number may change. | Verified |
| C-005 | Customers were more satisfied in June than April. | (none yet) | (n/a) | (no excerpt recorded) | Satisfaction improved from April to June. | This needs a defined metric (CSAT, NPS, survey) and a source. Do not include in the report until supported. | Needs verification |
How to turn the table into an AI-safe drafting workflow
Once you have your table, you can ask AI to draft without letting it “fill in” missing evidence. The trick is to constrain the model to the verified rows and to require it to preserve scope.
Step 1: Decide what AI is allowed to treat as fact
Common rule sets:
- Strict: AI may use only rows marked Verified as factual statements.
- Flexible: AI may use Partially verified rows only if it rewrites them to match what is supported (for example, changing “caused” to “followed” or “may have contributed”).
- Excluded: AI must not include Needs verification claims in the draft.
Step 2: Provide the table content in a structured way
You can paste the table rows into your prompt as a list of claim records. Keep each record compact and consistent. Example (based on the worked table above):
Drafting input (example format):
- C-001 (Verified): Claim: Median first response time fell from 9 hours in April to 6 hours in June. Evidence: "Median first response time decreased from 9 hours in April to 6 hours in June." (Q2 Support Summary, Section 2, para 3)
- C-002 (Verified): Claim: The team introduced a new on-call rotation on May 15. Evidence: "We introduced a new on-call rotation on May 15." (Q2 Support Summary, Section 2, para 4)
- C-004 (Verified): Claim: In Q2, high-severity incidents had a median resolution time of 14 hours. Evidence: median(ResolutionHours) with filter Date=Apr-Jun and Severity=High equals 14. (Incident Log Export CSV)
- C-003 (Partially verified): Claim idea: On-call rotation caused response-time improvement. Constraint: do not claim causation; only describe timing unless stronger evidence is provided.
- C-005 (Needs verification): Do not include in draft.
Step 3: Use a drafting prompt that enforces boundaries
Here is a reusable prompt you can adapt. It is designed to reduce invented details and keep the draft aligned to your evidence.
Reusable AI drafting prompt (template):
Write a report with sections: Executive Summary, Key Findings, Evidence Notes, and Open Questions.
Use ONLY claims marked "Verified" as factual statements. For "Partially verified" items, rewrite them so they match what the evidence supports (no causation unless explicitly supported). Do NOT include any "Needs verification" items in the report body; list them only under "Open Questions".
Do not invent quotes, numbers, dates, or sources. If a detail is not in the evidence, omit it.
After each factual sentence, add a parenthetical citation in the format (Source, location, Claim ID).
Evidence records:
[PASTE CLAIM RECORDS HERE]
Practical checks that prevent subtle evidence errors
Check 1: Scope match (who/what/when)
Before marking a claim verified, confirm the claim matches the source on:
- Population: Which users, customers, systems, regions?
- Timeframe: Which dates or period?
- Metric definition: Median vs mean, first response vs resolution, etc.
- Conditions: Severity levels, product versions, inclusion/exclusion rules.
Check 2: Causality vs sequence
If the source only shows that two things happened around the same time, your verified claim should reflect sequence, not causation. If you need causation, record what would count as stronger evidence (controlled test, explicit analysis, or a source that directly states the causal link).
Check 3: Quote integrity
If you plan to use direct quotes in the report, store them in the table exactly as written. If you shorten a quote, note what you removed so you do not change meaning.
Check 4: Conflicts and contradictions
If two sources disagree, do not “average” them into a new claim. Create two rows, mark them as contradicted, and add a follow-up row describing what would resolve the conflict (newer data, primary source, clarified definitions).
How to keep the table reusable across drafts and stakeholders
A claim-to-source table becomes more valuable when it can survive multiple report versions. A few habits help:
- Use stable source names: “Policy v3.2 PDF” is more stable than “that PDF from Slack.”
- Record locations precisely: Page + section + paragraph beats page alone.
- Keep one claim per row: If a sentence contains two facts, split it into two rows so each can be verified independently.
- Track revisions: When a claim changes, update the row rather than creating a new unlinked version (or add a “supersedes” note).
Common pitfalls (and how the table prevents them)
- Pitfall: “AI will cite sources for me.”
Fix: Provide the citations and excerpts in the table; require the model to cite Claim IDs and locations. - Pitfall: Paraphrases that add certainty.
Fix: Keep the original excerpt next to the paraphrase and review for added words like “proves,” “always,” “caused,” or “best.” - Pitfall: Mixing analysis into facts.
Fix: Put analysis in the interpretation column and label it clearly. - Pitfall: Using a metric without a definition.
Fix: Add a “metric definition” note or a separate claim row that defines the metric from a source. - Pitfall: Losing track of what still needs verification.
Fix: Filter the table by “Needs verification” and treat it as your research to-do list.
Frequently Asked Questions
FAQ 1: What is the difference between a claim-to-source table and a bibliography?
Answer: A bibliography lists what you consulted. A claim-to-source table maps each report statement to the specific source location and excerpt that supports it, plus your paraphrase, interpretation, and verification status. It is designed for traceability at the sentence level, not just source listing.
Takeaway: A bibliography tells you what exists; a claim-to-source table tells you what supports each claim.
FAQ 2: How detailed should the “exact location” be?
Answer: Detailed enough that another person can find the supporting passage quickly without re-reading the whole source. For PDFs, that can be page + section heading + paragraph number. For web pages, use the page title plus the section heading. For interviews, use timestamp ranges. For datasets, record the filter and calculation steps.
Takeaway: Aim for “findable in under a minute.”
FAQ 3: Should I store full quotes in the table or just short excerpts?
Answer: Store the smallest excerpt that still preserves meaning and context. If a short snippet could be misread, include the surrounding sentence(s). If you plan to use a direct quote in the report, store it exactly as written so you do not accidentally change wording later.
Takeaway: Keep excerpts short, but not so short that they become misleading.
FAQ 4: How do I handle quantitative claims from spreadsheets or databases?
Answer: Treat the “evidence” as a reproducible computation rather than a prose quote. In the table, record the dataset name/version, the exact filters (date range, segments), the metric definition (median vs mean), and the calculation method. If possible, store the query or formula used so someone else can reproduce the number.
Takeaway: For numbers, reproducibility is your citation.
FAQ 5: What should I do when two sources contradict each other?
Answer: Create separate rows for each conflicting claim, cite each source precisely, and mark them as contradicted. Add a follow-up row describing what would resolve the conflict (newer data, primary source, clarified definitions, or a reconciliation analysis). Avoid merging them into a single “compromise” claim unless you have evidence that supports the merged statement.
Takeaway: Record contradictions explicitly instead of smoothing them over.
FAQ 6: How do I label interpretation so it does not get mistaken for fact?
Answer: Put interpretation in its own column and use explicit language like “This may indicate…” or “One possible explanation is…,” followed by the assumptions you are making. Keep the report-ready factual claim separate, and only mark it verified if the source directly supports it without relying on your assumptions.
Takeaway: Separate columns plus explicit wording keeps analysis from masquerading as evidence.
FAQ 7: Can I ask AI to draft if some claims are still “Needs verification”?
Answer: Yes, if you constrain the drafting. In your prompt, instruct the model to use only verified claims as facts and to list “Needs verification” items only under an “Open Questions” or “To verify” section. This lets you move forward on structure and wording without accidentally publishing unsupported statements.
Takeaway: Drafting can start early if your prompt rules prevent unsupported claims from entering the narrative.
FAQ 8: What is a good minimum set of columns if I need a lightweight table?
Answer: A practical minimum is: Claim ID, Draft claim, Source, Exact location, Original text (or reproducible calculation), Verification status, and Notes (for interpretation and follow-ups). If you have room for one more, add “Claim type” to prevent mixing facts, recommendations, and interpretations.
Takeaway: Keep it small, but never drop the verbatim/reproducible evidence field.