Role View

The object view identifies mechanisms with specific components: head 9.9, neuron 347, this set of edges. But what happens when the same computation appears in multiple models implemented by completely different components? The role view answers: the mechanism is not the component, it’s the job. “Name mover” is the mechanism; head 9.9 is just one way it happens to be realized in one particular model.

This is the first step beyond the object view. It lets you say “this model has a name mover” without specifying which head, and it lets you compare mechanisms across models with different architectures. Many of the field’s important high-level claims are implicitly role-view claims — claims about what functional job is being done, not about which specific component does it.

Thesis

A mechanism is a role in a computational structure: a specification of what functional job needs to be done, which can be instantiated by different components in different models.

What it explains

Cross-model claims. When researchers observe induction-like behavior across many transformer models, they are noting that the same functional role is realized by different components in different architectures. Only the role view can express the claim “these models all do the same thing” without requiring them to use the same heads. The observation that induction heads appear across diverse model families — a claim about functional role, not about any specific head — is a role-view claim, regardless of whether the original authors framed it that way.

Why circuit labels like “name mover” or “S-inhibition head” are useful. These labels describe functional roles, not intrinsic properties of specific heads. The role view explains why these labels transfer across model instances and training seeds even when the specific component assignments change.

What “multiple realization” means for interpretability. The same role can be implemented by different components, by different numbers of components, or by different architectural structures. The role view makes this a feature, not a bug — it is exactly the level of description needed for cross-model comparison.

What this view says

The role view distinguishes between role specifications and role realizers. The role (e.g., “name-mover” in the IOI task) is abstract — it specifies a functional job. A particular head or set of heads is a realizer of that role in a specific model. Two mechanisms are the same when they occupy the same role in isomorphic computational structures, even if different components realize the role.

The cost is precision. Role labels like “name mover” must be specified precisely enough to be falsifiable — if the label is so vague that almost any component qualifies, the role view collapses into triviality. A role specification should include: what information the component must receive, what transformation it must perform, and what downstream effect it must have. “Roughly moves the relevant token” is too vague; “copies the indirect object token’s identity from the IO position to the end position, increasing the logit of the IO token by at least $\delta$ on IOI prompts” is testable.

When it works and when it doesn’t

The role view is strongest when the same behavior appears across models or training seeds via different components. Cross-seed comparison — different training seeds implement the same behavior via different components, but the same role partition covers all of them — is the cleanest evidence.

Vague roles. The central risk. A role like “roughly processes the relevant context” is satisfied by almost any component that weakly affects the output. Post-hoc role assignment is especially dangerous: if you observe what a head does and then name that the “role,” you have described the head, not discovered a functional category. Roles must be specified before looking at which components realize them, or the assignment is unfalsifiable.

Role inflation. If every component is assigned its own unique role, the role view collapses to the object view and adds no explanatory power.

Multiple roles per component. A component may realize different roles under different prompt conditions, making role assignment context-dependent. Head 9.9 might be a name-mover on IOI prompts and something entirely different on arithmetic prompts.

Roles are still tested via components. Evidence for role claims comes from component-level interventions in a specific basis. The role view inherits many of the object view’s measurement limitations — it adds a layer of functional abstraction on top.

Technical details

Evidence

Cross-seed comparison: different training seeds implement the same behavior via different components, but the same role partition covers all of them
Component transplant: replacing component $h_1$ from $M_1$ with $h_2$ from $M_2$ preserves behavior iff both realize the same role
Linear probing: tests whether a concept is linearly accessible, though probing establishes presence not causal use (see linear classifier formalism)
Weight-space role signature: for a name-mover role claim, $W_{OV}$ should encode a copying operation, the head should perform that function on novel prompts, and a head in a different model with the same $W_{OV}$ signature should earn the same label

What it lets you prove

Multiple realization: the same role can be implemented by different components
Role transfer: if component $h_1$ in $M_1$ realizes role $R$ , transplanting $h_1$ into $M_2$ (replacing $M_2$ ‘s role- $R$ component) preserves the role- $R$ behavior
Role independence: the role specification is stated without reference to the procedure that found the component, and predicts behavior on held-out constructions

Formalism

Role graph, graph homomorphism, causal abstraction. Marr’s levels organize explanatory targets and cut across the views — two researchers at the same Marr level can hold different views — so the two frameworks are complementary rather than nested. DAS/IIA is the primary method for testing role claims via interchange interventions.