Process Tracing: How to Test a Causal Story in One Case

Process tracing asks how a result may have come about inside one case. The researcher states a proposed chain of events, looks for records that each step should leave, and checks other accounts of the same result.

A library may see more visits after it sends text reminders. The dates line up. Yet the library also changed its hours.

To claim that the texts drove the rise, a researcher would need evidence that people received them and then chose to visit. The visit count alone leaves that link open.

Atlas can help line up selected case records and show the passage behind a draft comparison. The researcher chooses the causal tests and weighs the evidence.

What process tracing tests

Process tracing studies a proposed path from cause to result within a case. The path may include choices, messages, rules, or other steps that link an event to an outcome. Collier's original methods paper treats each source item as evidence that may bear on a stated claim and its rivals.

The program-evaluation chapter defines it as within-case analysis of processes and event order. It can help develop a causal account or test one already proposed. That scope differs from asking for an average effect across many people or sites.

A timeline helps order sources. It does not by itself test why the result occurred. The key question is: If this account were true, what else should we see, and what might we see if a rival account were true? A case study's source audit can help keep the records clear, while process tracing adds the explicit causal tests.

The method can be used in political research, policy review, history, or program evaluation. It takes more than a colorful story. You must say what the theory predicts, seek records that could make it fail, and explain why each source is strong or weak for the claim.

State the mechanism and rivals

The method starts with evidence expectations for each link. A case record can then support, challenge, or leave a link open.

Name the result and the proposed path

Begin with one outcome in one case. Set its time and place. Then write the steps that could have led to it. In the library example, a text-message account might be: reminder sent → visitor saw it → visitor planned a trip → visitor arrived. Each arrow makes a claim that can be checked.

The practical design guide asks researchers to define what the theory predicts, direct the search, and name the data needed for a test. Write those expectations before choosing only the records that fit the story.

Give a rival a fair test

A rival in this case is the new evening schedule. It may explain more visits even if texts were sent. Another account could involve a local event that brought people nearby. The program-evaluation chapter warns that leaving out a viable account can skew how all other sources are read.

The goal is to make both accounts testable. Ask what record would be expected if texts mattered and what record would be expected if the new hours mattered. A confounding-variable guide explains a related third-factor problem in observational studies; process tracing asks which links can be seen inside this case.

Gather evidence for each step

Start with records near the events: plans, logs, dates, messages, meeting notes, and interviews. Keep a source ID and page, row, or time mark for each item.

Record who made it, when, and for what purpose. A memo written after the outcome may be less reliable about what people expected before it.

A useful test card has four parts:

1. Claim: Name the proposed link, such as “The reminder reached a visitor before the visit.”
2. Expected evidence: State what record should exist if that link worked.
3. Rival expectation: State what a competing account would predict.
4. Source and limit: Name where to look and what the record cannot show.

The practical guide makes this plan part of the research design. Verian's evaluator guide gives similar advice: plan the needed evidence and its source before spending effort to collect it.

Check whether two records are truly independent. An event summary may repeat an interviewee's account; it is not a second witness.

A missing file also needs context. Was the record meant to exist? Was it kept? Could the researcher access it? A blank folder is not always a failed causal test.

If a source conflicts with the first account, keep the conflict visible. Read the full passage. The words may refer to another date, person, or outcome.

The Cambridge program chapter notes that causes can interact, so the final account may involve both texts and hours.

Use tests with care

The test names describe what a piece of evidence could do to a hypothesis, given the assumptions. Collier's paper sets out straw-in-the-wind, hoop, smoking-gun, and doubly decisive tests. These are ways to think about evidence, not labels that make a document strong by themselves.

A straw in the wind

A clue may make one account a little more plausible. If a visitor recalls seeing a poster about new hours, that helps the hours story. It still may not explain the visit. Collier's open paper says such clues are weak on their own and do little to rule out rivals.

A hoop test

