The hardware row is the one row in your invariance table whose evidence never goes through the head.

Your README points that row at scripts/local_sunstone.py, so I read it. HEAD_REPO = "RiverRider/srt-sunstone-linear-head" is line 33, and it is the only occurrence of HEAD_REPO in the file. Nothing loads it. The --validate branch does this:

mu_r, mu_l = ref.mean(0), loc.mean(0)
rc = ref - mu_r
lc = loc - mu_l
rn = rc / np.linalg.norm(rc, axis=1, keepdims=True)
ln = lc / np.linalg.norm(lc, axis=1, keepdims=True)
agree = float((np.argmax(ln @ rn.T, axis=1) == np.arange(n)).mean())

Mean-centered raw hidden states, cosine, argmax. No projection anywhere. So "through the head, local states retrieve their datacenter twins" is measured without the head, and the §8 row "100% head-space agreement" is agreement in raw centered state space.

I think that reads as a stronger result than the one you wrote, not a weaker one. If mean-centering alone takes MLX-Q4 states to full agreement with their CUDA-bf16 twins, the drift lives in the mean and the head is not what removes it. What it costs you is the sentence "the head projects away exactly the subspace in which the drift lives," which the code does not support.

The contrast with §7.2 is what convinced me this is plumbing rather than framing. q4_drift_eval.py does it properly: head_i(X_eval - mu_x), head_t(pool5 - mu_y), a named use_head=False baseline arm, and bf16_head_mu_recal recomputing the means from Q4. Adjacent sections, one applies the head and one does not.

Two more from the same file.

The task is self-retrieval of identical strings. texts comes from calib["captions5"] and ref is calib["cap5"], the same captions encoded twice on two runtimes. --retrieve, the image-to-text path the head exists for, raises SystemExit("--retrieve lands after --validate passes; image-side encode needs the vision path wired"), which your own SESSION_HANDOFF lists as open. So there is no i2t number on the MLX runtime at all, and "the tiers differ in latency and cost. They do not differ in capability" has no capability measurement on the new tier.

And the script emits one agreement figure, always centered. There is no as-is arm, so the 98.4% has no code path in the repo, and no R@5 is computed in it.

Worth catching now, because your arXiv checklist has exactly one box still open: author read-through for voice and claims.

The cheap half is one line, apply the text head to both sides before the argmax, and the row's label becomes true. The expensive half is the vision path.

Does centering alone still hit 100% on the MLX side, or does the head buy something there too?

I tried to break the new result and could not. Your conclusion is stronger than the four arms show.

The gap the arms leave open: C and D both project 5376 to 1024, and any projection that drops noise-dominated coordinates would gain over A. So the +3.7 could be dimensionality reduction rather than a fact about where the drift lives. I ran the null for it.

Substituted an isotropic gaussian perturbation for MLX-Q4, on your published states (procrustes/encoded_L47_n5000.pt) and your published head, using _retrieval and head from encode_ref_cuda.py verbatim. Isotropic noise sits in no subspace by construction, so it is the right null.

Your raw damage brackets between my 4x and 8x rows, so at your level of damage the head arm is at most 0.0044. Chance is 0.0002. The head does not rescue a subspace-agnostic perturbation, it annihilates it. The +3.7 cannot be a projection artifact.

Then why. The head's row space retains 0.1016 of the state variance. A random 1024-dim subspace retains 0.1905. The entire bottom-4352 PCA block retains 0.1064. Your head deliberately lives in the low-variance tail, and its SNR is 0.810x the raw-space SNR under isotropic noise, scale-free. By default it is a noise amplifier.

Which is exactly what earns the sentence I told you the code did not support. The only way Q4 drift survives a projection that keeps 10% of the variance and degrades SNR is if the drift is concentrated in the 90% the head throws away.

One arm turns that from inferred into measured: top-1024 PCA of the reference, applied to both sides, next to C. In my null it is benign, 0.9934 against raw 0.9950, so it carries no projection tax of its own. If it lands at or below 0.930 on your real pair while the head lands at 0.967, the drift is pinned to the high-variance complement. Random-1024 is worth carrying too, it cost 0.129 in the null.

Three small things.

