Dipankar Sarkar PRO

Rule 4 has one more customer, and it is the null you published in this message.

You ran the zero mass, concluded the contrasts are not about the collision rate, and cited Fisher p = 0.66 and 0.55. That is a null read without its floor, which is the thing this whole exchange has been about. I pulled your two files off the Zenodo record and reran masse_en_zero.py: every number reproduces, 0.700, 0.01479, 0.01035, 147 positives, CV 0.83.

Then I computed the floors you did not.

The CV you want to pre-register is one third point mass

Your relative floor needs a stable CV. The mixture CV is not one quantity:

CV_mix^2 = CV_pos^2 / p  +  (1 - p) / p

  CV_pos^2 / p     0.9736
  (1 - p) / p      0.4286      <- pure Bernoulli, no scale in it
  sum              1.4022      measured CV_mix^2  1.4022

Exact, on your 210. So 30.6 % of the CV^2 you would write into a design document is the collision rate, and CV_mix = 1.184 is your 1.2.

That matters because the two halves have different consumers, which is your own point from this message. Pre-registering on the mixture prices a floor for neither.

Split it and the design gets sharper, not weaker

                              floor / mean   at 30+30 seeds
mixture (your 0.89 line)          0.856
E[gap | collision]                0.713      on E[n_pos] = 21 per cell

Dropping 30 % of the runs buys a 17 % finer floor, because the variance you drop is larger than the n you drop. Treating E[n_pos] as fixed at 21 rather than random, so read it as the leading term.

The other half has no resolution at all

Same construction, delta = 2.80 x SE, applied to the proportion:

cells        detectable only if the rate rises to   or falls to
beta 30+30              0.956                          0.361
R 25/24 53+47           0.916                          0.433

Observed rate 0.700, and the parameter stops at 1.000. The detectable upward window is [0.956, 1.000], which is 15 % of the headroom that exists. At 53+47 it is 28 %.

So Fisher p = 0.66 is not evidence that the R contrast is not carried by the zeros. It is the same reading you retracted for observed power, on a test whose floor is most of the parameter space. The share estimates say the same thing once they carry an interval:

contrast          zero share    bootstrap 95 % CI    Fisher p
R 25 vs 24            13 %        [1 %, 52 %]         0.660
beta .005/.03         17 %        [0 %, 56 %]         0.552

A share whose interval runs to half cannot support "they are about the size of the inflation when it happens".

What I think this costs you, and what it does not

Not the decomposition. P(collision) = 0.700 and E[inflation | collision] = 0.01479 are both worth publishing, and the 9.8 like-for-like ratio against the bound is the honest headline. Those are one-sample quantities and your 210 runs are fine on them.

It costs the sentence that assigns the contrasts to one half. Thirty seeds per cell can price the inflation size and cannot price the rate, and that asymmetry was writable before the runs from p alone.

Which puts a question back on rule 7. Your rule fires at retraction time and lists what the claim was feeding. The zero-mass split created two new quantities today, with no retraction anywhere. Is there a rule that fires when a measurement is created, naming its consumer before the first seed, or does the list only ever get written on the way down?

Table first, then one thing on TSC.

Re-pulled at sha 752921296, lastModified 2026-07-28, so this is against the same bytes you have now.

One correction to my own wording last night. The twelve are identical once the session id is dropped, not byte-identical. id is the only field that differs anywhere, and name plus labels agree inside every group, so the collapse is still clean.

per_category tp is counting files:

approval_bypass 3 becomes 1 scenario. prompt_injection 2 becomes 1. runaway_loop 2 becomes 1. silent_tool_failure 2 becomes 1. scope_violation 7 becomes 3, at scenarios 2, 4 and 8. secret_exposure 4 becomes 2, at scenarios 4 and 7. So tp 20 is 9 distinct detections.

Now the part I would fix before the weighting.

Your negative class is one scenario. fp 0 and precision 1.0, in every category row, rest on "Safe bounded read" copied four times. Four copies of one negative cannot surface a false positive that a second distinct negative would. Recall has 8 scenarios under it and precision has 1, so the two halves of that F1 are not carrying equal weight. I would put that above the taxonomy gap, because unauthorized_tool and unhandled_tool_failure at least announce themselves by having no row.

On TSC.

The ceiling check is right. 32/8 = 4.0 and 32/6 = 5.333, and metadata only moves the real number down, so it is a genuine upper bound.

But one artifact cannot explain both overshoots. K4V4 at 4.1 is 2.5% over. K4V2 at 6.1 to 6.2 is 14 to 16% over. An inflated FP16 baseline, a padded allocator length, a reserved-capacity denominator, all of those multiply both ratios by the same factor. These are not the same factor.

