How to build a source-linked evidence table for a report

What is a source-linked evidence table?

A source-linked evidence table is a structured working table that records each usable piece of evidence and links it to its source, the exact place in that source, the claim it supports and the finding and report section it feeds. One row holds one evidence item.

The table is not the report. It is the working layer between raw material and written analysis, and it is one part of keeping every claim in a report traceable to its source. An evidence item can be a short excerpt, a source-linked summary, a survey result, a row from a dataset, a submission point or a coded interview segment. Each item should be small enough to trace and useful enough to support analysis.

A good evidence table lets anyone on the team answer four questions without opening the source folders:

• 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 that layer, teams tend to rebuild the evidence trail late, often during review, when a funder, board or steering committee asks where a statement came from.

How is an evidence table different from a source register?

A source register records the sources themselves; an evidence table records what was taken from them. The register says what material exists, where it is stored, which version is current and how sensitive it is. The evidence table holds the excerpts and summaries, and connects each one to claims, findings and report sections through a Source ID and a locator.

The two work as a pair, and the register comes first: every source gets its Source ID there before anyone extracts evidence from it. How to set one up is covered in how to build a source register. Direct wording that writers may want to quote has its own home in a quote bank, which stores selected quotes with their consent and sensitivity checks. Keep the three apart. A register used as an evidence table produces rows that are too broad, and a quote bank used as one stores excerpts without the interpretation that turns them into claims.

When does a report team need an evidence table?

A team needs one when there is enough material, enough reviewers or enough risk that memory is no longer a safe method. A two-page internal update can be written from notes. A report that will be reviewed, defended or updated usually cannot.

Evidence tables earn their place in:

• evaluation reports and donor reports
• situation analyses and policy reviews
• public consultation reports and submission analysis
• qualitative and mixed-methods synthesis
• interview and case study analysis
• reports with several analysts, writers or reviewers

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

What fields should an evidence table include?

Start with the fields that protect traceability: an Evidence ID, a Source ID, a precise locator, the excerpt or summary, the claim it supports, a theme, a draft finding, the report section and a review status. Add anything else only when the project needs it.

Systematic reviewers solved a version of this problem long ago. The Cochrane Handbook chapter on collecting data advises recording both the study and the report each item came from, and where in the report the information was found, so the data collection form becomes the record of where every extracted figure came from (Li, Higgins and Deeks, Cochrane Handbook version 6.5, 2024). A report team does not need systematic review methods, but the principle carries over: extract into a consistent structure, with a locator, before writing from it.

Here is a header row you can paste into a spreadsheet:

Evidence ID | Source ID | Source locator | Excerpt or summary | Claim | Theme | Subtheme | Research question | Finding ID | Recommendation ID | Report section | Review status | Analyst | Reviewer | AI-assisted (Y/N) | Human checked (Y/N) | Notes

Which optional fields are worth adding?

Add a field only when someone will filter or check by it. Common additions for larger reports are stakeholder group, geography, data collection method, date, a contradictory evidence flag, a minority view flag, a sensitivity or consent restriction, a limitation note and an exclusion reason.

Confidence fields need care. GRADE-CERQual, the approach used to judge how much confidence to place in findings from qualitative evidence syntheses, looks at four components: methodological limitations, coherence, adequacy of data and relevance, and rates confidence as high, moderate, low or very low (Lewin et al., Implementation Science, 2018). Most report teams will not run a formal CERQual assessment. They can still borrow its questions when testing a finding: is it coherent, is there enough data behind it, and does the evidence fit the context the report is about?

How does the evidence chain run from source to report section?

The chain runs source, Source ID, evidence item, locator, claim, theme, finding, recommendation, report section. The table's main job is to keep every link in that chain visible.

1. Register each source and give it a stable Source ID.
2. Extract usable evidence items and give each an Evidence ID.
3. Add a precise locator to every item at the moment of extraction.
4. Summarise the item and state the claim it supports in plain language.
5. Tag the theme and subtheme, and link the item to a research or evaluation question.
6. Group related items into draft findings and give each finding an ID.
7. Link findings to recommendations where relevant, and assign each to a report section.
8. Record the review status, limitations and notes.
9. Draft each section from the grouped, reviewed records.
10. Check the report's claims back against the table and the sources.

This example shows the difference between an excerpt, a claim and a finding.

A finding should usually draw on more than one evidence item. A single quote can illustrate a finding, but it should not carry it alone unless the report presents it as a case example or a named stakeholder's position.

How do you turn evidence items into findings?

Filter the table by question, theme or section, read the related claims together, and write a finding that states what the team concludes from the cluster. A finding is more than a repeated quote.

Work through the cluster in this order:

