[Proposal] Representation Geometry: causal inner products, concept directions, and categorical diagnostics #1880
Description
Proposal
Add a maintained representation-geometry utility for TransformerBridge that derives a metric from centered unembedding covariance, constructs concept directions from counterfactual token pairs, and reports categorical geometry in explicitly declared measurement or intervention spaces.
Deliver this issue through two complementary outcomes:
- A usable geometry/concept-analysis feature with tests, public documentation, and a download-free demo.
- Independent research reproduction and controlled behavioral validation of metric-derived interventions.
The core implementation exists locally but is not merged. Independent empirical validation remains outstanding. This issue should remain open after the core feature merges and close only after both outcomes are delivered.
Motivation
TransformerLens exposes unembedding weights and internal activations, but comparing concept directions requires an explicit metric and coordinate-space contract. Measurement directions describe how a concept is read; intervention vectors describe how it is written. These spaces transform dually, so applying the same whitening map to both breaks their pairing.
A reusable geometry primitive would make contrast-based concept analysis less ad hoc and provide a common foundation for geometry-aware probing and steering experiments. It complements existing projection-kernel subspace analysis rather than duplicating it: issue #1720 and PR #1721 concern attention-head subspace overlap, not unembedding-covariance metrics.
The method is motivated by Park, Choe and Veitch, arXiv:2311.03658v2. Its causal interpretation depends on linear-representation and spanning conditions, plus Assumption 3.3 concerning uncorrelated concept measurements under uniform vocabulary sampling. Theorem 3.4 characterizes a family of metrics; the experiments choose D = I, giving the covariance-inverse metric. This is not a uniquely identified inner product or an unconditional property of every model.
Geometry alone does not establish causal separability, semantic categories, or causal model use. Raw cosine remains a useful comparison baseline, not a universally invalid measurement.
Pitch
A clear and concise description of what you want to happen. It is useful if you relate proposals to existing features or lackthereof as well as relevant mechanistic interpretability techniques or model architectures.
Geometry and concept-analysis API
Provide the following public types and operations:
RepresentationGeometry: tensor fitting and non-mutatingfrom_bridge(...)construction.- Separate measurement/intervention transforms, inverse maps, inner products, and cosines.
ConceptDirection: oriented pair means, raw/whitened differences, population dispersion, and explicitly labeled metric-derived interventions.CategoricalGeometry: centering, affine rank, Gram matrices, distances, angles, validity masks, and separate simplex/regular-simplex checks over supplied vertices.GeometryBasis: coordinate provenance for snapshots and their results.
For U = W_U with shape [d_model, d_vocab], estimate centered, uniformly weighted population covariance:
mean_g = mean_v U[:, v]
Sigma = (1 / V) sum_v (U[:, v] - mean_g)(U[:, v] - mean_g)^T
For an exact positive-definite fit, set M = Sigma. With explicit positive ridge, set M = Sigma + epsilon I. For column-vector measurement g and intervention/context vector h:
W = M^(-1/2)
g' = W g
h' = W^(-T) h
h'^T g' = h^T g
Measurement inner products use M^(-1) and intervention inner products use M. Exact whitening satisfies W Sigma W^T = I; with ridge, the identity applies to Sigma + epsilon I, not generally the original covariance. Reject singular/near-singular exact fits and insufficient explicit ridge rather than silently pseudo-inverting or clamping eigenvalues. Report population, precision, rank threshold, conditioning, and regularization.
Pair (lo, hi) contributes U[:, hi] - U[:, lo]. Return an unnormalized, equally weighted mean and population dispersion. A single pair has zero dispersion, not a confidence guarantee. Reject invalid, duplicate, reversed-duplicate, zero, or non-finite contrasts rather than silently filtering them.
String endpoints must encode to exactly one known token without implicit BOS/EOS, preserving leading-space spelling. IDs need no tokenizer. Snapshot the readout and optional tokenizer so subsequent source edits do not change results silently.
M^(-1) g is a metric-derived intervention. Its transformed-coordinate alignment is true by construction, not independent intervention evidence. Do not treat input-token embedding differences as contextual causal interventions.
Categorical analysis accepts explicit vertices in a declared raw space. Simplex checks require affine independence; regularity additionally checks pairwise distances under a declared relative tolerance. Retain degenerate vertices and mark undefined angles with NaNs and a validity mask. Arbitrary category-token rows are not automatically the representations constructed in arXiv:2406.01506; no token-to-category estimator or paper-specific construction is included in the core feature.
TransformerBridge support and basis contract
Use the actual linear unembedding input after unfolded final LN/RMS, including its learned gain and bias. Do not automatically fold normalization, apply a cached activation scale, enable compatibility mode, move the model, or change training flags. Unembedding bias is excluded from the metric and must still be accounted for in logit readouts.
The supported Bridge contract requires a raw causal decoder with a direct LN/RMS-to-plain-linear vocabulary head and consistent d_model/d_vocab_out. Reject compatibility processing, final output projections, active soft caps, custom post-readout transforms, parametrized/custom-forward heads, and meta/offloaded readouts.
Earlier residual hooks are not automatically in this basis. Tensor compute policies support CPU/CUDA, but the current geometry validation is CPU-based; the core does not claim MPS support or universal architecture coverage. A selected token population changes the covariance estimator, and the paper's full-vocabulary assumptions do not automatically transfer to arbitrary subsets. Ridge also changes the metric.
Independent reproduction and behavioral validation
Pin reference revisions, model/tokenizer configuration, contrast data, preprocessing, and dtype. Check licenses before redistributing reference code/data; provide regeneration routes when redistribution is unavailable.
The paper derives interventions through Equation (4.1) and then measures their effects. Reproduce that approach:
- Measure target and off-target changes across controlled counterfactual token configurations and held-out contexts.
- Include unedited, no-op, and appropriate matched controls.
- Compare raw-geometric baselines and run conditioning/ridge sensitivity analyses.
- Establish tolerances from measured reference evidence.
- Report negative findings and limitations instead of requiring every concept or small model to show clean orthogonality or simplex structure.
A separately fitted contextual intervention estimator is a possible research extension, not a required existing author algorithm to port. Such an estimator would need its own identification assumptions, dataset, and evaluation protocol.
The issue is complete when the core feature is merged with required repository validation resolved and independent reproduction, controlled intervention results, sensitivity evidence, and reproducible artifacts or commands are delivered.
Alternatives
- Raw Euclidean cosine only: retain it as a baseline, but it does not provide an explicit covariance-based metric or dual-space conversion contract.
- Activation-covariance whitening: useful for other questions, but data-dependent and a different estimator from the unembedding-covariance metric proposed here.
- Vendor the authors' notebooks: useful as inspected references where licensing permits, but not a substitute for a maintained API with independent tests and an explicit support contract.
- Put geometry only inside a steering or probing tool: reduces reuse and risks inconsistent space/normalization semantics across consumers. Keep the numerical core independent; consumer adapters can build on it.
- Treat whitening identity as empirical validation: it validates arithmetic by construction, not concept separability or behavioral intervention effects.
Additional context
Validation should distinguish algebraic correctness from empirical model evidence. Synthetic fixtures should verify covariance construction, dual-space transforms, regularization, and categorical diagnostics. Download-free integration tests should exercise the TransformerBridge and tokenizer contracts. Independent reproduction and controlled behavioral experiments are required before making claims about semantic geometry or causal separability in pretrained models.
Hierarchical tooling, automated lexicon/template construction, steering/probing adapters, unrestricted multi-token concepts, and a universal support matrix are outside this issue. Dense covariance/eigendecomposition can be expensive despite requiring no training; resource limits and numerical policies must be documented.
Hierarchical tooling, automated lexicon/template construction, steering/probing adapters, unrestricted multi-token concepts, and a universal support matrix are outside this issue. Dense covariance/eigendecomposition can be expensive despite requiring no training; resource limits and numerical policies must be documented.
Checklist
- I have checked that there is no similar issue in the repo (required).
Repository searches for "representation geometry", "causal inner product", and "whitening" found no matching issue or PR. Related projection-kernel work is linked above and has a different scope.
Activity
jlarson4 commentedon Oct 12, 2026
@janmenjayap I appreciate all the proposals you are putting together, but I am going to start to put the breaks on them. The volume of proposals, the initial quality of the code, and amount of use these tools are getting thus far is not adequate to continue approving them without first assessing community need. I don't want to clutter the repo with a bunch of tools that people will not be using.
Going forward, I am going to wait until we have expressed interest in these features from the community before green lighting any additional
analysistools.I'd ask that you adhere to the following guidelines going forward
Proposal, wait for my approval before submitting them as PRs.Proposalsneed a specific set of PRs that will be included as part of the resolution, with defined start and end points, denoted with checkboxes.If you are a researcher using TransofrmerLens who would find this feature useful, please react to the initial Proposal with a 👍 . If I see a significant volume of reactions, I will green light the proposal.
janmenjayap commentedon Oct 25, 2026
Thank you for the candid feedback, @jlarson4, and for all the time you've put into reviewing my work over the past few months. I fully respect your responsibility for the project's direction, and I agree that gauging community interest before adding more
analysistools is a sensible approach. I'll follow all three guidelines from here on.That said, I'd like to share some context on the quality concern. Given my earlier experience on the project, the feedback came as a surprise, and I'll be honest that seeing it stated in general terms, without specific issues identified, was discouraging. I hope this context helps us reach a shared understanding.
Earlier reviews. The feedback on my merged PRs was consistently encouraging:
These comments, along with the merges, gave me confidence that my work was meeting the project's expectations, and I continued investing my time on that understanding.
Real-model validation. Most of my merged PRs included validation on real checkpoints, with the commands and measured results documented in the PR description:
gpt2-small(194,946 edges)gpt2-smallL9H9pythia-70mFor #1887, I ran the unit, docstring, acceptance, and integration tiers along with the MPS suite on real hardware, and reported the one unrelated failure transparently.
On process: for several earlier proposals I opened the PR alongside the proposal (#1720 → #1721, #1748 → #1749, #1767 → #1768, and #1777 → #1778), and those were reviewed and merged on that basis, so I continued the same pattern for #1880, #1883, and #1884. In hindsight, I should have opened those three as draft PRs, so the code was available for reference without asking for your review before the proposals were approved. That's on me, and I'll keep to approval-first from now on.
On AI assistance. I do use AI tools in my workflow, as many contributors now do. I review and revise the code myself, run the test tiers locally, and respond personally to every review comment. If any of my work came across as largely AI-generated with little human review, I would have genuinely appreciated hearing that on the specific PR or issue at the time, so I could have addressed it then. Hearing it now, framed generally and after the fact, is a little disheartening, given the effort I put into reviewing and validating that work.
The motivation behind these tools. Today, a researcher who needs several interpretability methods in one project, say the J-lens, R-lens, attribution patching, and SVD circuits, usually has to clone multiple research repositories, each with its own model wrappers, dependencies, hook conventions, and assumptions, and then glue them together by hand. My aim was for TransformerLens to provide a common ground: state-of-the-art interpretability tools in one maintained, Bridge-native library, working across the architectures it already supports, so researchers can spend their time on research rather than integration.
On scope. I built each of these as a
tools/analysismodule because that was the scope approved in the proposals. On #1755 and #1742 you gave the "green light on scope and API shape", and the follow-up PRs were reviewed and merged on that basis. #1907 later removed R-lens, about two and a half weeks after #1834 was merged, and moved Backward Lens and SVD circuits to demos. I recognise that the recompute concern on R-lens was raised during review of #1785, and I understand why changes to core components carry a higher bar. I'm glad to work toward a narrower, demo-focused scope, as you suggested on #1884. I would only note that, had the preferred scope been demo-only or narrower from the outset, I would have planned my work quite differently and spent far less time on the follow-up module PRs, tests, and review rounds. To help avoid this in future, I'd appreciate it if we could agree on the delivery format (module, demo, or script) at the time a proposal is approved, and if you could share how you conclude whether a tool is "too narrow" or "can be recreated using base-bridge functionalities", so I can design proposals with that bar in mind.Going forward, I will:
The issues #1880, #1883, and #1884 are kept open for community 👍 reactions. If you have any specific concerns about my merged contributions, I'd sincerely welcome hearing them so I can address them.
I've contributed to TransformerLens alongside other commitments, in good faith, because I value the project and its community. I genuinely understand how important a well-maintained, reliable TransformerLens is to today's AI safety and interpretability research landscape, and why keeping it focused matters. I have always appreciated your quick and thorough reviews, and the care you put into them. I'd very much like to keep contributing in a way that fits the project's direction. Thank you again for your time and guidance.