Audit Trail in Qualitative Research: A Decision Log Example

An audit trail in qualitative research is a dated record of what the researcher decided, why, and which material informed the decision. It lets another reader follow the path from the question to the finding.

It includes more than a folder of transcripts. A useful trail connects original material, working notes, changes to the method, and the reasons for those changes. Write entries when decisions happen. If a reason was never recorded, mark the gap instead of writing a convincing story later.

Atlas can help compare sources you have permission to use and draft a note with citations. Check the cited passages yourself, then keep the corrected note and earlier versions under your project's own records policy. Atlas does not know which decisions your team made offline.

What an audit trail records

An audit trail lets a reader inspect how a study changed. Carcary's method paper asks teams to keep both their source files and their reasons for key choices. Both matter. A transcript shows what someone said; a dated memo shows why the team changed a code or sampling rule.

The record helps a reviewer ask whether a finding follows the path the team reports. It does not let anyone rerun an interview or know what the team thought but never wrote down. It should show the work that took place.

A team might change an interview question after three talks. It might merge two codes or rethink a case that does not fit. Keep the old version, the new one, and the reason. A final report often hides that path.

Nair's paper on auditability calls for a clear account of the research path. It also warns that a rigid form can hide how the work changed. Fit the record to the study and its ethics rules.

Choose records worth keeping

Start with what a reader needs to understand a claim, a change, or a gap. The list below helps you plan. It is not a fixed rule for every study. White and colleagues' field study shows how a large team kept a record of shifts in its data work.

Table 1: Keep private data apart from the part you can share. Use safe IDs and limit access under the study's consent and data rules. An audit trail is no reason to copy private transcripts into each memo.

A reflexive journal can form one part of this record. It notes how the researcher's own view may shape the work. The wider trail also links steps, file versions, source IDs, and report choices.

The inductive theme guide shows how a theme can change when a case does not fit. The thematic analysis guide covers the wider task of finding and testing themes.

Build a dated decision log

Create one entry when a decision changes what the team collects, codes, compares, or reports. Use a small set of fields that you can maintain:

1. Date and owner. Record when the decision was made and who made it. If the date is uncertain, say so.
2. Decision. Name the specific change. “Updated analysis” is too broad; “split the access code into referral and appointment codes” can be checked.
3. Reason and alternatives. State what prompted the change and what else the team considered. Distinguish a source observation from a preference.
4. Affected material. Point to the transcript identifier, excerpt, memo, version, or study plan. Protect restricted material.
5. Open question and review point. Say what remains unresolved and when the team will look again.

Carcary's practice guidance treats the record as a way to trace how a team's thinking changes. Write the reason alongside the change.

A list of dated files without the choice that joins them leaves the reader guessing.

Use a stable naming rule for versions. For example, codebook-v2 can cite codebook-v1 and the memo explaining the change. Keep the earlier file. A later overwrite destroys the comparison the trail is meant to preserve.

Example decision record

This fictional example shows a log entry for a small interview study about access to a campus support service. It is an illustration, not observed research data.

Table 2: The entry explains a change but does not prove the two excerpts were coded well. A reviewer still needs the source passages and the earlier codebook to assess it.

If P02 was never reread, the final trail should say the question stayed open. The negative case analysis guide shows how to test a theme against a case that resists it.

Avoid filling a missing row with a guessed reason. Suppose the team finds codebook-v3 but no note about why a code disappeared. Record “reason not documented” and ask a researcher who was present. If no reliable account exists, keep the gap visible in the report.

Maintain the trail as analysis changes

Set a regular point to save decisions, such as the end of each interview or coding meeting. Update the log when the decision occurs. A short contemporaneous note is easier to trust than a detailed account reconstructed months later.

Store originals and later versions apart. Link each new memo to the old version and the source it affects. Do not replace the earlier file.

When two people disagree, record both views and the final choice. Keep any open dispute that still matters to the finding. A reflexivity note can explain how the researcher's own position shaped that choice.

The auditability paper by Nair calls for a clear account of how the work changed. That does not mean every team needs the same form. A long interview study and a study of documents have different choices to explain.

Before drafting findings, walk backward from one claim. Can you reach the excerpt, the memo, and the decision that shaped the category? If an important step has no record, describe the limit. The qualitative coding guide covers coding choices. This trail records why a choice was made in this study. A framework analysis matrix can keep case summaries tied to source passages.

Check source links in Atlas

Add only files you are allowed to use to an Atlas project. For one choice, mention the sources with @ and ask how the passages differ. Ask for the source ID, cited text, and any missing field.

Open each citation. Then save a checked summary as a note. The source comparison guide offers a wider workflow for checking claims across chosen files.

For the fictional example, you could ask Atlas to compare P04 and P07 on the type of access barrier. If P07's passage does not support “appointment delay,” correct the note and log the correction. The researcher decides the code and records the reason; a plausible answer is not a substitute for source review.

This diagram shows how the fictional decision stays linked to excerpts, old and new codebooks, and the unresolved P02 question. It is a model for a researcher-maintained record, not a software log. Retain dated originals and versions in the storage process your project requires.

State what the trail cannot prove

A clear trail lets others check the work. It does not prove the study is sound, ethical, or based on enough sources.

Those judgments depend on how the team chose people or texts, worked with them, tested its own views, and made its claims. White and colleagues used a trail alongside staff training, team talks, and other checks in a large study.

It also cannot reveal undocumented decisions. If the team changed its sampling rule without noting when or why, neither an AI summary nor a polished timeline can recover that fact. Describe what is known, what is inferred, and what remains missing.

Use the trail in the final report to explain consequential changes and show where claims can be checked. Keep confidential material protected. The goal is an honest route through the study, including its turns and gaps, that another reader can examine.