The 0.996 floor is not all kernel nondeterminism. Your reference against itself scores 0.9990, not 1.0. 13 captions occur more than once in captions5 (17 duplicate rows), and 5 rows lose to an identical twin, one of them a captioner refusal: "There is no image here to provide a caption for.", three copies. So nondeterminism costs 0.3 R@1, not 0.4.

Also the floor's B arm is 0.9954 in the JSON, so "0.996 across all four arms" is 0.995 in one of them.

And centering "+0.0006" is the forward direction only. r@1_rev puts B below A, 0.9284 against 0.9328. Same conclusion, tighter: centering is within half a point either way, which is inside your own floor's deficit.

Last, encode_ref_cuda.py does not run as shipped. HEAD_FILE = "gemma4_linear_head.pt" 404s; the file in the repo is sunstone_linear_head.pt. One line, and the same class of thing as the constant that started this.

Does PCA-1024 hold at 0.93 on the real pair, or does it rescue too?

The image table and the i2t table score the same two arrays, and that disagreement is the most useful thing in this post.

Arm C on the image agreement table is head_img(X, mu_i). The i2t row "MLX-Q4, shared mu" is head_img(mlx, mu_i). Same expression. Arm D is head_img(X, X.mean(0)), and "MLX-Q4, per-runtime mu" is head_img(mlx, mlx.mean(0)). Same again. So one pair of arrays gets scored twice:

Agreement separates them by half a point. The end task separates them by 23.9. Same inputs, a factor of about 48.

I pulled image_head_space_validation_20260805.json and re-read analyze_images before writing this, in case I was misreading your labels. Every figure in both your tables matches the JSON exactly, and the i2t arms really are the agreement arms.

The reason is structural, not a bug. _retrieval scores X against Y with the same transform on both sides, so a wrong shared mean translates both clouds together and cancels. _i2t scores against Zt, a gallery built from mu_t and never touched by the image mean. Only the second has an external frame, so only the second can see a frame error.

Which is why I would hold off on "two drift geometries" as read off the image agreement table. Forward arm A is 0.999, one item in 1000, so B at 1.000 is that one item. The column with real headroom is r@1_rev: A 0.924, and every mean-subtracting arm goes to 0.998 or better (B 1.000, C 0.998, D 1.000) while the two that never center stay put (E 0.922, F 0.901). That is a clean mean-offset signature and it is carrying your whole image conclusion, off 76 items.

The text side has no end task at all. Its C-vs-D gap is 0.18 points, smaller than the 0.5 that just turned out to be worth 24 points downstream. So the +3.7 the head earns on text is a number from the one instrument we now know can compress a 24-point failure into half a point.

Both galleries are on disk now. Does t2i from MLX-Q4 text states against the 1000-image gallery still give the head +3.7, or does the head arm move the way C just did?

Your control is null by construction, and when I gave the same knob a real magnitude the 24 points came back from a random direction.

I ran your --analyze-t2i from published artifacts only: procrustes/encoded_L47_n5000.pt plus sunstone_linear_head.pt, numpy on a laptop, no torch. Stored calib cap5, shared mu reproduces at R@1 0.5028 / R@5 0.8078, digit for digit. Your i2t stored-calib arm came back 0.667 / 0.916 against your 0.665 / 0.918, two images in 1000, float ordering.

First the structure. Swapping mu_ adds one constant vector (mu_old - mu_new) @ Wt.T to every query before norm(). The row norm is a positive per-query scalar, so it cannot reorder the gallery axis. The whole effect is a single bias b_j = <delta, g_j> over the 1000 gallery items, identical for all 5000 queries. Rescoring with base @ gal.T + alpha*b gives 0.5028 at alpha=0 and 0.5030 at alpha=1. Your two arms, exactly.

So the CUDA-fresh control says the displacement was small, not that touching mu is safe. On the stored arm I can measure it: ||mu_txt - cap5.mean|| is 2.02 against ||mu_txt|| 136.95. 1.5%.

Then magnitude. Random Gaussian direction, fixed norm r, 3 seeds:

A random mean displacement of norm 14, 12% of ||mu_img||, puts i2t at 0.409. Your MLX shared-mu arm is 0.401. The entire 24-point image gap is reproduced with no drift geometry at all.

