Audit Trail in Qualitative Research: What to Document and How

By the YumiLM Team

An audit trail is the documented record that lets someone else follow your path from raw data to findings — what you collected, how you processed it, and why you made the decisions you made along the way. It's how qualitative research earns the trustworthiness that a p-value gives quantitative work: not through statistical significance, but through a reviewer being able to trace every step and judge whether your conclusions actually follow from your data.

When your raw data includes AI-generated interview or video transcripts, the audit trail needs a few entries that a purely manual process wouldn't — which tool produced the transcript, what got corrected before analysis, and how you confirmed the text matches the recording. This guide covers both: the audit trail categories every qualitative study needs, and what changes when part of your pipeline is AI transcription. For the coding and verification steps that feed into several of these categories, see Coding AI-Generated Interview Transcripts.

Key Takeaways

Table of Contents

• What an audit trail is, and what it's for
• The five categories of audit trail material
• What changes when a transcript is AI-generated
• Building the trail as you go, phase by phase
• Common gaps that weaken an audit trail
• Privacy and confidentiality considerations
• Checklist
• Sources

What an audit trail is, and what it's for

The term comes from financial auditing and was adapted to qualitative research by Lincoln and Guba, who framed it as the mechanism for establishing dependability (would another researcher, following your documented process, arrive at consistent conclusions) and confirmability (are your findings shaped by the data and your explicit reasoning, not by unexamined bias). A study can be methodologically sound and still fail a review if nobody but the original researcher can see how the conclusions were reached — the audit trail is what makes that reasoning inspectable after the fact, not just trusted on the researcher's word.

In practice, an audit trail is not one document. It's a maintained collection: a decision log, dated codebook versions, memos written during coding, and a record of anything that changed between raw recording and final report. The goal is that a reviewer — a supervisor, a journal reviewer, or a future version of yourself six months later — can reconstruct the path without having to ask you what you meant.

The five categories of audit trail material

Research methodologists commonly group audit trail material into five categories. Treat this as a checklist for what your project folder should contain, not a template to fill in after the fact:

1. Raw data — recordings, transcripts, field notes, and any documents collected during data gathering, kept in their original, unedited form alongside anything derived from them.
2. Data reduction and analysis products — codes, coding memos, and summaries produced while working through the raw data.
3. Data reconstruction and synthesis products — theme categories, interpretations, and the inferences drawn from the coded data.
4. Process notes — a log of methodological decisions, the challenges encountered, and why the approach changed if it did.
5. Materials related to intentions and dispositions — the original research proposal, a field journal, and reflexivity notes on how the researcher's own position may have shaped the analysis.

A project that keeps all five, dated and versioned, has an audit trail. A project that only keeps the final coded transcript and the write-up does not — even if every individual decision along the way was defensible, there's no record a reviewer can actually check.

What changes when a transcript is AI-generated

None of the five categories above disappear when a transcript comes from an AI transcription tool instead of a human transcriber — but raw data and process notes both pick up entries that wouldn't exist in a fully manual workflow:

• Which tool produced the transcript, and when. Note the transcription tool and the date the transcript was generated, the same way you'd note a human transcriber's name and the transcription date. If the tool or its underlying model changes partway through a study, that's a process note, not a footnote.
• A correction log, separate from the transcript itself. When you verify an AI transcript against the source recording, keep a record of what was corrected — not just the corrected transcript. A misheard technical term or a garbled sentence that gets silently fixed is invisible to a reviewer unless the correction itself is logged.
• What was verified, and what wasn't. If time constraints mean you spot-checked a sample of segments rather than the full recording, say so in the process notes. "Verified in full against the audio" and "spot-checked the segments used in direct quotes" are different claims, and the audit trail should reflect which one actually happened.
• Timestamps as part of the raw-data record. A transcript with preserved timestamps makes it possible to jump back to the exact moment a quote or coding decision came from, which is useful both during analysis and if a reviewer later asks to see the source for a specific extract. YumiLM's transcripts keep this timing information intact, which is what makes that kind of traceability possible without re-scrubbing through the full recording by hand.

Building the trail as you go, phase by phase

The audit trail is far easier to maintain in real time than to reconstruct afterward. A practical way to attach it to a standard analysis workflow:

Keeping this as a running log, rather than a document assembled at write-up time, is what actually makes the difference — a decision explained in the moment is more accurate than one reconstructed from memory weeks later.

Common gaps that weaken an audit trail

A few gaps show up often enough to call out directly:

• No codebook versioning. Only the final codebook survives, with no record of how codes were split, merged, or renamed as coding progressed.
• Corrections made silently. An AI transcript gets cleaned up before coding starts, but the corrections themselves are never logged — so a reviewer can't tell how much of the "transcript" is the tool's output versus the researcher's edits.
• No note on partial verification. A transcript is treated as fully checked when only the sections used in the final report were actually verified against the recording.
• Process notes written after the fact. Reconstructing "why we changed the coding approach in week three" from memory during write-up is a weaker record than a note written the week it happened.
• Reflexivity notes skipped entirely. Confirmability specifically depends on this category — a strong codebook and a clean correction log don't substitute for documenting the researcher's own position and its potential influence on interpretation.

Privacy and confidentiality considerations

An audit trail can end up containing more identifying detail than the final report — coding memos and correction logs sometimes quote a participant verbatim to explain a decision. Anonymize participant names and identifying details in audit trail materials the same way you would in the report itself, confirm your consent scope covers the transcription and analysis tools you actually use, and check your institution's data-handling and retention requirements before storing recordings, transcripts, or correction logs anywhere.

Checklist

• All five audit trail categories are present: raw data, reduction/analysis products, reconstruction/synthesis products, process notes, and reflexivity materials.
• The transcription tool, model/version if known, and generation date are logged alongside the raw transcript.
• A correction log exists, separate from the corrected transcript, recording what changed during verification.
• The process notes state clearly whether verification was full or partial, and against what.
• Codebook versions are dated, with a memo explaining what changed at each revision.
• Quotes in the final report are cross-referenced back to a timestamp in the source recording.
• Participant identifying details are anonymized across all audit trail materials, not just the final write-up.

Sources

• Rodgers, B. L., & Cowles, K. V. (1993). The qualitative research audit trail: a complex collection of documentation. Research in Nursing & Health, 16(3), 219–226.
• Carcary, M. (2009). The Research Audit Trail: Enhancing Trustworthiness in Qualitative Inquiry. Electronic Journal of Business Research Methods.
• Using an Audit Trail to Demonstrate Trustworthiness in Qualitative Research — Statistics Solutions

Recommended

• Coding AI-Generated Interview Transcripts | YumiLM
• How to Analyze Interview Transcripts | YumiLM
• Thematic Analysis with AI-Generated Transcripts | YumiLM
• Verbatim Transcription Accuracy for Interviews | YumiLM
• AI Transcription Guide | YumiLM