A Priori Codes: Apply a Framework Without Forcing Fits

A priori codes are labels you prepare before a coding pass. You draw them from a stated framework, prior research, or your study questions. They give you a starting lens for reading text, while leaving its meaning open to review.

Your task is to explain why a code fits a passage and what it leaves out. Keep the rule, source text, reason, and open question together. The invented support example below shows a match, a rejected match, and an idea the codes miss. Atlas can help compare the supplied text and rules; you check each suggested code.

What makes a code a priori

The term describes where the code comes from and when you prepare it. A code drawn from a prior framework starts with a specified concept. A data-led code develops as you read the material. CUNY's coding chapter explains the prior starting point and warns that the connection to the text must be clear.

For example, a study might use a supplied model of support to prepare labels for kinds of help. Another study might develop labels from how people describe asking for help. These are different origins, even if a final label sounds similar. The Delve coding tutorial compares framework-led and data-led approaches through worked examples.

Choose the approach through the research question and analysis plan. If you need to justify the theory behind your concepts, first develop a theoretical framework. A code list cannot stand in for that argument.

The approaches can also be combined when the design supports it. Fereday and Muir-Cochrane's study used prior theoretical codes alongside data-led coding in research on nursing performance feedback. That is a documented example, rather than a rule that every study must use both.

Turn concepts into usable coding rules

A label such as “support” is too broad to guide a decision on its own. Define the concept, the kind of text that counts, and what should remain outside it. State the unit you will code: a phrase, a turn, or a passage long enough to preserve its meaning.

MacQueen and colleagues' original codebook paper separates definitions, use rules, non-use rules, and examples. Lumivero's practitioner guide explains how those boundaries help make a codebook more than a list of names.

The real excerpt below gives a definition for a specific social-relationship code. Its meaning depends on the framework and surrounding rules; the label alone would not supply the same test.

Fereday and Muir-Cochrane, Table 1, page 6, define a particular kind of relationship. The image crops the definition row from the original PDF. Read the full entry and study before adapting that concept to your own material.

For the fictional exercise below, the supplied teaching framework F, version 1, defines two codes:

• Practical help: someone reports receiving help to complete a task. Include actions such as explaining a form. Exclude a wish for future help without a reported action.
• Time fit: someone reports using support during a named period they had available. Include support received during a break. Exclude a general statement about time with no link to using support.

These are invented teaching rules, not a validated framework or a substitute for a real theory. The narrow definitions make it possible to explain both a match and a refusal to match.

Test the rules on selected passages

Try the rules on a range of passages before using them across all the text. Choose some that seem to fit, some whose meaning is unclear, and some the codes may miss. Read the surrounding question and answer too. A short quote can lose a condition that changes what the person meant.

Check what the passage says against both the rule for a match and the rule for leaving it out. A shared word is only a clue: “help” can mean help received, help sought, or help that never came.

Fereday and Muir-Cochrane tried their prior codes on two appraisal documents and compared coding with a supervisor. Your trial needs to show how the rules work on your text. Their count is part of their method record, not a tested minimum for other studies.

If others code with you, use the same rule version when you discuss a disputed passage. Decide how your method will handle such disputes. Talking through a case is one step; a formal measure of agreement is another. Reading the same code list does not carry out either check.

A worked prior-code application

Use framework F with four fictional excerpts about access to support. The speakers, statements, and locators are invented. Read the proposed code beside its reason and the check still needed, rather than treat the table as a completed research finding.

Table 1: These four decisions illustrate a fictional coding exercise. They do not establish actual participant experience, tested agreement, or a final theme.

The second row is the critical refusal. Assigning Practical help because the word “help” appears would ignore the exclusion rule. The correct record keeps the stated hope and explains why the proposed label was rejected.

The fourth row shows why multiple codes may fit when the scheme permits it. Each code still needs its own reason. If you later chart cases across a wider dataset, framework analysis addresses that next stage of comparison; this table checks individual code applications.

Keep exceptions and uncaptured evidence

An unmatched passage can reveal a gap in the scheme, a different topic, or a need for more context. Preserve its locator and a short memo about the issue. Do not silently remove it because it makes the table look less complete.

In E3, fear of being judged falls outside the two supplied rules. You might investigate that concern through a data-led code if the design allows it. Keep its origin clear instead of presenting a new label as part of the prior framework. Inductive thematic analysis explains the wider data-led process.

Also distinguish a coding gap from a challenge to an interpretation. A passage may fit Practical help while contradicting a claim that all help was useful. Negative case analysis helps test that claim. A code application and a claim check answer different questions.

The Delve tutorial discusses the risk of missing detail when existing concepts guide attention. Leave space for that detail, and do not take a lack of coded matches as proof that the concept is absent from the corpus.

Record changes before applying them broadly

Check the analysis plan

Check your study plan before changing the rules. Some studies allow the scheme to change as you read. Others need a fixed set to compare work under the same rules.

If you have grounds for a change, keep the old and new meanings, the reason, and a list of earlier cases to check.

Distinguish a broader rule

Suppose a fifth fictional excerpt says, “Sessions always start while I'm at work.” F version 1's Time fit rule covers help used at a time the person had free, so this passage would not match.

A proposed version 2 might cover both a time that fits and a time that prevents access. That gives the code a broader meaning.

Save the change record

Decide whether to broaden the code or create a separate Timing barrier code. Note the choice and check earlier text that the old rule left out.

Lumivero's revision guidance calls for a record of changes. An audit trail keeps those reasons with the source links.

Keep the earlier decisions so a reader can see what changed. Record which rules you used for each coding pass and why you read a passage again.

Check supplied codes in Atlas

Atlas can compare a supplied framework, code descriptions, and permitted excerpts. Keep your study's data permissions and privacy rules in view before adding material. For this teaching exercise, use framework F and the fictional excerpts rather than real participant data.

1. Add permitted PDFs through Add a source and Upload files. Check processing, then open the files to confirm the definitions and excerpts are readable. Keep the framework version in the source title or your working note.
2. In chat, mention the selected framework and excerpt sources with @. Ask: “Apply only framework F version 1 to these excerpts. For each proposed match, cite the passage and the definition, explain the fit, and check the exclusion rule. Mark ambiguous or uncaptured text. Do not force every excerpt into a code or infer themes.”
3. Open each numbered citation and read the surrounding source text. If E2 is labeled Practical help, compare its future hope with the rule requiring help received. Reject that match and keep the future need as uncaptured evidence. If a definition lacks a useful citation, locate it by name and request the supporting passage.
4. Save the corrected table and reasons through New and Note, then wait for Saved. Include framework version, locators, rejected matches, open questions, and any planned rechecks.

The suggestions remain provisional until you check them. Atlas does not certify coding validity, resolve method choices, measure coder agreement, or establish that every relevant passage was found. You own the decision to keep, reject, or revise a code.

Move from codes to defensible interpretation

Codes help you group evidence for the next stage of work. A label used in several places does not, on its own, show a theme, cause, or proof of the theory.

Read how those passages differ and what their context changes. Check the claims they can support before drawing a wider conclusion.

Keep the table with the rules and notes on text they missed. You can then show why one passage received a code and another did not. That record lets a reader trace your later claims back to the text and the choices you made.