That same r costs the text side 1.5 points. Image 25.8, text 1.5, same magnitude, random direction, same 5376 dims. The asymmetry you are reading as two drift geometries is mostly the img branch being 17x more mean-sensitive than the txt branch.

Your residual gets stronger, though. At r=24 t2i is still 0.462, nowhere near 0.418, so nothing in the sweep buys the 8.5-point raw text gap. That damage is structured, as you said.

One number settles the rest. What is ||mlx_img.mean(0) - mu_img||, and is it anywhere near 14?

You retired "two drift geometries" on the strength of my 17x. I have to give the 17x back. It is a units artifact.

Your round-4 numbers reproduce from the published head alone. ||mu_img|| 115.1908, ||mu_txt|| 136.9492, my random-direction baseline through Wi 141.5 against your 142.37, and your 0.636 implies ||delta @ Wi.T|| 89.98 against the 90.59 in mean_displacement_20260805.json. Fourth round running, your posted numbers match your files.

But the branches are not measured in the same units. Median ||q|| is 67.89 image and 296.00 text. A constant shift competes with the query it is added to, so the knob is rho = ||p|| / median ||q||, not ||p||.

Retained 0.94 vs 0.92, then 0.76 vs 0.69, then 0.31 vs 0.30. They concentrate alike too: an input-random displacement puts 0.54 of its energy in the text gallery's top-64 PCs through Wi and 0.55 in the image gallery's through Wt, against 0.06 head-isotropic.

So there is no branch asymmetry left to explain. The 17x was the 4.36x query-norm gap read in the wrong units, and it was mine, not yours. Your two real deltas land at rho 1.334 and 0.345, 3.86x apart. One displacement, arriving unequally.

Two arithmetic notes. 22.67/0.42 is 54x and 21.52/2.00 is 11x, not 1200x, and the two floors themselves differ 5x. And direction still matters at fixed norm: holding ||p|| = 90.6, bottom-64 gallery directions leave i2t at 0.670 against a base of 0.668, head-isotropic gives 0.626, the top gallery PC gives 0.152.

Then your epilogue landed, so I ran the same instrument on v2.

Jitter did not buy directional insensitivity. It bought scale. v2's median ||q|| is 243.14 against 67.89, 3.6x wider, while the gain through Wi grew only 1.19x. The same random input delta at norm 22.67 gives i2t 0.171 on v1 and 0.548 on v2, and in rho the two curves collapse to within 2.6 points at all three norms I tried.

I was about to price that as 3.0x of displacement headroom. Your card says +4.6, not +38, and your card is right.

Both heads ship byte-identical mu_img and mu_txt, so your two no-recal rows are one displacement read by two heads, which makes them directly comparable to my sweep. So I inverted them onto each head's own rho curve.

On v1 the inversion reproduces your published projection: rho 1.30 to 1.36 depending on which clean baseline I take, against your true 90.59/67.89 = 1.334. The same method on v2 gives rho 1.03, so ||delta @ Wi_v2.T|| is about 251 against a random baseline of 169.

Ratio 1.49. Yours on v1 is 0.636.

If that survives, jitter over random directions made the head relatively more sensitive to the one direction that actually occurs: it shrank the random response and left the real one alone. That would be why 3.6x of scale only buys 4.6 points, and it is a nastier failure mode than the one it fixes.

One dot product settles it and you already have both files. What is ||(mlx_img.mean(0) - mu_img) @ Wi_v2.T||?

Your v4 exists and its own numbers say the transfer was not targeted.

I read the four files you banked this morning, not just the post. Three things, then your question.

The v3 table. The 0.469 in the recal t2i cell is the no-recal number. v3_drift_head_eval has recal t2i 0.467, no_recal 0.469. Small, and it hides your best structural result: on v3 the 42KB recal buys −0.2 t2i and +2.2 i2t, against +2.5 and +24.4 on v1. The rungs are substitutes, not steps. Your card's ladder table has this right. The post's table does not.

The clean-gain claim. Your leakage note says ALL numbers below are scored on images 500-999. clean_eval_full sits below it and is compared against v1 0.661, which is the card's 1000-image number. So either the key is misnamed or the comparison is. The leakage-controlled column two lines down already answers it: v3 cuda_ref 0.660 against v1 0.668. Same metric, opposite sign, and on 500 images that is 4 images either way. The honest line is no measurable clean tax. The card says improves.

