Phase C · mechanistic interpretability

Path patching / IOI circuit

Wang et al. 2022; Goldowsky-Dill et al. 2023

← back to the method catalogue

What it does?

Path patching recovers a circuit by patching along specific routes. Rather than measuring whether one internal value matters overall, it patches a value only where it flows along a chosen path to the output, so it can separate a direct effect from an indirect one that passes through other components. This is the technique behind the well-known indirect-object-identification circuit in GPT-2, where it isolated exactly which heads send signals to which. We apply it to the VCS by patching along directed edges of the candidate data-flow and comparing the recovered edge set to the true routine from the disassembly. The idea is powerful because it targets the wiring, not just the nodes. On the VCS its limit is recall in a single frame. When we run it as a one-step directed do-operation, it recovers only the paths that carry a surviving signal in that single step. Many true dependencies are re-derived within the frame through other cells, so a one-step path does not carry them and the method misses them. On some games where the direct circuit is genuinely empty it matches perfectly; on others it recovers little. Path patching is thus precise about what it finds but silent about dependencies that flow through intermediate cells, a recall limit we can measure exactly against the known routine.

Path patching / IOI circuit result

Two adjacency matrices over the candidate RAM cells: the true data-flow graph and the graph this method recovered. A bright cell (row = cause, column = effect) is an edge; the difference between the two panels is the error. path_circuit_F1_vs_true_routine = 0.000 — this example only (pong, state gameplay(seed=0,prefix=90)+15); the audit aggregate is below.

Mechanistic family · patching the wiring, not the nodes

Learn the method — a beginner's guide

New to explainable AI? This block explains the method as it is used on neural networks, then how we run the very same method on an Atari 2600, where — unlike for a network — we know the right answer. Every implementation step links to the code. See also the XAI primer for the shared vocabulary.

The idea in plain words

Activation patching tells you that a component matters. It does not tell you how its influence reaches the output. Component A might act on the output directly, or it might only matter because it changes component B, which then changes the output. A circuit is the answer to that question: the small set of components and the edges (connections) between them that carry out a behaviour. To find edges you need a sharper tool.

Path patching is that tool. You change a sender component, but you let the change reach only one chosen receiver. Every other component downstream of the sender is held at the value it had in the normal run. If the output still moves, the signal must have travelled along the sender→receiver edge. This is how Wang et al. mapped the indirect-object-identification (IOI) circuit in GPT-2: which attention heads send which information to which other heads to complete “When Mary and John went to the store, John gave a drink to…” with “Mary”. On the VCS the true wiring between memory cells can be measured exactly, so we can check how much of it a path patch actually recovers.

How it works on a neural network

Think of the network as a directed graph of components. A transformer’s components all read from and write to the residual stream, so every earlier head can influence every later one. Pick a sender \(s\) and a receiver \(r\). Path patching runs the clean input \(x\) with three rules: \(s\) takes its value from the corrupted input \(\tilde x\); the receiver \(r\) is recomputed normally, so it sees the corrupted \(s\); and every other component that \(s\) could reach is frozen to its clean value. Then

\[ \Delta_{s \to r} \;=\; y\big(x \,\big|\, s := s(\tilde x),\; \text{others frozen},\; r \text{ recomputed}\big) \;-\; y(x). \]

A non-zero \(\Delta_{s\to r}\) means the edge \(s \to r\) carries part of the behaviour. Repeating this over pairs, working backwards from the output, builds the circuit. The result is scored as a set of edges.

Toy example. Let \(b = 2a\), \(c = a + b\), and output \(y = c\). Clean \(a = 1\): \(b = 2\), \(c = 3\). Corrupt \(a := 2\). Plain activation patching of \(a\) gives \(b = 4\), \(c = 6\), so \(\Delta_a = 3\). Now path-patch the edge \(a \to b\): let \(b\) see \(a = 2\) (so \(b = 4\)), but freeze \(a\)’s direct input to \(c\) at its clean value 1. Then \(c = 1 + 4 = 5\) and \(\Delta_{a\to b} = 2\). Path-patch the direct edge \(a \to c\) instead: \(b\) stays at 2, \(c = 2 + 2 = 4\), \(\Delta_{a\to c} = 1\). The total effect of 3 splits into an indirect part (2, via \(b\)) and a direct part (1). That split is what node-level patching cannot give you.

Recipe

  1. Choose clean and corrupted inputs and a metric, as for activation patching.
  2. Pick a sender component \(s\) and a receiver \(r\).
  3. Run the clean input with \(s\) set to its corrupted value; freeze every other component downstream of \(s\) at its clean value; let only \(r\) recompute.
  4. Run the rest of the network and record \(\Delta_{s\to r}\).
  5. Repeat over sender/receiver pairs, starting from the output and moving backwards; keep the edges with large effects.
  6. Score the recovered edge set (precision, recall, F1) against a reference, or test it with ablations.

