Keeping a Qualitative Research Audit Trail

What an audit trail actually contains

Guba and Lincoln's criteria of dependability and confirmability are usually where supervisors point, and both come down to records. In practice the trail has five layers.

• •Raw material records: what was collected, from whom, when and under what consent.
• •Process notes: how data were prepared, transcribed and organized.
• •Analytical decisions: how codes were created, merged, split or abandoned.
• •Reflexive notes: your position, assumptions and the moments they were challenged.
• •Interpretive steps: how codes became themes and how themes became findings.

Record decisions at the moment they happen

The methodology, ethics, data collection and analysis pages give each of those layers a home, so a decision can be written where it belongs instead of in a notebook app you will not open again. Every page autosaves and every save enters version history, which means the trail carries dates you did not have to type.

That timestamped history is the part external readers find convincing. A coding framework page whose history shows three revisions across two months documents an evolving analysis; the same page with a single save on submission day documents nothing.

Keep a reflexive record, not a diary

Reflexivity is only useful when it is specific. Rather than restating your worldview, write the moment: the question you asked that led a participant somewhere, the transcript that irritated you, the code you nearly dropped because it did not fit the story you liked.

1. 1. Before fieldwork

   State what you expect to find and why. This is the baseline you will be held to.

2. 2. During collection

   Note anything that surprised you in the session, while you still remember the room.

3. 3. During coding

   Record why a code was created and what it excludes, not only what it includes.

4. 4. At theme level

   Say which alternative readings you considered and why the chosen one fits the data better.

Show how codes became themes

This is the step most audit trails skip. Use the analysis pages to record the code list, the merges and splits with reasons, and the mapping from final codes to themes. Where a theme is supported by a source or a prior study, the evidence matrix links that reasoning back to the literature, so an interpretation is not left floating.

Version comparison lets you place two saved versions of a coding page side by side, which is the clearest available answer to 'when did this theme appear?'.

Protect participants while documenting

An audit trail should be detailed about process and disciplined about identity. Record consent status, anonymisation approach and the identifier scheme you used, and keep direct identifiers out of the notebook entirely. Everything in a project is private to your account by default, but the ethical standard is minimisation, not access control.

Assemble the trail before you write the methods chapter

Run project review near the end of analysis: it points out pages left empty, research questions with no analysis behind them, and sources that never made it into the matrix. Then export the project so the record exists outside the account as well.

The methods chapter is then a summary of a trail that already exists — which is a considerably shorter piece of writing than the alternative.