The first AI-assisted coding pass should not feel like handing your study to a machine. It should feel like getting a structured draft that you can inspect, correct, and turn into reviewed evidence. That distinction is the difference between useful acceleration and risky automation. OpenVerbatim is designed for the structured draft.
This tutorial walks through the workflow at a product level: prepare interview audio, create a project, ingest the source, review transcript progress, run an AI-assisted coding pass, adjudicate suggestions, and use confirmed evidence for the next analytic step. The details of your study will vary, but the review discipline should remain the same.
Before you start with real participant material, use the public sandbox. It runs with generated demo material in the browser, so you can learn the interaction pattern without uploading your own data. The sandbox is not a substitute for a real project, but it is the fastest way to understand the accept, edit, and reject loop.
1. Start with a clear research frame
AI-assisted coding works best when the project has a clear frame. You do not need a complete codebook before the first pass, but you should know what kind of analysis you are doing. Are you exploring barriers to adoption? Comparing experiences across participant groups? Looking for process breakdowns? Identifying language that explains trust, risk, or motivation?
Write down the initial research question and any early sensitizing concepts. Keep them lightweight. The goal is not to force the assistant into a rigid scheme. The goal is to give reviewers a shared basis for deciding whether a suggestion is relevant. Without a frame, every plausible label looks useful, and the codebook can become noisy quickly.
Also decide how conservative the first pass should be. For a high-stakes study, you may want every suggestion manually reviewed. For an exploratory internal study, you may allow a faster pass while still routing uncertain material into review. The important thing is that the team knows the review standard before suggestions arrive.
2. Prepare the interview audio
Use the cleanest audio you have. Background noise, cross-talk, and missing speaker context can make transcription and coding harder. If the interview has multiple speakers, keep whatever metadata you can: participant ID, interviewer name, session date, and any consent constraints that affect how the material may be handled.
Do not upload material until your team has confirmed that the project is allowed to use AI assistance. This is a research governance decision, not a UI step. OpenVerbatim’s BYOK orientation is meant to make provider choices explicit, but your team still needs to decide which material is appropriate for the workflow and who is allowed to review it.
For a first test, pick one representative interview rather than the largest possible project. You want to learn the review loop, inspect the transcript quality, and tune the team’s code language. A small, real sample reveals more than a synthetic benchmark because it contains your actual ambiguity.
3. Create a project and ingest the source
In OpenVerbatim, the project is the container for sources, review settings, coding work, themes, and questions. Create a project with a descriptive name and enough context that another team member can understand what the analysis is about. Add the interview audio as a source.
During ingest, the system should make progress visible. Long audio files can take time. A good research tool should not leave the user staring at a silent spinner. Progress events, transcript arrival, and coding status help the reviewer understand what is happening and when the first useful material is ready.
Once transcript text begins to appear, resist the urge to judge the entire study from the first few lines. Skim enough to confirm that the right source is loaded, speakers are understandable, and the content matches the project. If the transcript is clearly wrong, fix the source or settings before running a coding pass. Coding bad text creates bad work faster.
4. Run the first coding pass
The first coding pass should produce suggestions, not final claims. A useful suggestion includes a code label, the supporting quote, a rationale, and an indication of confidence or uncertainty. The quote is essential. It lets the reviewer decide whether the system’s interpretation is grounded in the participant’s words.
As suggestions arrive, look for three things. First, is the suggested code relevant to your research frame? Second, does the quote actually support the code? Third, is the wording at the right level of abstraction? A code that is too broad will absorb everything. A code that is too narrow may fragment the analysis. Editing is a normal part of the pass.
Do not try to perfect the whole codebook immediately. The first pass is about separating useful signal from noise. Accept the suggestions that are clearly grounded, edit the ones that need better wording, and reject the ones that overreach. The system should preserve those decisions as part of the project history.
5. Review with accept, edit, and reject
The A/E/R loop is where AI assistance becomes qualitative work. Accept means the suggestion is good enough to enter the reviewed set. Edit means the assistant found something worth keeping, but a researcher needs to adjust the code, quote, or rationale. Reject means the suggestion should not be used for that interpretation.
Use edit generously. Many useful AI suggestions are directionally right but methodologically rough. The label may use language your team would not use. The quote may include extra sentences. The rationale may miss why the passage matters. Editing lets the team keep the useful discovery while taking responsibility for the final analytic wording.
Use reject without guilt. A rejected suggestion is not wasted time if it helps clarify the boundary of a code. Rejections can reveal where the research question is ambiguous or where the assistant is attracted to surface language that does not match the study. The product should make rejection easy because weak suggestions are expected.
6. Form early themes only from reviewed material
After a first pass, it is tempting to jump straight into themes. That can be useful, but be careful about inputs. A theme built from unreviewed suggestions may look coherent while hiding weak evidence. Prefer to build early themes from accepted or edited material that your team is willing to treat as reviewed.
When a theme appears, inspect its members. Does each code belong? Are there contradictory quotes that should split the theme? Is the theme name descriptive enough to survive outside the workspace? The assistant can help organize, but the researcher still decides what the theme means.
This is also a good moment to refine the codebook. Merge duplicate codes, rename unclear labels, and write short definitions for codes that will recur. The quality of later coding passes depends on this cleanup. AI can accelerate discovery, but a messy codebook will still produce messy analysis.
7. Ask questions of confirmed evidence
Once you have a reviewed set of evidence, ask a focused question. For example: “What barriers did participants describe when trying to complete intake?” or “Which moments increased trust in the process?” The answer should cite source material so you can jump back to the transcript and evaluate whether the synthesis is fair.
Question answering is most useful when it respects the confirmed evidence boundary. If the answer draws from reviewed material, the team can treat it as a synthesis candidate. If it draws from raw suggestions, it may still be useful for exploration, but it should not be confused with a reviewed finding.
Save useful answers as working notes, not final report text. Qualitative writing still requires interpretation, context, and often comparison across participants. The answer can give you a well-cited starting point. Your job is to decide what claim the study can responsibly make.
8. Decide the next pass
After the first interview, pause. Review what the assistant did well, where it overreached, and which codes need clearer definitions. Then decide whether to run the same pass on more sources, adjust the research frame, or tighten the codebook. The best teams treat the first pass as calibration.
If the workflow felt too noisy, narrow the prompt or require more manual review. If it felt too conservative, consider whether project policy can allow faster handling of low-risk suggestions. If reviewers disagreed often, capture that disagreement as a methodological signal rather than hiding it.
The value of OpenVerbatim is not that it makes qualitative analysis automatic. The value is that it can make the first pass faster while keeping review, grounding, and provenance in the center of the work. Start small, review carefully, and let confirmed evidence become the basis for the next analytic step.