From a neural network to the Atari

A component (head)A candidate RAM cell: a byte the game uses as a variable.
LayersVideo frames. The sender lives at frame \(f^*\), the receiver at frame \(f^*{+}1\).
Sender corruptionWrite base+17 into the sender cell at \(f^*\).
Freeze all other componentsAfter one frame, overwrite every other candidate cell with its clean value at \(f^*{+}1\); only the receiver keeps the sender’s signal.
MetricDoes the receiver cell’s own value differ from the clean run at the end of the 15-frame horizon?
Reference circuitThe true routine: the same path patch with an exhaustive set of sender values (0, base+17, base+37). An edge is true if any value fires it.

How we apply it to the VCS

The nodes are the game’s candidate RAM cells. Everything starts from the shared gameplay checkpoint at \(f^*\) with a 15-frame horizon. The first frame of the horizon is the sender→receiver hop, using the gameplay stream’s own next action.

  1. One path patch \(i \to j\): copy the checkpoint, write the sender value into cell \(i\), step one frame, then restore every candidate cell except \(j\) to its clean frame-\(f^*{+}1\) value. Run the remaining 14 frames. The edge fires if cell \(j\) ends up different from the clean run.
  2. Recovered circuit. One sender value per edge (base+17), the classical single-shot path patch, over all ordered pairs of cells.
  3. True routine. The same edge-restricted operation, but with three sender values. This is the faithful direct circuit the method targets. A separate transitive graph (perturb a cell, run the full horizon, see which cells change) is recorded for context only.
  4. Score. Edge precision, recall and F1 of the recovered circuit against the true routine, with self-edges excluded.
  5. Positive control. Re-deriving the circuit with the exhaustive value set must give F1 = 1, proving the scorer rewards a faithful circuit.

Two differences from the transformer original matter. First, our “layer” is a whole frame of thousands of CPU instructions, and a cell can be read and rewritten many times inside it. Second, we freeze only the candidate cells, not every byte, CPU register or TIA register. A signal can also leak through those unfrozen parts. The runner also counts transient receivers: cells the program recomputes from scratch, so no single-frame path into them can survive to the end of the horizon.

Read the code

XAI the interpretability method   substrate the bit-exact emulator it runs on (jutari, Julia).

Reading the result

Each game’s figure compares two adjacency matrices: the recovered edges and the true routine. Expect low recall on most games. A single sender value often fails to trip an edge that another value would. Many cells are also rebuilt by the program within the frame through other cells, so the one-step path carries no surviving signal. On games where the direct circuit is genuinely empty the method trivially matches it. On others, including the Pong state shown here, it can recover almost nothing. The positive control shows this is a real limit of the single-shot method, not a scoring bug.

Pitfalls

Try it yourself

julia --project=jutari tools/xai_study/phaseC_mechanistic/path_patching.jl --games core

Writes path_patching_<game>.json/.npz and a core summary into tools/xai_study/phaseC_mechanistic/out/. The exhaustive reference needs up to three re-runs per ordered cell pair, so this is the slowest of the patching runners; it can be sharded per game on the cluster (--shard i --nshards n).

Original papers & further reading

Read next: Activation patching / causal mediation · ACDC — automatic circuit discovery · Attribution / edge patching · A1 · Connectomics / data-flow graph

How it's scored

The score is the F1 of the recovered path or circuit against the true routine's data-flow. We patch along directed edges of the candidate data-flow and compare the recovered edge set to the true routine from the disassembly, taking the harmonic mean of edge precision and recall. The grading is always against the intervention oracle's true wiring. Faithfulness for this method is that circuit F1. Run as a single-frame, one-step directed do-operation, the method recovers only the paths that carry a surviving signal in that single step. Many true dependencies are re-derived within the frame through other cells, so a one-step path does not carry them and recall suffers, which is the main limit the score reflects. On some games the direct circuit is genuinely empty and the method matches it perfectly; on others it recovers little. There is no sprite-position hard-case here, because the output is a circuit, not a coordinate. The grading is always against the oracle, never against another method. The audit box reports the measured triad across the scored games, so the F1 is an average over the scored set. Path patching is precise about the paths it finds but silent about dependencies that flow through intermediate cells.

The score is measured against the §1 intervention oracle — never against another interpretability method. F (faithful) is always vs the oracle; see the execution stack. How each of F / S / M is actually computed for this method (and whether it matches the paper) is in the box just below; the numbers are in the In the audit box under it.

How F, S, M are computed here

