How to build a source register for an evidence-heavy report

What is a source register?

A source register is a structured list of all the source material used, reviewed or held for a report, with one row per source. It records what each source is, where it came from, where it is stored, which version is current, whether it has been reviewed and whether it may be used.

It does not replace the source files and it does not do the analysis. Its job is to give every source a stable identity, a known location and a known status, so that every claim built from it can be traced back. It is the first control in the method we set out in how to keep every report claim traceable to its source.

That sounds administrative, but it is part of report quality control. Records management standards treat metadata about each record as part of managing it (ISO 15489-1:2016). Without that metadata, findings, quotes and recommendations drift away from the material they came from.

When is a source register worth building?

Build one when a 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 draws on several source types, such as interviews, case studies, submissions, field notes, datasets and long documents
• sources are spread across folders, inboxes, spreadsheets and cloud drives
• several people review or code the material
• reviewers are likely to ask where a claim came from
• there is a risk of using old drafts, duplicates or superseded files
• some material is confidential or covered by consent conditions
• an AI knowledge base will be built from the material
• the evidence base has to be handed over at the end

Size is not the only trigger. A small project built on sensitive interviews may need a tighter register than a large project built on public documents.

How is a source register different from a bibliography, evidence table or quote bank?

The register controls the source layer. The other tools work on top of it and connect to it through source IDs.

A bibliography lists only what the final report cites. A register includes everything the team received, reviewed, excluded or held for reference. A folder stores files but cannot tell you whether a file has been reviewed or is safe to use.

The source-linked evidence table and the quote bank both depend on the register: they cite source IDs, and the register tells you what those IDs point to.

What fields should a source register include?

Include enough fields to support review and handover, and no more than the team will keep current. A small internal report may need ten fields. A donor-funded, multilingual or AI-assisted project may need most of the list below.

If the register may later feed a catalogue or an AI system, it helps to know that several of these fields match terms in a published metadata standard: identifier, type, source, isReplacedBy and accessRights all have defined meanings in DCMI Metadata Terms (Dublin Core Metadata Initiative, 2020). Using those meanings from the start makes the register easier to map later.

Where sources contain personal information, the sensitivity and consent fields carry legal weight. In South Africa, the Protection of Personal Information Act restricts processing of special personal information, such as information about health, religious beliefs or race (POPIA, Act 4 of 2013, section 26). The register is where the team records that a source contains it and how it may be used.

How should you design source IDs?

Source IDs link the register to the quote bank, evidence table, findings matrix, report draft and reviewer comments, so they must be unique, stable, short and readable. Once an ID is assigned it is never changed or reused.

For most projects, a type prefix and a sequence number is enough:

For larger or multi-workstream projects, add a project or workstream prefix, for example EVAL-INT-014, CONS-SUB-0245 or SITAN-DOC-032. For complex projects, use a fixed pattern such as [Project]-[Type]-[Entity]-[Sequence], for example CONS-SUB-ORG-0147.

The format matters less than the rules behind it:

• If a source is removed from use, mark it excluded. Do not delete the row.
• If a new version replaces a source, keep the ID, update the version field and record what changed.
• If a genuinely different source arrives, give it a new ID.
• Never recycle an ID. A quote, evidence row or reviewer comment may already depend on it.
• Keep IDs independent of file names, which change.

When should you build the source register?

Build it before coding, extraction, synthesis or drafting begins. A register built after analysis has to reverse-engineer the evidence trail, which is when files go missing, links break and findings lose their support.

A workable intake order:

1. Collect the source material.
2. Save the raw sources in a controlled folder, unchanged.
3. Assign source IDs.
4. Log each source in the register.
5. Add the core metadata.
6. Confirm version, sensitivity and consent status.
7. Only then start coding, quote extraction, synthesis and drafting.

Not every field has to be complete on day one. Every source does need a stable identity before anyone builds findings from it. At intake, capture at least the source ID, title, type, date, file link, version, review status and sensitivity. Add the rest as the project develops.

What belongs in the register and what belongs in the analysis?

The register describes sources. It does not hold the analysis. Keeping the two apart is what keeps the register maintainable.

Register fields answer questions about the source: what it is, where it is, which version is current, whether it may be used, whether it has been reviewed and who checks it. Analysis fields answer questions about the evidence: which claim it supports, which quote matters, which theme it fits and how strong it is.