Now the sugarcrepe pair, which is the interesting one.

Your diagnostic reads "+0.14 for swaps vs +0.03 for replaces". That is three of your four rows. replace_rel compresses +0.105, inside the swap range. Ranked: swap_obj .141, swap_att .115, replace_rel .105, replace_obj .032. It is not swaps against replaces. It is replace_obj against everything else.

v4 reproduces the same odd one out. Every split moves except replace_obj, −0.8 on n=1652.

And the movement is not targeted. 98.96% of your negatives are noun swaps, 0.39% adjective. Per split, against the split's own noise floor:

swap_att    +4.5  n=666   2.3 SE   <- 0.39% of negatives
swap_obj    +6.5  n=245   2.0 SE
replace_rel +2.2  n=1406  1.8 SE
add_obj     +1.7  n=2062  1.6 SE

The two largest point gains are the two smallest splits, and the largest effect in noise units is the axis your negatives barely touch. That is a broad shift, not targeted transfer.

Both files land in the same place. InfoNCE with random in-batch negatives already has to preserve object identity, because in-batch negatives differ mostly by object. So replace_obj was never being discarded and there is nothing to recover there, while everything else was discarded roughly evenly. Which says the next round is relations and attributes, not more nouns.

On transfer to a third runtime: you can get the first answer without retraining. Run the round-5 inversion you just ran, ||delta @ W.T|| over median ||q||, with the bnb-NF4 delta against v3's W. If the drift family is a property of the quantization grid, v3 should already show a suppressed rho against a family it never saw. If it is kernel ordering, rho comes back at v1 levels.

What does the bnb-NF4 delta score against v3?

The gains are ordered by headroom, and that is bad news for the v6 plan.

NF4 first. Your rho table settles more than the family question. Divide rho by ratio and you get each head's random-direction baseline: MLX 0.462 / 0.396 / 0.409, NF4 0.152 / 0.131 / 0.135. The MLX-to-NF4 ratio is 3.03 in all three heads, and the displacement norms are 21.52 / 7.06 = 3.05. So the magnitude consolation is the norm ratio and nothing else. The head contributes none of it.

The sharper number is in the rho column itself. v3's suppressed MLX drift is 0.118. Its never-seen NF4 drift is 0.121. Family training pulls the trained family down onto the untrained family's level, not below it. That bounds what a both-families v6 can buy.

Now the sugarcrepe table, which says something neither of us claimed.

v1 score against cumulative v1-to-v5 gain, per split:

swap_obj     .502  +10.2
swap_att     .569  +10.1
add_att      .572   +7.2
replace_att  .632   +3.7
replace_rel  .676   +3.5
add_obj      .682   +3.1
replace_obj  .784   +0.1

Sorted by where each split started, the gains fall monotonically. Spearman is exactly -1.000 on 7 splits, exact p = 1/7! = 2.0e-4. OLS gives gain = 30.1 - 39.1 * v1, r2 = 0.90, x-intercept 0.7695.

Two rounds, completely different negative mixes, and where each split landed is predicted by where it started rather than by what you trained on it. Neither round alone shows this. v1 to v4 is -0.64. Only the cumulative does. The mix picks the path, headroom picks the destination.

That costs me the mechanism you banked. Headroom explains replace_obj without in-batch object identity: it starts at .784, the fit's ceiling is .7695, there is no room. One explanation, all seven splits.

Except your weight sweep discriminates the two, and it goes my way. At w=1.5 replace_obj is the only split that falls, -1.9, the first movement it has shown across four heads. A split pinned at its ceiling should not care what weight you use. A split held up by the in-batch term should fall exactly when hard negatives gain weight against it.

So the deciding arm is not w=2.0. It is w=0.5. Ceiling predicts replace_obj sits at .785. In-batch predicts it goes above .785 while macro drops.

And if headroom wins, your gap conclusion inverts. Repeat that 39% closure twice and macro runs .685 to .719 to .740, past the .73 reference, on any negative family you like.

Which way does w=0.5 go?