A hoop test asks for evidence a claim needs to stay in play. If the claim says a person visited after receiving a text, proof that no text could have reached that person would hurt it. Passing the hoop, such as showing a text was sent, leaves the account possible. It does not show the person read it or acted on it. The Collier discussion makes that passing-versus-confirming gap clear.

A smoking-gun test

A record can give strong support if it is hard to explain under rivals. A time-stamped note written before the visit that says “I am going because of the text” might favor the text account. But who wrote it, why, and whether the person later visited still matter. Collier's examples show how the same clue can be strong or weak as its assumptions change.

A doubly decisive test

The rare ideal would both strongly support one account and rule out every viable rival. Collier cautions that a single test with that power is hard to find in social research. Treat the label with care. An unchecked rival can make a “decisive” story much less decisive.

Follow a fictional case ledger

The case below is fictional. Every date, source ID, quote, and count is invented for teaching. No real library or Atlas analysis produced this record.

A neighborhood library sees visits rise during a two-week pilot. It sent text reminders to past visitors and began evening hours in the same week. The team wants to know which change contributed to the rise.

H1 says texts prompted visits. H2 says later hours made visits possible. Both may matter.

Before reading more records, the researcher writes what each account predicts. H1 needs evidence that visitors received a text and chose to come because of it. H2 needs evidence that people used the new hours or say the time change enabled the trip. Neither prediction follows from the total visit count alone.

Table 1: The ledger does not award a winner. It shows a stronger piece of evidence for the hours path and a gap in the text path.

One interview also cannot stand for all 18 extra visits. The researcher should seek more sources or state the result as uncertain.

A bounded finding might read: “Visits rose during the pilot, and some occurred in the new evening slots. One guest linked their visit to the later time. The available records do not connect sent texts to specific visits, so the text-reminder path remains untested here. Both changes may have contributed.”

That paragraph keeps a case-level account tied to its sources. It does not estimate a population effect or claim that hours caused all new visits. The Center for Evaluation Innovation's guide frames process tracing as practical work in complex settings where more than one path may matter.

Check case records in Atlas

Atlas can help prepare a source comparison after the researcher has set the hypotheses. Add only case material the project is allowed to hold. Mention the chosen plan, send log, visit record, and interview note in one project chat.

Ask for a row per proposed link: “Which passage supports H1, which challenges it, and what does H2 explain? Keep each source distinct and cite the passage.”

Open each citation and read the surrounding record. Check the date, person, and source purpose. If Atlas blends an interview with a log, separate them by hand. If it misses a source, inspect that source directly. Save a checked note with the expected observation, source locator, rival, and remaining gap.

This first-party image shows an open paper beside an Atlas answer. The visible paper concerns AI science. It does not show the fictional library records or a causal test.

Atlas's public guides support selected-source comparison, opening citations, and saving checked notes. They do not show that retrieval is complete or that the product can choose a valid test. The method still rests with the researcher. For a broader source-analysis workflow, see qualitative data analysis with AI.

State what the case can show

Process tracing can build or test an account of how one outcome arose. It needs viable rivals, good sources, and clear assumptions. The practical design paper focuses on theory testing, while other forms may build a theory. Name which job your study does.

A missing record is only informative if you can say it should have existed and been available. A document written after the outcome may reflect hindsight.

Two accounts may share one source. An interview may report a reason that changed later. Mark these limits as you weigh each test.

A case finding may travel poorly to a new site. The library's visitors, hours, and message list may differ elsewhere. The program-evaluation chapter treats the method as a way to explain a case, not a substitute for an effect estimate across cases.

A strong process-tracing report lets another reader follow the claim, expected clue, source, rival, and judgment. It says what would change that judgment. Those parts matter more than attaching “hoop” or “smoking gun” to each line of a timeline.

When the first job is to find and describe changes that emerged during a program, outcome harvesting starts with observed actor changes and then examines plausible contribution. Process tracing starts with a proposed mechanism to test within a case; the two can inform each other without answering the same question.