How to Build a Source-Linked Evidence Table for a Report

The table gives each evidence item a place in the workflow

Each row usually represents one evidence item. That item could come from an interview transcript, stakeholder submission, survey result, policy document, field note, case study, workshop record, administrative dataset or previous report.

The table can show:

• where the evidence came from
• the exact page, paragraph, row, timestamp or section
• the point the evidence supports
• the theme or subtheme it relates to
• the research question or evaluation question it answers
• the draft finding it supports
• the recommendation it informs
• the report section where it may be used

This is why the evidence table sits between data collection and report writing. It is close enough to the source material to preserve traceability, but structured enough for analysts, writers and reviewers to use.

The practical questions it should answer

In practical terms, a good evidence table helps a team answer four questions quickly:

• What evidence do we have for this claim?
• Where exactly did that evidence come from?
• Which evidence items support this finding?
• Where is this finding used in the report?

Without this working layer, teams often rebuild the evidence trail late in the process. That is slow, frustrating and risky, especially when the report is going to a donor, board, client, public body or steering committee.

The tools are connected, but they do different jobs

A source register tells the team what it has. A quote bank stores wording the team may want to use. A findings-to-recommendations matrix connects high-level findings to recommendations. A response matrix manages review comments or public consultation responses.

A source-linked evidence table shows how the material supports the report.

That difference matters. If a team tries to use a source register as an evidence table, the rows become too broad. If it tries to use a quote bank as an evidence table, the team stores excerpts without enough interpretation. If it jumps straight to a findings matrix, it can lose the smaller evidence records that explain how the finding was built.

Use it when memory is no longer a safe method

A source-linked evidence table becomes useful when the team has enough source material, reviewers or risk that memory is no longer a safe method.

This often applies to:

• evaluation reports
• donor reports
• situation analyses
• public consultation reports
• policy reviews
• white paper processes
• stakeholder submission analysis
• qualitative research synthesis
• mixed-method reports
• interview and case study analysis
• evidence reviews
• recommendation-heavy reports
• reports with several writers, analysts or reviewers

The warning signs are usually practical. Writers cannot find support for draft claims. Reviewers keep asking where statements came from. Recommendations do not clearly follow from findings. Different analysts code the same material in different ways.

AI-assisted work needs a reviewable evidence layer

AI adds another reason. If the team uses AI to summarise documents, extract themes or draft early findings, the table gives reviewers a place to check the source trail before anything is treated as report-ready.

This is also why messy source material often leads to weak AI outputs, as discussed in why AI gives weak answers when source material is messy.

Start with the fields that protect traceability

That evidence item can be a direct excerpt, a short source-linked summary, a survey result, a row from a dataset, a submission point, a case example or a coded interview segment. What matters is that each item is small enough to trace and useful enough to support analysis.

This approach is similar to the logic behind structured data extraction forms used in evidence synthesis. The Cochrane Handbook chapter on collecting data notes the value of structured forms that preserve clear links back to source reports. Report teams do not need to copy systematic review methods exactly, but the same principle is useful: extract information into a consistent structure before trying to write from it.

Add advanced fields only when the project needs them

More complex reports often need fields that help the team track confidence, source balance, restrictions and review decisions.

Useful additional fields include stakeholder group, respondent type, geography, data collection method, date, confidence level, evidence strength, limitation note, contradictory evidence flag, minority view flag, sensitivity flag, consent or use restriction, recommendation ID, citation text, use in final report, AI-assisted extraction flag, human checked, triangulation status, source reliability, link to output paragraph, QA notes and exclusion reason.

For qualitative synthesis, confidence fields should be used carefully. The GRADE-CERQual guidance is a useful reference point because it focuses on how much confidence to place in qualitative review findings. A normal report team may not need a formal CERQual assessment, but it can still borrow the habit of asking whether a finding is well supported, coherent, relevant and based on enough data.

The right structure is the lightest table that still lets the team trace the report back to the source base. For projects that need a custom structure, see database architecture and the Evidence, Insight & Reporting Engine.

The chain should stay visible

A strong evidence-to-report workflow usually follows this sequence:

• Add each source to the source register.
• Give each source a stable Source ID.
• Extract usable evidence items from each source.
• Give each evidence item an Evidence ID.
• Add a precise source locator.
• Summarise the evidence item in plain language.
• Record the claim or point the evidence supports.
• Tag the theme and subtheme.
• Link the item to a research question or evaluation question.
• Group similar evidence items into draft findings.
• Link each finding to a recommendation where relevant.
• Assign each finding or evidence cluster to a report section.
• Add review status, limitations and notes.
• Draft the section from the grouped evidence records.
• Check report claims back to the table and source material.

A simple example

This example shows the difference between an excerpt, a claim and a finding. The excerpt is the source-linked material. The claim is the interpreted point. The finding is the higher-level statement built from that item and other related evidence.

A finding should usually draw on more than one evidence item. A single interview quote can illustrate a finding, but it should not carry the full finding unless the report is clearly presenting a case example, single-source observation or named stakeholder position.

This is the problem covered in more depth in how to stop losing source traceability in evidence-heavy reports.

Move from evidence items to findings

Start by filtering the table by research question, theme or report section. Read the related claims together, not one source at a time. This helps the team see patterns across interviews, submissions, documents and datasets.

Then group similar claims. Some claims will say nearly the same thing in different words. Others will point to different sides of the same issue. Keep them together long enough to test whether they support one finding or several narrower findings.

Next, check the source mix. A finding supported by interviews only is different from a finding supported by interviews, administrative data and document review. A finding supported by one stakeholder group is different from a finding repeated by beneficiaries, implementers and managers.