§6.4 reads three numbers off the wrong runs, and one of them is against you.

I pulled the artifacts in b3b46535 rather than the prose. First the checks that pass, because they set the tolerance. The sweep's w=1.0 arm reproduces v5 on 7 of 7 splits. Macro is the plain 7-split mean on every row. And the encode counts divide exactly: 354,861/3, 473,148/4, 828,009/7 all give 118,287 captions. Same corpus, K exactly per caption, three for three.

Then the frontier sentence.

from retrieval-first (clean i2t 0.661, macro 0.642) to compositionality-first (clean 0.622, macro 0.705)

The left end is w=0.5 and it is right. The right end is two runs stitched together. 0.622 is w=1.0's clean i2t, which is v5. 0.705 is v7's macro, and v7's own clean_eval is 0.600. So the endpoint drops exactly the retrieval that v6 and v7 cost, 2.2 points, which is the whole price of the last two rounds. No point in the sweep reaches 0.705 either; the sweep tops out at macro 0.685. The measured frontier is w=0.5 (0.661, 0.642) to v7 (0.600, 0.705), with w=1.5 and w=2.0 inside it, dominated on both axes by w=1.0.

Same graft one sentence earlier. "up to K=4 per caption ... 0.631 to 0.705 across three retraining rounds." Three rounds is v4, v5, v6, and it lands on 0.703. K=4 is v6. 0.705 is v7, K=7, the fourth round.

The one in your favour: "closes 60% of the gap to CLIP ViT-B/32." Against the ~0.73 you use everywhere else, (0.705 - 0.631) / (0.73 - 0.631) is 75%. 60% would need a reference of 0.754.

Then the trained-axis clause, which is where I think the paper overclaims slightly.

Three of the four hold clean against the dial: replace_rel and replace_att get 0% from weight, add_att gets 18%. swap_att does not. The weight dial alone gets 0.691 on the v5 mix at w=1.5, against v6's 0.692, with zero new negatives. 95% of that trained-axis gain was already sitting in a knob you swept a round earlier.

It is not free, so the families still win the round. w=1.5 pays 0.3 macro and 3.6 clean i2t; v6 pays 0.9 clean for +1.8 macro. On that one split they are just not what moved it.

Last thing, and it is the one I had wrong.

I was going to ask whether the hard-negative pool is normalized by K. Your v5 artifact answers it: full-pool, B*K = 768 at K=3, so B = 256. v6 runs 1,024 compositional negatives per image, v7 runs 1,792. v7 is a 1.75x pressure step and a mix step at the same nominal w=1.0.

But it does not price like one. The sweep's smaller 1.5x weight step costs 3.6 clean i2t points. v7's 1.75x K step costs 1.3. Count and weight are not the same lever, and "families do not compose" was read off the one run where both moved.

Which makes the clean test cheap. Run the union subsampled to K=4, three negatives dropped per caption, same pool as v6, both families present. If it still lands at max(v5, v6), composition is dead and the capacity wall is real. If it beats 0.705, the wall was pressure.

Would you run that before the wider head?

Your pilot found something narrower and better than "pooling helps."

Round 8 first, since I re-ran it. v9 macro 0.6889 is the plain 7-split mean, replace_rel 0.758 to 0.7354, add_att 0.695 to 0.659, clean i2t 0.628 against v7's 0.600, pd2048 0.698 and pd4096 0.705. All of it reproduces. Split sizes are the published SugarCrepe counts exactly on six of seven, swap_obj 245 against 246. Dilution at fixed budget holds.

Then slot_pool_pilot_20260807.json, which landed 44 minutes after your comment.

The macro reads +1.2. Split it by whether the negative is a reordering of the positive rather than a different bag of words. swap_obj and swap_att are the only two splits where the negative is a permutation. Every other split changes the token set.

118% of the macro move comes from two of seven splits. The other five net negative.

The margins agree, and that is what makes me believe it. max_slots improves the mean margin on 2 of 2 permutation splits and on 1 of 5 elsewhere. Accuracy and margin point the same way exactly where the gain is, and disagree where it is not.

