Evidence-heavy reports usually depend on more source material than one person can keep in their head.
A team may be working with interviews, case studies, public submissions, field notes, PDFs, previous reports, spreadsheets, meeting notes, datasets, or policy documents. Some sources may be final. Some may be drafts. Some may be confidential. Some may be duplicates. Some may be useful for findings, while others only provide background.
If there is no source register, the team ends up relying on folder names, memory, email threads, and old links. That makes report writing slower and source checking harder.
A source register gives the team one controlled record of the material behind the report. It shows what sources exist, where they are stored, what they contain, whether they have been reviewed, and how they connect to the evidence workflow.
Who this guide is for
This guide is for: Research, evaluation, donor-funded, public-sector, policy, and reporting teams working with many source files, source types, reviewers, and evidence outputs.
What a source register is
A source register is a structured list of all source material used, reviewed, or held for a report, evidence review, public consultation, research project, or AI knowledge base.
It records:
- what the source is
- where it came from
- where it is stored
- what it contains
- which version is current
- whether it has been reviewed
- whether it can be used
- how it connects to evidence outputs
In practical terms, the source register is the control table behind an evidence-heavy report.
It does not replace the source files. It does not do the analysis on its own. Its job is to make sure every source has a stable identity, a clear storage location, useful metadata, and a known status.
That sounds administrative, but it is part of report quality control. Without it, findings, quotes, claims, and recommendations can drift away from the material they came from.
When a source register is worth building
A source register is useful when the report has more than a handful of sources, more than one reviewer, or a real need to prove where claims came from.
It is especially useful when:
- the report uses many source types
- several people are reviewing the material
- sources are stored across folders, emails, spreadsheets, PDFs, transcripts, or cloud drives
- findings need to be checked against evidence
- reviewers may ask where a claim came from
- the report includes interviews, case studies, field notes, public submissions, or long documents
- the team needs to avoid using old drafts or duplicate files
- an AI knowledge base will be built from the source material
- the project needs a handover trail
Common examples include public consultation reports, evaluation reports, UNICEF or donor-funded reports, policy reviews, situation analyses, theory of change work, research syntheses, public submissions analysis, internal reporting reviews, and impact reports.
The larger the evidence base, the more important the register becomes. But size is not the only trigger. A small project with sensitive interviews may need a tighter source register than a large project using only public documents.
How a source register differs from a bibliography, folder, evidence table, and quote bank
A source register is easy to confuse with other project tools. The difference is the layer it controls.
| Tool | Main purpose |
|---|---|
| Source register | Tracks the source material and its metadata. |
| Source folder | Stores the actual files. |
| Bibliography | Lists published references used in the final report. |
| Evidence table | Extracts claims, findings, or evidence points from sources. |
| Quote bank | Stores selected quotes or excerpts from the sources. |
| Codebook | Defines the coding categories used during analysis. |
| Thematic matrix | Compares themes across sources, groups, or questions. |
| AI knowledge base | Lets users retrieve and summarise approved source material. |
The source register sits before these tools.
A bibliography only lists sources that need to appear in the final report. A source register can include everything the team has received, reviewed, excluded, superseded, or held for reference.
A folder stores files, but it does not tell the team whether a file has been reviewed, whether it is safe to use, or which report section it relates to.
A quote bank stores selected excerpts. A source register tracks the source records those quotes came from.
An evidence table links evidence to claims or findings. A source register tells the team what source material exists and where it can be found.
This separation matters. Once a report has multiple sources, findings, quotes, and drafts, trying to manage everything in one table quickly becomes messy.
What should go into a source register
A source register should be simple enough to maintain and detailed enough to support review.
Not every project needs every field. A small internal report may only need 10 fields. A donor-funded, public-sector, multilingual, or AI-assisted evidence workflow may need more.
Here is a practical field structure.
| Field | Purpose |
|---|---|
| Source ID | Gives every source a unique reference. |
| Source title | Gives the source a clear, readable name. |
| Source type | Shows whether it is an interview, case study, submission, report, dataset, transcript, field note, or other source. |
| Author / originator | Records the person, organisation, stakeholder, or team that produced it. |
| Date created | Shows when the source was created. |
| Date received | Shows when the team received it. |
| File name | Records the exact file name. |
| File link / folder path | Shows where the source is stored. |
| Version | Marks whether the source is current, superseded, draft, final, translated, cleaned, or redacted. |
| Locator system | Shows how evidence can be found inside the source, such as page, paragraph, timestamp, row number, or transcript line. |
| Short summary | Explains what the source contains. |
| Key topics | Lists the main issues covered. |
| Themes | Links the source to coding or report themes. |
| Review status | Shows whether the source is not reviewed, in review, reviewed, approved, excluded, or superseded. |
| Coding status | Shows whether it is not coded, partly coded, coded, or checked. |
| Sensitivity flag | Marks the source as public, internal, confidential, sensitive, or restricted. |
| Consent / permission status | Shows whether the source can be quoted, cited, summarised, or used internally only. |
| Language | Records the source language. |
| Translation status | Shows whether the source is original, translated, needs translation, or has a checked translation. |
| Duplicate status | Marks whether the source is original, duplicate, possible duplicate, or superseded. |
| Related sources | Links to other source IDs connected to the same case, respondent, issue, or document family. |
| Report use | Shows whether the source supports findings, background, quote bank, recommendations, appendix material, or is not used. |
| Responsible reviewer | Names the person responsible for checking the source. |
| Last checked date | Shows the latest review date. |
| Notes | Adds context, cautions, handling instructions, or unresolved questions. |
For a smaller project, use a shorter version:
Source ID Source title Source type Date File link Summary Theme Review status Sensitivity Notes
For a more serious evidence-heavy report, use an expanded version:
Source ID Source type Source title Originator Date received File name File link Version Locator Summary Key topics Review status Coding status Consent Sensitivity Report use Reviewer Notes
The goal is not to collect metadata for its own sake. The goal is to make the evidence base easier to find, check, compare, and hand over.
How to design source IDs
Source IDs are one of the most important parts of the register.
They become the link between the source register, quote bank, evidence table, findings matrix, report draft, and reviewer comments.
Good source IDs should be:
- unique
- readable
- stable
- short enough to use in notes
- clear enough for reviewers to recognise
- connected to source type where useful
Simple examples include:
| Source type | Example ID |
|---|---|
| Interview | INT-001 |
| Case study | CS-001 |
| Public submission | SUB-001 |
| Field note | FN-001 |
| Policy document | POL-001 |
| Dataset | DATA-001 |
| Literature source | LIT-001 |
| Internal document | DOC-001 |
For larger projects, add a project, country, workstream, or stakeholder prefix.
Examples:
- ZAM-CS-001
- PAL-INT-014
- WP-SUB-245
- EVAL-DOC-032
- SITAN-DATA-004
For more complex projects, use a structured pattern:
[Project]-[SourceType]-[Entity]-[Sequence]
For example:
- CPR-INT-P012-003
- WP-SUB-ORG-0147
- EVAL-DOC-20250314-021
- SITAN-DATA-ZM-004
The exact format matters less than the rule behind it: once a source ID is assigned, do not reuse it for another source.
If a source is removed, mark it as excluded. If a new version replaces it, mark the old source as superseded. Do not recycle the ID.
This protects the evidence trail. A quote ID, evidence row, or report comment may depend on that source ID later.
Build the register before analysis starts
A source register is most useful when it is built before coding, extraction, synthesis, or report drafting begins.
If the register is built after analysis, the team has to reverse-engineer the evidence trail. That creates extra work and increases the chance of missing files, broken links, duplicate sources, and unsupported findings.
A better workflow is:
1. Collect the source material. 2. Save the raw sources in a controlled folder. 3. Assign source IDs. 4. Log each source in the register. 5. Add core metadata. 6. Confirm version and sensitivity status. 7. Then begin coding, quote extraction, synthesis, and report drafting.
This does not mean every field must be perfect on day one. It means every source should have a stable identity before the team starts building findings from it.
At minimum, capture the source ID, title, source type, date, file link, version, review status, and sensitivity level at intake.
The register can then become more detailed as the project develops.
Keep source metadata separate from analysis
A source register should track the source itself. It should not become the full analysis table.
Source register fields answer questions such as:
- What is this source?
- Where is it stored?
- Which version is current?
- Can we use it?
- Has it been reviewed?
- Is it sensitive?
- Who is responsible for checking it?
Evidence table fields answer different questions:
- What claim does this source support?
- What quote or excerpt matters?
- What theme does it relate to?
- Which finding does it support?
- Is the evidence strong, mixed, weak, or contradictory?
This distinction is important because one source can support several findings. One interview may contain material for three themes. One submission may include several policy issues. One report may support both background context and a recommendation.
If all of that is forced into the source register, the table becomes hard to maintain.
The cleaner structure is:
- source metadata lives in the source register
- selected excerpts live in the quote bank
- coded evidence lives in the coding tool or evidence table
- findings live in the findings matrix or report draft
- recommendations live in the recommendation tracker or matrix
These tools should connect through source IDs. They should not all become the same spreadsheet.
How a source register supports report writing
A source register helps writers because it reduces the time spent searching, guessing, and checking.
A good register helps the team:
- find source material faster
- check where findings came from
- see which sources have been reviewed
- avoid using outdated versions
- prepare evidence tables
- build quote banks
- link claims to source material
- respond to reviewer comments
- check draft sections against evidence
- prepare appendices or methodology notes
- hand over the evidence base after the project
This matters most during drafting and review.
A writer may need to know which interviews discussed a service barrier. A reviewer may ask where a recommendation came from. A client may ask whether a certain submission was included. A technical reviewer may question whether a finding is supported by more than one source.
Without a source register, the team may have to search folders, notes, old emails, and draft comments.
With a source register, the team has one place to start.
How a source register supports AI knowledge bases
A source register also helps when teams want to use AI for retrieval, summarisation, synthesis, or drafting support.
AI should work from an approved source base, not from a loose folder of documents.
A source register helps because it tells the team:
- which documents are approved for upload
- which sources are confidential or restricted
- which files are current
- which drafts should be excluded
- which sources are duplicates
- which sources need redaction first
- which sources have checked summaries or metadata
- which sources are suitable for AI-assisted retrieval
Without a register, AI workflows become harder to control.
The risks include:
- the AI searches the wrong version
- sensitive files are uploaded by mistake
- old drafts are treated as final sources
- unreviewed material is treated as approved evidence
- summaries cannot be checked against source files
- the team loses the link between answer and source
- excluded documents still influence outputs
A source register does not make AI safe on its own. The team still needs the right tools, permissions, storage rules, review process, and human checking.
But the register gives the AI workflow a cleaner starting point. It creates a human-readable source inventory before the material enters an AI knowledge base.
For evidence-heavy work, that matters. If the source base is uncontrolled, the AI output will be uncontrolled too.
Quality checks for a source register
A source register should be checked before drafting starts and again before handover.
Use this checklist:
- Every source has a unique source ID.
- Every source ID links to the correct file.
- File names match the register.
- Folder links work.
- Duplicate sources are marked.
- Superseded versions are marked.
- Draft and final versions are clearly separated.
- Sensitive sources are flagged.
- Consent or permission status is clear.
- Review status is current.
- Summaries are accurate.
- Locator systems are clear.
- AI-generated summaries or tags have been checked.
- Source IDs used in quotes, findings, and report sections match the register.
- The register can be understood by someone who did not build it.
The last point is often the real test.
A source register is not only for the person who created it. It should be usable by another analyst, writer, reviewer, client, or future project team.
Simple source register template
A simple source register can start in a spreadsheet.
Use this version for smaller projects:
| Source ID | Source title | Source type | Date | File link | Summary | Theme | Review status | Sensitivity | Notes |
|---|---|---|---|---|---|---|---|---|---|
| INT-001 | Interview with service provider | Interview | 2026-04-12 | [Link] | Discusses referral barriers and staffing issues. | Access; workforce | Reviewed | Confidential | Use anonymised references only. |
| CS-001 | Case study: rural household | Case study | 2026-04-18 | [Link] | Describes service access, transport costs, and local support. | Access; poverty | In review | Sensitive | Needs anonymisation check. |
| SUB-001 | Public submission from NGO | Submission | 2026-04-20 | [Link] | Raises concerns about implementation gaps. | Policy implementation | Reviewed | Public | Suitable for summary. |
For larger reports, use an expanded version:
Source ID Source type Source title Originator Date received File name File link Version Locator Summary Key topics Review status Coding status Consent Sensitivity Report use Reviewer Notes
For AI-assisted projects, add fields such as:
| AI field | Purpose |
|---|---|
| Approved for upload | Shows whether the source can be added to an AI tool. |
| Approved tool | Shows which AI tool or workspace may use it. |
| Chunk-ready | Shows whether the document is clean enough for retrieval. |
| Excluded sections | Notes parts that should not be uploaded or used. |
| Source quality tier | Helps prioritise stronger sources. |
| AI summary checked | Confirms whether AI-generated summaries have been reviewed. |
These fields are only useful if the team maintains them. Keep the template as light as the project allows, but as structured as the evidence requires.
What software can be used
A source register does not need expensive software. The right tool depends on the source volume, review team, sensitivity level, and need for linked tables.
| Tool type | Examples | Best for |
|---|---|---|
| Spreadsheets | Google Sheets, Excel | Most source registers, especially early-stage and handover-ready systems. |
| Lightweight databases | Airtable, Notion, Coda | Teams needing linked tables, views, filters, and cleaner interfaces. |
| Reference managers | Zotero, Mendeley, EndNote | Literature-heavy reports and academic-style references. |
| Qualitative analysis tools | NVivo, MAXQDA, ATLAS.ti, Dedoose, Quirkos, Taguette | Larger qualitative projects with coding and transcript analysis. |
| Document management | Google Drive, SharePoint, OneDrive, Dropbox | Source storage and file control. |
| AI knowledge tools | NotebookLM, custom GPTs, Claude Projects, Gemini | Retrieval and summarisation from approved source sets. |
| Project tools | Trello, Asana, ClickUp, Monday | Tracking review tasks, not managing the source register itself. |
For many teams, a spreadsheet is enough to start. It is easy to filter, review, export, and hand over.
A lightweight database may be better when the project needs linked tables. For example, one table for sources, one for evidence extracts, one for report sections, and one for review tasks.
Qualitative analysis tools are useful when the project needs coding, excerpt retrieval, and transcript-level analysis.
Document management tools are still needed because the register should point to source files, not replace them.
Project tools can help track review tasks, but they should not become the only place where source metadata lives.
The safest rule is to keep storage, metadata, and synthesis logically separate, even when one platform can handle more than one layer.
Common mistakes to avoid
Most source register problems come from starting too late or making the table too informal.
Here are the mistakes to watch for.
Creating the register after analysis has started
If the team starts coding, extracting quotes, and writing findings before sources are logged, the evidence trail becomes harder to rebuild.
Relying only on file names
File names are useful, but they are not stable enough on their own. Files get renamed, copied, downloaded, translated, and saved in different folders.
Using vague source titles
A title like “Interview notes” or “Final report” may make sense for one day. It will not help six weeks later when there are 40 similar files.
Changing source IDs halfway through
Changing IDs after quote extraction or drafting can break links between the register, evidence table, quote bank, and report comments.
Not marking duplicates
Duplicate sources can distort analysis, especially in public consultations, submissions analysis, evidence reviews, and document-heavy projects.
Not tracking versions
Drafts, final files, cleaned files, translations, and redacted files should be clearly marked. Otherwise, writers may use the wrong version.
Leaving links broken or missing
A source register without working file links becomes a list, not a retrieval tool.
Ignoring sensitivity
Sensitive, confidential, restricted, or personal material should be flagged early. Do not leave these decisions until publication review.
Mixing source metadata and analysis in one messy sheet
The source register should not become the quote bank, codebook, evidence table, findings matrix, and draft outline all at once.
Uploading uncontrolled folders into AI tools
An AI tool should not receive every file just because it exists. The source register should help decide what is approved, current, relevant, and safe to use.
Failing to hand over the register
A final report and a folder of documents is not enough for many evidence-heavy projects. The register is part of the project memory.
Need help organising source material for a report?
A source register is not the final report, but it protects the route to the final report.
It gives the team one place to check what evidence exists, where it is stored, how it has been reviewed, and how it connects to the writing.
For evidence-heavy work, that structure matters. It reduces repeated searching, supports source traceability, and gives writers and reviewers a cleaner way to move from raw material to report-ready evidence.
If your team is working with interviews, case studies, submissions, field notes, reports, PDFs, spreadsheets, or project documents, I help build the source register, evidence tables, quote banks, and reporting workflows that make the material easier to use.
Data Synthesis
Combine and interpret inputs from multiple sources into integrated findings.