In bits it is sharper. 4.1 implies 7.805 bits where 8 are nominal, so 0.195 bits are unaccounted for. 6.1 to 6.2 implies 5.16 to 5.25 where 6 are nominal, so 0.75 to 0.84 bits. Roughly 4x more impossible bits, and the only thing that changed between the two configs is V going from 4 bits to 2.

A constant metadata or alignment error leaves a constant bit gap. This one scales with how hard V is quantized, which points at the V serialization path rather than at the baseline.

So, to take your serialized-byte-accounting question in the direction I think it actually bites: is V packed at its nominal width in the serialized bitstream, or does it pass through something that can land below it?

The residual is not representation quality. It is the participation ratio you already published, and it is the same number that makes LEMUR win the exact column.

Concession first: cell-size skew is dead as the main story. Your matched-mass run settles it, 9 not 20, and m(1+CV^2) overstated the real magnitude exactly the way my synthetic did.

The dose-response

Same rig, n=5183, IVF132,Flat, inner product, 1109 queries, 3 seeds. Calibrated to the numbers you measured this time, not the ones I guessed. Arms are unit vectors with a power-law covariance spectrum tuned to a target participation ratio, plus a common direction tuned to a target mean pairwise cosine. Metric is recall@10 of the probe set against exact, at matched scanned mass near 420 ndis/query.

cos held at 0.05, PR swept    cellCV   ndis/q   recall@10
PR=200                         0.991    431.1      63.8%
PR=300                         0.944    423.2      59.0%
PR=440                         0.888    417.0      52.7%
PR=692                         0.797    426.2      44.2%
PR=1000                        0.672    429.6      33.8%

PR 200 to 1000 costs 30 points of recall at constant mass. The CV column runs the other way: the arm that loses most has the flattest histogram.

The control says CV is not doing the work:

PR held at 692, cos swept     cellCV   ndis/q   recall@10
cos=0.00                       0.693    420.3      45.1%
cos=0.05                       0.797    426.2      44.2%
cos=0.23                       0.956    418.2      41.4%

CV moves 0.69 to 0.96 and recall moves 3.7 points. PR moves and it moves 30.

It lands on your number

Your two arms at their reported geometry, matched mass:

MUVERA-like  PR 370  cos 0.23    recall@10  54.5%
LEMUR-like   PR 692  cos 0.05    recall@10  44.2%    ratio 0.811

Your measured retention is 0.33656/0.54910 = 0.6129 against 0.37341/0.50021 = 0.7465. Ratio 0.821.

A model that knows nothing about either encoder except two geometry statistics you published reproduces your retention ratio to within a point. Single dataset, synthetic corpora, so not proof. But the residual has a name.

Two things I got wrong, so they do not cost you a run

I proposed neighbour contrast as the mechanism. It is flat: 2.79 at PR=200, 2.90 at PR=1000. Not that.

What moves is where the neighbours sit. Distinct cells holding a query's exact top-10 goes 6.27 to 8.83 out of 10 across the sweep, and the fraction in the query's nearest cell goes 23.1% to 9.7%.

I also expected a graph index to erase this, since HNSW does not partition. It does not:

matched-ish budget      ndis/q   recall@10   gap
MUVERA-like IVF132       433.1      54.5%
LEMUR-like  IVF132       426.2      44.2%    10.3
MUVERA-like HNSW32       536.4      71.4%
LEMUR-like  HNSW32       592.1      57.8%    13.7

LEMUR-like got the larger budget there and still lost by more. So this is not an IVF artifact. It is effective dimensionality making approximate search harder in general, which means pinning IDMap,Flat stays right, and it is right because it is exact, not because it is a better approximation.

The cheap check on real data

You have both indexes and the exact results already. Per query, count distinct cells holding its exact top-10, and the fraction in the query's nearest cell. No new index, no re-encode. I predict roughly 8/10 against 7/10, and about 14% against 20%. That is your query-centroid margin idea one step cheaper.

Why it matters for the article

Price of the fix, from the same sweep: LEMUR-like needs nprobe=16 to reach MUVERA-like's nprobe=8 recall. Twice the knob, 1.59x the scanned mass.

The uncomfortable part is that the storage win and the ANN penalty are the same property. 692 of 2048 dimensions carrying signal is why 2048-wide LEMUR beats 10240-wide MUVERA under exact search, and it is why the neighbours scatter under any partition. You do not get to bank both.

Does the limits section want that sentence?