Then look for contradictions. Do not hide them in the notes column. If evidence points in different directions, flag it. A good report can still present a clear finding, but it should not flatten disagreement that matters.

Finally, write the draft finding. A finding should be more than a repeated quote. It should state what the team has concluded from the evidence cluster.

Reduce the work pushed into the writing stage

Report writing becomes harder when the evidence work is unfinished.

A writer sitting with folders, transcripts, survey exports and marked-up PDFs has to do several jobs at once. They have to find evidence, interpret it, compare it, decide what matters, draft the section and manage citations. That is too much to push into the writing stage.

A source-linked evidence table separates the work. Analysts can extract and code evidence before drafting starts. Lead researchers can review claims and draft findings. Writers can then work from filtered evidence clusters rather than searching through the source base again.

This helps with faster section drafting, fewer repeated source searches, clearer chapter summaries, better handover between analysts and writers, more consistent use of themes and findings, fewer unsupported claims in the draft, and easier checking when reviewers ask for the source trail.

The table should not make the writing mechanical. It should give the writer a stronger base. The writer still has to decide what belongs in the narrative, what needs a caveat, which quote helps the reader and which detail belongs in an appendix.

Bring the evidence check earlier

A source-linked evidence table brings that check earlier.

This is especially important for evaluations and public-sector work. The UK Government’s Magenta Book frames openness and quality around the planning, design, analysis and reporting stages of evaluation. A report evidence table supports that kind of early QA by making claims, findings and source links visible before the final review.

An evidence table helps the team test whether:

• each finding has enough evidence behind it
• each recommendation follows from a finding
• each claim can be traced to source material
• some findings rely too heavily on one source type
• one stakeholder group is over-represented
• contradictory evidence has been reviewed
• weak evidence has been labelled carefully
• direct quotes are approved for use
• sensitive evidence has been handled correctly
• AI-assisted summaries were checked by a person

If your team is unsure where the traceability risk sits, the source traceability risk checker can help identify weak points in the workflow.

Use review statuses as controls, not decoration

Review status fields tell the team what can be used safely and what still needs attention.

A writer should not rely on a record marked “extracted” if nobody has checked whether the claim is a fair reading of the source. A reviewer should be able to filter the table for “used in draft” and test whether the report is backed by approved evidence.

Use AI for retrieval and first-pass work

AI can help with first-pass extraction from long documents, summaries of source material, draft claim statements, suggested themes or subthemes, grouping similar evidence records, comparing source sets, identifying possible gaps or contradictions, drafting early finding statements, and checking whether report claims have evidence links.

The risk is not AI use itself. The risk is treating AI output as if it has already been reviewed.

AI should not decide final findings alone. It should not invent source references. It should not turn unreviewed excerpts into approved evidence. It should not replace research, evaluation, policy or programme judgement.

Add review controls to AI-assisted extraction

A safer AI-assisted workflow uses clear controls:

• Give AI a defined source set, not a vague folder of material.
• Ask for outputs in the same fields used by the evidence table.
• Require source locators for every extracted item.
• Mark AI-assisted records in the table.
• Have a human reviewer check the source, excerpt, claim and theme.
• Approve records for report use only after review.

This fits well with source-linked report writing. AI can support retrieval, classification, comparison, summarisation and drafting. People still need to decide what the evidence means, what it does not prove and how it should be written in the final report.

For teams building this into a repeatable workflow, see AI Knowledge Base Build, custom AI building and how to QA an AI knowledge base before team use.

Start with the tool the team can maintain

For many teams, a spreadsheet is enough. Excel or Google Sheets can work well when the project has a clear field set, stable IDs, dropdowns, protected columns and a shared folder structure.

A spreadsheet is usually enough when the team is small, the source base is manageable, the table has fewer than a few thousand rows, the report has a clear structure and one person can manage the data dictionary and QA process.

Airtable, SharePoint Lists or Notion databases can help when the team needs better filtering, linked records, views by section, reviewer dashboards or file attachments.

Qualitative analysis software such as NVivo, ATLAS.ti, MAXQDA or Dedoose can help when the project involves detailed coding, large interview sets, mixed data types or formal qualitative analysis. These tools can support coding and retrieval, but the team still needs a report-facing structure that links evidence to findings, recommendations and report sections.

A custom database or AI knowledge base can help when the source base is large, the reporting cycle repeats, or the team needs source-linked retrieval across many documents. This is often the case for public submission analysis, multi-country evidence reviews, donor reporting portfolios or policy processes with several rounds of drafting and review.

The tool matters less than the structure. A clear spreadsheet can be a serious evidence system. A badly designed database can still fail.

Use three sheets to start

A practical spreadsheet-first setup can use three sheets.

Sheet 1 is the source register. Use it to record every source before extraction starts. Include Source ID, source title, source type, date, owner or author, stakeholder group, geography, file link and access or sensitivity note.

Sheet 2 is the evidence table. Use it as the working layer for extraction, coding, synthesis and report use. Include Evidence ID, Source ID, source locator, evidence excerpt or summary, claim or point made, theme, subtheme, research or evaluation question, Finding ID, Recommendation ID, report section, review status, limitation or sensitivity note, analyst, reviewer, AI-assisted extraction flag and human checked status.

Sheet 3 is the findings and recommendations map. Use it to connect synthesis to action. Include Finding ID, finding text, Evidence IDs, Recommendation ID, recommendation text, priority, owner or audience, report section and review decision.

Once the sheets are set up, agree on the rules. Every source gets a Source ID before extraction. Every evidence item gets an Evidence ID. Every evidence item needs a locator. Every claim needs a theme. Every finding should link back to evidence. Every record used in the report should be reviewed.

That is enough to start. The team can add more fields later, but it should not skip the basics.