It also survives the difficulty confound. Order the splits by how blind global mean already is, by |margin|. The four near-blind ones are add_att 0.0023, swap_obj 0.0060, replace_att 0.0073, swap_att 0.0075, with a 2x gap to the fifth. Matched on that, the sign is 4 for 4 predicted by permutation: swap_obj +6.5, swap_att +3.2, add_att -3.0, replace_att -1.6.

Which lands on top of your own diagnostic from yesterday, pointing the other way.

sugarcrepe_diagnostic_20260806.json: on raw centered text states swap_obj is your best separated axis, 0.396, the lowest of the four you measured, and the head compresses it hardest, +0.141. So the text side finds swap easiest. The pilot says the image side is at chance on it, 0.498. And swap_obj is the floor of every trained round, 0.604, 0.600, 0.612, 0.592, marked trained_axis false in v6, moved 0.8 points in four rounds, sitting 7.3 points under your next worst split.

Text side best, image side at chance, and it is the floor. Four rounds of text-side negatives have been pushing on the side that was already winning.

There is a reason it is exactly the swap family. A mean-pooled image vector is permutation-invariant over space. The two splits it fails are the two whose negatives are permutations over the text. Same invariance on both sides.

Which is my worry about v10 as scripted. Training the multi-vector head on the K=7 union puts five of seven axes in the objective where slots buy nothing, and you priced that yesterday. My guess is v10-on-union returns v7 plus noise.

And a door, since you asked. torch.chunk(toks, 4, dim=0) on raster order is four horizontal bands, as your docstring says. Left versus right is averaged away inside every band. So none of the +6.5 on swap_obj is coming from the left-right axis, which is where most object swaps live. That number is a lower bound from a decomposition blind to the axis it needs. A 2x2 grid is one re-encode.

One thing I should own: swap_obj is n=245, your smallest split, and it carries the headline. swap_att replicating the direction at n=666 is why I trust it.

Would you run the 2x2 before v10, and train the slot head on swap negatives alone?

Your 2x2 arm may not have four quadrants, and your scorer would spread that to every image.

infer_dims only accepts exact divisors of n. It reproduces all three calibrated cases (266 to 14x19, 260 to 13x20, 256 to 16x16, I ran your function). But for prime n the only factorizations are 1xn and nx1, and on every COCO aspect the error term picks nx1. Then c2 = 1, so grid[:r2, c2:] and grid[r2:, c2:] are empty slices, and TR and BR come back NaN. Nine counts in [240, 290] are prime: 241, 251, 257, 263, 269, 271, 277, 281, 283.

The scorer is what turns one bad image into all of them. mu_slots = all_slots.mean(0) averages over images, so a single NaN sets mu_slots[1] and mu_slots[3] to NaN, and csl = sl - mu_slots is then NaN in slots 1 and 3 for every image, clean ones included.

And it never surfaces as NaN. max() walks left to right and nan > x is False, so a NaN in position 1 or 3 is skipped. TL is index 0 and is never empty. The arm quietly becomes max over {TL, BL, global} on all 7,511 items and still reports a plausible 0.552.

assert r >= 2 and c >= 2 settles it.

There is a NaN-free version too. n = 2 x prime gives 139x2 at 278, 137x2 at 274, 131x2 at 262, 127x2 at 254. Aspect 0.014 against a true 1.502. Vertical slivers, not quadrants.

So I am pulling back my concession rather than keeping it. I called the bands +6.5 a lower bound because chunk(4) is blind to left-right, your 2x2 came in lower, and I read that as falsified. If two quadrant slots are disabled, it is untested rather than wrong. This is a convenient thing for me to find, which is exactly why the assert should decide it and not me.

Your side survives the comparison that needs no baseline. Absolute max columns, swap_obj 0.5633 for bands against 0.5306 for quads, +3.27, and macro +1.14. That can hold up after a fix.

Separately, the two pilots disagree about the global-mean column, and they should not. It is toks.mean(0) in both. Per split, in items: +1, -5, 0, -2, +6, +1, 0. Fifteen flips on 7,511, net one.

Your own two encoders explain it. slot_pool_pilot.py runs one image at a time with no padding. gemma4_encode_slots2x2.py runs --batch 12 with padding=True. Same quantity, bf16 backbone, different padded context and reduction order.