One interview can feed three themes. One submission can raise several policy issues. If all of that is forced into the register, it becomes unmanageable. 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 a recommendation tracker

These tools connect through source IDs. They should not all become one spreadsheet.

How does a source register help when an AI knowledge base is built?

It decides what the AI is allowed to see. An AI tool should work from an approved, current source set, not from every file in a shared folder.

Without a register, the usual failures are predictable: the tool retrieves an old draft, sensitive files are uploaded by mistake, unreviewed material is treated as approved, excluded documents still shape answers, and nobody can trace an answer back to a source. A register does not make an AI workflow safe on its own. Permissions, storage rules and human review are still needed, and people check every output before it is used. It does give the AI workflow a controlled starting point.

For AI-assisted projects, add a few fields:

We explain which of these fields matter most for retrieval in which metadata fields matter for AI retrieval.

How do you check a source register?

Check it before drafting starts and again before handover. The final test is whether someone who did not build it can use it.

Source register check

[ ] Every source has a unique source ID
[ ] Every ID links to the correct file, and every link opens
[ ] File names in the register match the files
[ ] Duplicates and superseded versions are marked, not deleted
[ ] Draft and final versions are clearly separated
[ ] Sensitive sources are flagged and consent status is recorded
[ ] Review status and last-checked dates are current
[ ] Summaries match what the sources say
[ ] Each source type has a stated locator system
[ ] AI-generated summaries or tags have been checked by a person
[ ] Source IDs used in quotes, evidence tables and the draft exist in the register
[ ] Someone who did not build the register can find a source from an ID

Source register template

Start with this version for a smaller project. Copy the header row into a spreadsheet and keep one row per source.

Source ID,Source title,Source type,Date,File link,Version,Summary,Themes,Review status,Sensitivity,Notes
INT-001,Interview with service provider,Interview,2026-04-12,[link],Final,Referral barriers and staffing,Access; workforce,Reviewed,Confidential,Use anonymised references only
CS-001,Case study: rural household,Case study,2026-04-18,[link],Draft,Service access and transport costs,Access; poverty,In review,Sensitive,Needs anonymisation check
SUB-001,Public submission from an NGO,Submission,2026-04-20,[link],Final,Concerns about implementation gaps,Implementation,Reviewed,Public,Suitable for summary

For a larger or higher-risk report, use the expanded header:

Source ID,Source type,Source title,Originator,Date received,File name,File link,Version,Locator system,Summary,Key topics,Review status,Coding status,Consent,Sensitivity,Report use,Reviewer,Last checked,Notes

Add the AI fields above only if the material will feed an AI tool. Every field needs someone to keep it current, so keep the template as light as the project allows and as structured as the evidence requires.

What software can you use for a source register?

A spreadsheet is enough for most registers. It is easy to filter, review, export and hand over. Move to other tools only when the volume, the number of reviewers or the need for linked tables makes a spreadsheet hard to keep current.

Whatever the tools, keep storage, metadata and analysis logically separate, even when one platform could hold all three. If you would rather have the register, evidence tables and quote bank set up as one linked system, we offer a source-linked evidence system, built and handed over. The same register-first method sits behind the TRC Evidence Archive, where every record is catalogued and linked to its original document.

Common mistakes

• Creating the register after analysis has started. By then the trail has to be rebuilt.
• Relying on file names. Files get renamed, copied, translated and saved in different places.
• Vague titles. "Interview notes" or "Final report" means nothing a few weeks later among dozens of similar files.
• Changing IDs halfway through. It breaks the links from quotes, evidence rows and reviewer comments.
• Not marking duplicates. Duplicates distort counts, especially in consultation and submissions analysis.
• Not tracking versions. Writers end up quoting a draft, an untranslated original or an unredacted copy.
• Broken or missing links. A register without working links is a list, not a retrieval tool.
• Leaving sensitivity decisions until publication. Flag confidential and personal material at intake.
• Turning the register into the analysis. It should not also be the quote bank, codebook, evidence table and outline.
• Uploading whole folders into AI tools. Use the register to decide what is approved, current and safe.
• Not handing the register over. A final report and a folder of files is not a usable evidence base.