The exact formula this method uses for each score, read from its runner, and whether it matches the paper's §3 (F ∧ S ∧ M triad) definition. From the committed audit fsm_math_phaseC.json.

AxisFormula (as computed) What it measuresMatches §3?
F
faithfulness
\(F = F_1^{\mathrm{edge}}(\hat{E}, E^{\star})\)Edge-F1 of the recovered path circuit against the true direct-path routine (exhaustive edge-restricted path patch).✓ matches path_patching.jl (F = clamp(score.f1)); metric_name path_circuit_F1_vs_true_routine. Exactly the paper's circuit-discovery F = edge F1 vs the true data-flow/routine. Record: extra.triad.F / value (pong F=0.0 — no path edges recovered; battery mean F=0.580, n=42).
how it's measured — call stack:
  1. F = clamp edge-F1(recovered path circuit, true routine) — path_patching.jl:693
  2. true causal effect Δy(u) by bit-exact re-run — oracle_intervene.jl:242
S
sufficiency
S = null (undefined)Not scored: the recovered path circuit is a graph structure, not a per-do(u) predictive map.— n/a path_patching.jl (S = nothing). n/a for a graph-valued explanation is consistent with the paper (S defined for predictive maps). Record: extra.triad.S = null.
M
minimality
\(M = |U^{\star}| / |\hat{U}| = |E^{\star}| / |\hat{E}| \in (0,1]\)True-routine edge count over the number of discovered path edges.✓ matches path_patching.jl (M = min(1, ntrue/nrec)). This is the paper's |U*|/|U_hat| applied to edges. n/a when |U_hat|=0 discovered edges (emitted as null, e.g. pong M_named_size=0 -> M=null). Record: extra.triad.M, M_true_minimal_size/M_named_size (battery mean M=1.0 over the n=18 games with >=1 discovered edge).
how it's measured — call stack:
  1. M = |true edges| / |discovered path edges| — path_patching.jl:698
  2. count true-routine and recovered path edges — path_patching.jl:691

✓ matches = the same quantity as §3; ◐ partial = the same kind of estimator but a differing detail; ✗ does not match = a different quantity (see the note). Definitions: F = agreement with the oracle's true causal effects Δy(u); S = held-out predictive score in [−1, 1]; M = |U*|/|Û| (true-minimal-set size / named-set size).

In the audit

This is the method's entry in the actual cross-method audit — scored on the paper's correctness triad, each axis a mean over 44 of the 44 scored games (44 committed §R records), not the single example shown above. Tradition: causal. The example figure (Pong) is one of those records.

0.603F — faithfulness vs oracle (mean over 44 games, ±0.127 CI95)
n/aS — sufficiency: held-out predictive (n/a where the paper does not define this axis)
1.000M — minimality: true-minimal-set / named-set (n/a otherwise)
44committed records aggregated
0.00human-plausibility proxy

F faithfulness (scored vs the oracle for every method) · S sufficiency (held-out predictive score in [−1, 1]; a negative value means the explanation predicts held-out interventions worse than the unperturbed baseline; reported for the predictive methods across all three phases where the calibration/held-out split is defined) · M minimality (true-minimal-set / named-set; where the method names a cause set) — n/a otherwise, per the paper's F ∧ S ∧ M triad.

Source: leaderboard.json · the whole leaderboard is on the methods page and the Paper 2 audit.

Results per game

This method's faithfulness on each of the 44 scored games (all-regime F; this method has no content-vs-position split (see the note below)). Click a header to sort. Every number is read from site_data.json (methods.path_patching.per_game).

content-F and position-F are n/a for this method. The content-vs-position split applies only to pixel-attribution methods — those that produce an attribution map over the framebuffer, whose score can be read separately on the smooth content outputs and the discrete position outputs (where the naive gradient is provably zero). This method does not attribute to a pixel output; it is graded by its own fidelity metric (path_circuit_F1_vs_true_routine), reported as the F column, so there is no content or position regime to separate.

M is n/a on 23 of these games. Minimality is M = |U*|/|Û|, the size of the true minimal cause set over the size of the set the method actually names. On a game where the method names nothing (|Û| = 0 — it discovers no circuit, its attribution map is all-zero, or it decodes no cell), that ratio is undefined, so M is left blank rather than scored. The aggregate M is the mean over the 21 games where the method did name a cause set.