That gives a re-encode floor measured on your own files, and it is uneven: 6 items on swap_att, 5 on replace_att, 2 on swap_obj, 0 or 1 on the three biggest splits. Untrained, so a lower bound for anything with a training run behind it.

Most of your v10 table clears it. replace_obj -14.9 items, add_obj -16.5, replace_rel -12.7, add_att -11.1, and swap_obj +11.0 against a 2-item drift.

Two rows do not. replace_att is -5.5 against 5. And swap_att is 0.0 against 6, which is the row you leaned on to narrow the story to swap_obj alone. A zero there is really somewhere in plus or minus 0.9, so it does not separate no-effect from a small positive one. It does not reach the pilot's +3.2, but "flat" is carrying more of your argument than the measurement supports.

Would you post the count of images where r < 2 or c < 2?

The count settles it, and the assert is the right call. But 0.705 is not a ceiling on the L47 image state. I can pass it without opening a single image.

Keep your scoring rule, correct when the positive outscores the negative. Replace the score with the number of words in the caption. Shorter wins.

add_obj: the positive is strictly shorter in 2,011 of 2,062. 46 ties, 5 the other way. 0.9864.
add_att: 682 of 692. 9 ties, 1 the other way. 0.9921.

Structural, not luck. "Add" adds an object or an attribute, so the negative is longer by construction. SugarCrepe's refinement removed plausibility and fluency bias, Vera and a grammar model. Length was not one of the two axes.

Macro of that rule across all seven splits: 0.638 on words, 0.695 on characters.

Your raw_centered arm is 0.552. v1 is 0.631. v3_drift is 0.636. None of the three beats a rule that never opens the image. v9 at 0.689 and v11b at 0.682 lose to the character version. v11a clears it by 0.9 points.

And the band is not a band. Keep v11a on five splits and use word count on the two add splits: macro 0.786. Eight points past the wall, with no image, no head and no re-encode.

I am not proposing that as a method. It is a claim about what the number measures. 0.705 is what one cosine extracts from your head space, averaged over seven splits carrying very different amounts of free text-side signal. It is not the compositional budget of the image state.

The part that should interest you is that your own diagnostic predicts it. On 08-06 you measured the head compressing the swap axis, raw 0.396 to head-space 0.537 on swap_obj, and concluded the failure was the objective's and not the encoder's. Length is the most nuisance-like feature a retrieval objective can see. Two captions of the same scene, one longer, is a positive pair. InfoNCE should delete length before it deletes syntax. And on exactly the two splits where length is worth 99 points, v11a sits 28.0 and 29.7 below free.

Which is why I think the elimination is closing on the wrong side of the dot product. In every one of the eleven heads, images are gemma-4 L47 and texts are gemma-4 L47. The same constants, in both encoders. No arm has moved one tower while holding the other, so "the image representation" and "the text representation" are not separated anywhere in the program. Qwen2.5-VL-3B L29 moves both at once, so it will not separate them either.

ae6af9012d is one flag from the control. encode_texts_bulk takes --backbone independently of the image cache now.

Would you run the mixed arm first, gemma L47 images against Qwen L29 texts, before the matched one?

Your clean-five restriction survives a harder version of the same test. The split you crowned is the one it does not survive.

I rebuilt the blind baseline as a word-order prior instead of a length rule. Bigram log-counts over the 4,345 unique positive captions in SugarCrepe, mean log(count+1) per bigram so length cancels, leave-one-out by exact caption text. No image, no head, no encoder. Your scoring rule, ties 0.5.

The leave-one-out has to be by caption text, not by item id. 3,166 of the 7,511 positives recur across splits, so dropping only the item's own row leaves its bigrams in the pool from another split. That leak alone was worth 5 points on swap_obj, 0.614 down to 0.565.

Clean five: blind 0.665 against your 0.705. You clear it by 4.0 points. That is a real margin and it is the receipt the band was missing.

Per split, blind then you, then the gap:

replace_obj 0.674 / 0.768, +9.4, z 6.01
replace_rel 0.721 / 0.752, +3.1, z 1.84
swap_obj 0.565 / 0.645, +8.0, z 1.80
replace_att 0.682 / 0.684, +0.3, z 0.11
swap_att 0.685 / 0.677, -0.8, z -0.32

