DISCOVERING THE MAP · SENSITIVITY-1A/1B/1B′/1C · RECORDED · GRANITE-4.1-3B
WE CAN STORE A PRECISION MAP. BUT WHO WRITES IT?
The quantization chapter ends at the map — representation decisions over components, held to evidence. This is the harder question underneath it: can anything cheap discover those decisions automatically? Four attempts, each measured against ground truth. Four instructive failures.
Why can't we automatically build the precision map yet?
Because every cheap signal tried so far measures the wrong thing. Weight error alone carries no semantic signal — a fixed relative grid makes every tensor's error nearly identical. Normalised activation error rewards small outputs. Absolute local consequence almost works, but confidently protects down_proj — the one tensor where protection measurably makes quality worse — because a local score cannot see where an error lands in the computation. And replaying errors through the remaining layers costs five times more than just measuring the truth.
recorded — granite-4.1-3b · the SENSITIVITY programme vs the banked Q-BANK sweep
THE GROUND TRUTH, AND ITS PRICE
The bank measures a candidate the honest way: compile it, run it, compare probability distributions position by position. About one minute fifty-one per candidate on the 3B model — fine for fifteen candidates, hopeless for the real problem, which is combinatorial: every projection at every depth. So the question became: can something cheap rank candidates the way the bank ranks them? Before any screen produced a number, the bar was frozen.
THE BAR — FROZEN BEFORE ANY SCORE EXISTED
1. It identifies late-FFN as the highest-return region.
2. It rejects v_proj, k_proj and down_proj as low-value.
Both, or it is not a predictor.
The second half is the trap. A screen that merely learns “protecting more bytes helps” would be true, useless, and would pass any correlation test — the three frozen negatives are what it has to avoid.
Four screens walked at that bar. Here is how each one scored.
recorded — granite-4.1-3b · SENSITIVITY-1A/1B/1B′/1C vs the banked Q-BANK sweep · applicability to other models unestablished · tap a screen
The third screen is the interesting one — right form, one devastating counterexample.
MEAN LOCAL CONSEQUENCE, PER PROJECTION — RECORDED · GRANITE-4.1-3B
the screen says: protect down_proj. the bank already measured that: +1,150 MiB, and the tail gets worse.
This is not noise — it is a screen being confidently wrong for a structural reason. Local consequence measures where quantization error is large. It does not measure whether the model's output is sensitive to error there. The difference is not local, and the next figure is why.
WHY: TWO ERRORS, TWO FATES — THE RESIDUAL STREAM
gate → SiLU · up → ⊗
an error HERE crosses a nonlinearity
— it changes what the network computes. Small error, large meaning.
down → ⊕ into the stream
an error HERE joins a much larger signal
— added to what was already computed, and the layers downstream mostly absorb it. Large error, small meaning.
down_proj writes into the residual stream: its error, however large, nudges what has already been computed. An error in gate or up goes somewhere else entirely — through a nonlinearity, where it changes what gets computed at all. A local score cannot tell those apart, because the difference isn't local.
Local consequence measures where the error is large — not whether the output is sensitive to it.
THE FRONTIER — OPEN, AND MARKED AS SUCH
One route remains that survives the analysis. Against a KL metric, first-order sensitivity is identically zero — a divergence is stationary at its own reference — so the leading term is second-order curvature. That sounds expensive, but the curvature matrix factors exactly: draw a random vector, shape it by the model's own output probabilities, push it backwards through the network once, and sensitivity arrives at every layer boundary simultaneously. The catch: it needs reverse-mode execution the reference implementation does not have. That is a research programme, not a feature — and it is filed on the Record as exactly that: candidate, not built.
Measurements can justify a precision map. VINDEX3 can express, compile and execute that map. Cheap surrogates cannot write it — what writes it is a search that pays for real composed measurements.
The sequel exists: REPRESENT abandons the cheap-surrogate hope this page falsified and searches with real evidence under a frozen behavioural contract — judging composed maps, because the composed model is the only honest judge. Its first earned topology is on the Record.
PUBLISHED 30 AUG 2026 · REVISED 31 AUG 2026 · VERSION 3.0 Candidate
CITEsite build 43a1b6b · built 2026-09-02
CITE THIS
Web page · 3.0 Candidate
Hay, C. (2026). Discovering the Map. In VINDEX3 Specification (Version 3.0 Candidate). VINDEX3. https://vindex3.org/discovery
A chapter of the specification, citable on its own. Cite the version rather than the site — the canonical reference, and how to use it, live at /cite.