GameF (all)content-Fposition-FSMNote
Air Raid1.000n/an/an/an/arecovers the true causes
Bank Heist1.000n/an/an/an/arecovers the true causes
Boxing1.000n/an/an/an/arecovers the true causes
Centipede1.000n/an/an/an/arecovers the true causes
Double Dunk1.000n/an/an/an/arecovers the true causes
Fishing Derby1.000n/an/an/an/arecovers the true causes
Freeway1.000n/an/an/an/arecovers the true causes
Gopher1.000n/an/an/an/arecovers the true causes
Ice Hockey1.000n/an/an/a1.000recovers the true causes
Kangaroo1.000n/an/an/an/arecovers the true causes
Krull1.000n/an/an/a1.000recovers the true causes
Kung-Fu Master1.000n/an/an/an/arecovers the true causes
Name This Game1.000n/an/an/an/arecovers the true causes
Phoenix1.000n/an/an/an/arecovers the true causes
Q*bert1.000n/an/an/an/arecovers the true causes
Skiing1.000n/an/an/a1.000recovers the true causes
Venture1.000n/an/an/a1.000recovers the true causes
Video Pinball1.000n/an/an/a1.000recovers the true causes
Yars' Revenge1.000n/an/an/a1.000recovers the true causes
Tennis0.941n/an/an/a1.000recovers the true causes
Riverraid0.909n/an/an/a1.000recovers the true causes
Bowling0.800n/an/an/a1.000
Enduro0.800n/an/an/a1.000
Montezuma's Revenge0.800n/an/an/a1.000
Carnival0.667n/an/an/a1.000
Asterix0.400n/an/an/a1.000
Hero0.400n/an/an/a1.000
Road Runner0.333n/an/an/a1.000
Berzerk0.298n/an/an/a1.000
Chopper Command0.286n/an/an/a1.000
Space Invaders0.286n/an/an/a1.000
Private Eye0.222n/an/an/a1.000
Demon Attack0.200n/an/an/a1.000
Seaquest0.200n/an/an/a1.000
Alien0.000n/an/an/an/ano true-cause signal
Assault0.000n/an/an/an/ano true-cause signal
Atlantis0.000n/an/an/an/ano true-cause signal
Breakout0.000n/an/an/an/ano true-cause signal
Frostbite0.000n/an/an/an/ano true-cause signal
Jamesbond0.000n/an/an/an/ano true-cause signal
Ms. Pac-Man0.000n/an/an/an/ano true-cause signal
Pacman0.000n/an/an/an/ano true-cause signal
Pitfall0.000n/an/an/an/ano true-cause signal
Pong0.000n/an/an/an/ano true-cause signal

Call stack — how it runs on jutari / jaxtari

The path from this method's runner (run_game) into the bit-exact VCS substrate, and the computation it involves. Every step links to the exact source on main. From callstack_phaseC.json.

Applied on the substrate

  1. Boot the real ROM with the xitari-parity reset (60 NOOP + 4 RESET) — env_reset!(env; boot_noop_steps = 60, boot_reset_steps = 4) jutari
  2. Deterministically step the emulator one action per env-frame (the one-hop and tail replays) — env_step!(env::StellaEnvironment, action::Integer) jutari
  3. Assemble the shared gameplay-state testbed (checkpoint at f*, causes, shared screen output, cause-density gate) — build_shared_testbed(game; ... intervene_ram = intervene_ram!, run_intervention = run_intervention, soft_ram_peek = soft_ram_peek, ...) runner
  4. Freeze byte-exact RAM + screen out of the env at a frame — snapshot(env::StellaEnvironment, frame::Integer) jutari

The computation

  1. Path patch edge i->j: corrupt the sender cell, step ONE frame (i -> t+1), freeze-restore every other candidate cell at t+1 to its clean value (leaving only j on the i->j edge), continue the rest of the tail, snapshot — path_patch(checkpoint, clean_next, nodes, sender_i, receiver_j, sender_value, rest_tail; hop_action) -> intervene_ram!; env_step! runner intervene_ram! @ path_patching.jl:314 & :319, env_step! @ :316 & :322
  2. Node-level true data-flow graph (transitive reachability) the recovered circuit is scored against — node_dataflow_graph(checkpoint, tail, nodes, at_target) -> intervene_ram! runner intervene_ram! @ :272
  3. Recovered path circuit: which edges fire under the single-shot path patch (vs the exhaustive-do-set true routine graph @ :353) — recovered_path_circuit(checkpoint, clean_next, nodes, ...) -> edge_fires -> path_patch runner true_routine_graph @ :353, score_circuit @ :424

Scored against the exact intervention oracle Δy(u): run_intervention(checkpoint, actions, target_frame, horizon, cause).

Implementation
tools/xai_study/phaseC_mechanistic/path_patching.jl
Reference
Wang et al. 2022; Goldowsky-Dill et al. 2023
Record
path_patching_pong.json
All records
phaseC_mechanistic/out

The figure is generated from the committed record by docs/gen_method_figures.py; the game frame and each RAM cell's screen footprint are produced by render_scenes.jl / cell_footprints.jl.