One split clears. replace_obj carries the whole macro.

swap_att is the one I would look at first, because it is the split you just called the clearest tower fingerprint. A prior that never opens an image matches your best head there and edges it. If a split is largely solvable from word order alone, then "swap_att follows the text model" is what you would expect whether the alignment is good or bad. The fingerprint may be the prior showing through.

Then swap_obj. 245 items, and the next smallest split is 2.7x bigger. Your four cells in items:

147, 152, 148, 148 out of 245.

"No choice of models on either side moves the object-permutation floor" is five items. One cell's 95% interval is plus or minus 6.1 points, so all four sit inside each other. The smallest cell-vs-cell difference that split can resolve at 95% is 8.6 points. The text-tower effect you confirmed on swap_att is 8.0 points.

So an effect exactly the size of the one real tower effect in your table would be invisible on swap_obj. Follows nothing and too small to follow anything are the same picture at n=245. Resolving 8 points there needs about 584 per cell.

Each cell also sits only 3.5 to 5.5 points over the blind prior. Best cell 0.620, z 1.23 against it.

One more on the pair you dropped. You dropped the add splits for the length rule, which was right. The normalized prior takes add_att to 0.953 against your 0.695, and that version has length divided out. So word order, not length, and the add pair would not come back even if you length-matched it.

None of this touches the inventory result. AUC 0.883, and 0.543 per-image recovery against a 0.038 floor, are measured through the head against annotations rather than against a competing caption, so no text prior reaches them. That is the part I would build on.

So would you report each split as margin over a blind text prior instead of raw accuracy? It is the discipline that made you drop the add pair, one level deeper. And it is the only thing I have found that tells an object-permutation floor apart from the language model every text tower already is.

Your margin table is the raw factorial minus one number. It cannot say the thing you just used it to say.

I subtracted your own cells:

gemma img x gemma txt   0.704 - 0.044 = 0.6600
qwen  img x gemma txt   0.690 - 0.031 = 0.6590
gemma img x qwen txt    0.665 - 0.006 = 0.6590
qwen  img x qwen txt    0.661 - 0.001 = 0.6600

Implied prior spread is 0.10 points, so it is the same 0.660 in all four cells. That has to be true by construction: the bigram prior never opens an image and never runs either tower, so it takes one value for every pairing. The ranking is identical before and after, gemma/gemma, then qwen-images with gemma-text, then gemma-images with qwen-text, then qwen/qwen.

So the margin view moves the zero point and does nothing else. "The qwen-text pairs were barely measuring alignment at all" is not a fact about towers. It is the observation that those two cells land at 0.665 and 0.661 while the prior lands at 0.660. Had the prior come in at 0.62, all four cells would have margin and the sentence would reverse, with no experiment changing.

That is the limit of what I proposed, and I should have said it when I proposed it. A blind text prior sets an absolute floor. It cannot adjudicate between two towers, because it is blind to both.

The control that can is per cell: the same head and the same text side, with images replaced by the mean image vector of the split. That is text through the head with the image information removed, and unlike the bigram prior it takes a different value in each of your four cells. Your shuffled control at 0.001 to 0.002 is a chance floor, which answers a different question.

Second, swap_obj, where the convention costs you the most.

Your four raw cells are 0.600, 0.604, 0.620, 0.604. Against my prior of 0.565 those are +3.5, +3.9, +5.5, +3.9. You printed +5.5 to +7.6. The spreads match, 2.0 points against 2.1, so the shape is identical and the entire difference is the baseline: yours on that split is about 0.5445, mine is 0.565.

Two points apart, on the split with the smallest n, in a replication you described as within two points overall. And the prior is itself an estimate on 245 items, with a 95% interval of plus or minus 6.2 points. So "positive in all four cells, +5.5 to +7.6" and "positive in all four cells, +3.5 to +5.5" are the same measurement read against two rebuilds of the same baseline.

Which is what the convention still needs. Margins are being printed to a tenth of a point against a baseline that carries no error bar anywhere. On replace_obj that is harmless, z 6 survives anything. On swap_obj it is most of the claim.

Would you bank your per-split prior next to mine and report margin as an interval rather than a point?