1. Group similar claims. Some say the same thing in different words. Others show different sides of one issue. Keep them together until it is clear whether they support one finding or several narrower ones.
2. Check the source mix. A finding supported only by interviews is different from one supported by interviews, administrative data and document review. A point made by one stakeholder group is different from one repeated by participants, implementers and managers.
3. Look for contradictions. Flag them in their own column, not in the notes. A report can still state a clear finding, but it should not flatten disagreement that matters.
4. Write the finding. State the conclusion, the scope it applies to and any caveat the evidence requires.

Once findings are written, a findings-to-recommendations matrix carries them through to recommendations, owners and actions.

The table also changes who does what. Analysts can extract and code evidence before drafting starts, lead researchers can review claims and draft findings, and writers can work from filtered evidence clusters instead of searching the source base again. The writing does not become mechanical: the writer still decides what belongs in the narrative, what needs a caveat and which detail goes to an appendix.

How does an evidence table support quality assurance and review?

It moves the evidence check earlier. Reviewers often find evidence problems late because the draft looks finished before anyone has checked the source trail; a table with review statuses lets them test claims while the draft is still taking shape.

UK central government evaluation guidance treats openness as central to credible evaluation and sets out transparency at three points: planning the evaluation, carrying out the analysis (including keeping the materials and data behind it) and reporting the results (HM Treasury and Evaluation Task Force, Magenta Book, updated May 2026). An evidence table is a practical way to meet the analysis and reporting parts of that standard for a report of any size.

Use the table to test whether:

• each finding has enough evidence behind it
• each recommendation follows from a finding
• each claim traces to a source and a locator
• one source type or one stakeholder group dominates a finding
• contradictory evidence has been reviewed
• weak evidence is labelled as weak
• direct quotes are approved for use and sensitive material has been handled
• AI-assisted summaries were checked by a person

Review statuses only work as controls if writers respect them. A writer should not rely on a row marked "extracted" until someone has checked that the claim is a fair reading of the source, and a reviewer should be able to filter for "used in draft" and confirm every row is approved.

Can AI help build an evidence table?

Yes, for first-pass work, provided a person reviews every row before it is used. AI can suggest extractions from long documents, draft claim statements, propose themes, group similar records and flag possible gaps or contradictions. It should not decide findings, invent references or move unreviewed excerpts into approved evidence.

Controls that keep AI-assisted extraction reviewable:

• Give the tool a defined source set, not a loose folder.
• Ask for output in the same fields the evidence table uses.
• Require a locator for every extracted item.
• Mark AI-assisted rows in their own column.
• Have a reviewer check the source, excerpt, claim and theme of each row.
• Approve rows for report use only after that check.

Which tool should you build an evidence table in?

Use the simplest tool the team can maintain. The structure matters more than the software: a clear spreadsheet can be a serious evidence system, and a badly designed database can still fail.

• Spreadsheets work when the team is small, the source base is manageable and one person owns the field definitions and checks. Use stable IDs, dropdowns for status and theme, and protected ID columns.
• List and database tools help when the team needs linked records, views by section, reviewer queues or attachments.
• Qualitative data analysis software helps with detailed coding of large interview sets, but the team still needs a report-facing table that links coded evidence to findings and sections.
• A purpose-built database makes sense when the source base is large, the reporting cycle repeats, or several rounds of drafting and review draw on the same evidence.

A spreadsheet-first setup can start with three sheets. Sheet one is the source register. Sheet two is the evidence table, using the header row above. Sheet three maps findings to recommendations: Finding ID, finding text, Evidence IDs, Recommendation ID, recommendation text, owner, report section and review decision. Then agree the rules: every source gets a Source ID before extraction, every item gets an Evidence ID and a locator, every finding links back to evidence, and every row used in the report is reviewed.

The same structure, with reported indicators linked back to their sources, sits behind the Social Employment Fund evidence portal. Where the source base or the reporting cycle has outgrown a workbook, a source-linked evidence system, built and handed over, is the next step.

Common mistakes

Most evidence table problems start with design choices made early and casually.

• No stable Source ID. If one document is called "interview notes", "INT 3" and "manager interview" in different places, the trail breaks.
• No Evidence ID. Without item-level IDs the team can only point to a whole source, not the passage that supports a claim.
• Vague locators. "Annual report" is not a locator. "Annual report, p. 34, table 6" is.
• Writing findings straight into the report without evidence records behind them.
• Mixing register and evidence fields in one sheet.
• Too many overlapping themes, or no agreed difference between an excerpt, a claim and a finding.
• No review status, limitation notes or contradiction flag.
• No data dictionary or version record, so nobody knows what a field means or which copy is current.
• Using AI summaries without source checks.
• A table so complex that nobody keeps it up to date. The fix is a clearer table, not a heavier one.