You went to the one part of the project that has never run. That is the right place to go, and it is the first time in five rounds that a criticism has arrived before the data rather than after. That matters at the end of this reply.

Your numbers

All of them. Seed 0 at 20,000 reproduces to the digit. My own 10M draw is an independent stream, so it is a check on the estimand and not on your RNG:

Two independent samples agreeing on a maximum to four digits made me check whether the statistic was discrete enough to explain it. It is discrete — 2,951 distinct values in 2M draws, since the whole matrix is a function of nine integer counts — but the top rungs are singletons, so discreteness explains nothing. It is a coincidence, and the next section is what happens when you stop relying on one.

Your vectorised-vs-scalar check: I did the same and got max absolute difference 5.551e-17 on 3,000 codes, which I assume is your 5.6e-17. For a bijection both margins of the joint are exactly uniform, so I(A_i;M_j) = Σ (c/27)·log2(c/3) with c integer — that identity is what makes the whole thing a lookup table, and validating against the scalar path is really validating the identity.

The threshold: you are right, and the reason is worse than "still moving"

Your framing is that the max is the only row still in motion. Mine is that it cannot stop.

The 1,296 compositional codes are bijections. They are in the null, with probability 1296/27! ≈ 1.19e-25, and they score exactly 1. So the supremum of the null distribution is exactly 1 — the very value the threshold was built to declare unreachable. A sample maximum here is not estimating a threshold. It is estimating 1, infinitely slowly. No sample size fixes that, because there is nothing to converge to except the thing being tested.

Empirically, twelve independent blocks of 10,000,000 (variabilite_du_maximum.py, 384 s):

The block maxima run from 0.3775 to 0.4283. That range is 1.54 standard deviations of the null itself. A threshold read off that row inherits it: it measures how long I was willing to sample, not the distribution.

So: threshold withdrawn, quantile quoted instead, exactly as you proposed. q99.9 = 0.2525.

The part you found without pointing at it

§6.1 should never have carried a pass/fail line at all, and my own document says so three paragraphs earlier. §5 reads:

On abandonne délibérément le critère pass/fail. […] la mesure de concentration positionnelle définie en §6.1 sera statistiquement indiscernable de celle d'une permutation tirée uniformément au hasard.

That is a commitment about a distribution. Then §6.1 reintroduces a pass/fail and congratulates itself for it being derived rather than arbitrary. The defect was never the arbitrariness. It was the pass/fail, which §5 had already discarded for the reasons you then re-derived from the power side. I wrote both paragraphs. It took an outside reader for me to read them next to each other.

Your power numbers reproduce exactly. One-sided, p < 0.001, 80% power, δ = 3.93σ/√n:

against 0.223 on a single run for the threshold. Ratio 17. That calculation is now in §6.2 where it belongs.

The matching: your diagnosis is right, your localisation is not

74.6% double-count rate on uniform draws — I get 74.6%. On my top 200, matching gives mean inflation 0.0179 against your 0.0170. Same phenomenon.

Where I disagree is "real in the middle and absent at both ends". I could not test that against the null alone, because the null has no structured codes in it. So I built two populations where the structure is known independently of the MI matrix.

Codes with k of 3 positions cleanly encoding an attribute, the rest scrambled conditionally (still bijections), 4,000 each:

A ladder from a compositional code outward by transpositions, scored against d = minimum Hamming distance to any of the 1,296 (so relabellings are free):

 d      0    2    4    6    8    9   10   12   14   16   18   20   21   23
 infl  .000 .000 .000 .000 .000 .000 .0001 .0004 .0022 .0051 .0081 .0099 .0103 .0090
 dbl%   0    0    0    0    0    0   1.1   3.5  17.4 35.5 57.1 68.8 73.2 77.7

Inflation is exactly zero out to nine transpositions, then climbs and meets the null's own 0.0101 around d = 21.

So the inflation does not live in the middle of the scale. It lives in the region with no positional structure at all, and it is identically zero everywhere there is structure to read. Which means the specific §6.1 worry — a 0.28 code credited 0.017 it does not have — is real only for codes that reached 0.28 by accident, and those have nothing to read either way.

I want to flag how I nearly got this backwards. My first sweep binned the null by concentration level and found inflation rising with concentration: 0.0014 below 0.05, 0.0228 above 0.30. That is a true measurement and it points the opposite way from the ladder, which at the same concentration ≈ 0.27 gives 0.0022. Both are correct. Inflation tracks structure, not level, and those are not the same axis — a uniform draw at 0.27 got there by accident and usually double-counts, a near-compositional code at 0.27 did not. One population would have convinced me of the wrong thing.

Your actual question

Is the max standing in for a matching you have not needed yet, or is there a reason to want the double count?

Standing in for a matching. There was no reason.

There is one reason to keep reporting it, which I did not know when I wrote it and had to go check: the unconstrained per-position form is the field standard. posdis (Chaabouni et al. 2020) takes the argmax independently per position with no one-to-one constraint. So dropping it costs comparability with published numbers.

Both are now in grammaire3.py. concentration() unchanged, so the 20,000-draw table still reproduces bit for bit. concentration_appariee() added — exact Hungarian, and at 3×3 that is six permutations, so enumerated rather than solved. §6.1 now reads the matched one as its position.

One argument for your fix that you did not make

You wrote that the change cancels in §6.2 because it is the same transform on both sides. That holds under H0 — if the emergent codes are ordinary bijections, both populations shift by the same 0.0101 and nothing changes.

It does not hold under H1. If a pressure creates positional structure, the double count disappears with it, as the tables above show. The 0.0101 then comes off the null and not off the emergent population. The matched statistic lowers the reference without moving the signal: neutral where it must be, favourable where I want power. Small — sd also drops 0.0330 → 0.0315 — but it points the right way, and it is a better argument for your change than the one you offered.

Bounding the damage

Local hill-climbing over transpositions, so these are lower bounds, not maxima:

• largest max-minus-matched gap found: 0.1443, on a code scoring 0.2473 — i.e. inside the body of the null, where nothing is concluded anyway;
• highest concentration reachable while double-counting: 0.6314, and that code still scores 0.5560 matched. Even pushed adversarially, the max does not turn an unstructured code into a structured one;
• highest non-compositional concentration found: 0.9294. Your argument that concentration 1.0 forces an injective argmax is right — two positions each fully determining one attribute would collapse nine referents onto three messages, and a bijection cannot — and the top of the scale turns out to be isolated as well as safe: 1.0000, then 0.9294.

All three of those are hill-climbing over permutations, which matters more than I realised when I wrote them. See below.

A follow-up that makes your fix necessary rather than optional

After answering you I ran §6.7, the two-agent check that had never been done. One of its results changes the standing of your second question.

Exact gradient ascent on the joint objective, no sampling anywhere, does not reach a bijection from a uniform start. One start in forty. It settles on codes where 1 to 4 referents collide — E[R] lands on 23/27, 24/27, 25/27, 26/27. Started on a perfect code it stays at exactly 1.

So the emergent codes will not be bijections, and your safety argument for the top of the scale is conditional on bijectivity. Drop that condition and it fails outright. Take m₁ = a₁, m₂ = a₁, m₃ = a₂ — duplicate the first attribute across two positions, discard the third:

distinct messages used : 9 of 27          bijective : no

I(A_i ; M_j) in bits          concentration, max      : 1.000000
[[1.585 1.585 0.   ]          concentration, matched  : 0.666667
 [0.    0.    1.585]
 [0.    0.    0.   ]]

The published statistic hands a perfect 1.0000 — the value reserved for compositional codes — to a code that throws away one attribute in three and uses a third of the message space. The matched version returns 0.667, which is the right answer: two attributes read out of three.

So the double count is not a middle-of-the-scale artefact confined to structureless codes, which is what the measurement on bijections suggested to both of us. Once bijectivity goes, it reaches the top. Your fix is not a 0.48-point improvement in rank concordance. It is the only one of the two statistics that stays interpretable in the regime the experiment will actually be in.

I would not have found this by measuring harder on the null. It came from running the step that had never been run, and it is the second time in this exchange that the useful thing was upstream of the number under discussion.

Why this round was cheap and the next one would not be

No Test 3 training has run. There is no measured emergent concentration anywhere in the repository. So changing the instrument today cannot have been motivated by a result, and anyone can check that from the git history. The identical change made after a first run would be unverifiable from outside, and should be refused. That is the whole reason §5 recorded its commitment with a date, and it is the first time the mechanism has actually been worth something.

Thank you for going to the unpublished part. It is where the mistakes are cheapest to fix and where nobody has any reason to look.

You are right, and the diagnosis is worse than "measured in the wrong regime"

I annotated the three bounds as conditional on bijectivity and left them standing. Annotation is not the fix, and I knew that at the time. The same article says a retracted number should be re-measured, not footnoted.

But there is a sharper reason they could not have been right, and it is about the search rather than the reporting. My climber moved by transpositions. A transposition of a permutation is a permutation, so the move set could not leave the bijective regime even in principle. The constraint was not an assumption I failed to check, it was welded into the operator. Yours reassigns one referent to any message, which is why it can see what mine could not.

That is the third time this week that my instrument, not my reasoning, decided the answer.

Your sweep reproduces

Independent implementation, single-referent reassignment, 20 restarts, 120 steps, identical budget at every floor:

Same shape, and the same conclusion: one collision is the whole effect. My R = 27 baseline is a little higher than yours, so my ratio is 2.6x rather than 4x, which does not touch the claim.

Your second bound matches exactly. Highest concentration reachable while still double-counting: at R = 27 you get 0.2045 and I get 0.1943; at R = 26 we both get 0.6409, with matched 0.5812. Two different climbers, four decimals. My permutation figure was 0.6314, so one collision beats a bijectivity-restricted search over the whole permutation space.

And my R = 26 winner has the shape you describe, with a different attribute index:

I(A_i ; M_j) bits          argmax per position: [1 1 1]
[[0.086 0.012 0.062]       distinct messages: 26 of 27
 [0.416 0.330 0.410]       max 0.2430 against matched 0.1068
 [0.036 0.012 0.049]]

One attribute claimed by all three positions, at one collision instead of the eighteen my hand-built example needed.

Your question, answered on 100 seeds rather than 40

You asked whether R = 26 is common enough in the forty starts to be the modal case rather than the boundary. It is neither: R = 25 is modal, and R = 26 is second. Tabular sender, beta = 0.02, 100 seeds:

So the bijective case is not the boundary of the regime, it is 3 % of it. Ninety-seven of a hundred runs sit at or past the first collision, and the median run is one collision beyond where your sweep says the effect has already arrived.

It holds across the code regime rather than at one beta. Mean R by entropy coefficient, 20 seeds each: 24.05 at 0.005, 24.55 at 0.010, 24.80 at 0.030, 25.25 at 0.037. Raising beta toward the stability threshold buys back distinct messages and never reaches 27 on average.

And the other two parametrizations sit deeper, not shallower. Modal R = 21 for the autoregressive-per-referent sender, R = 23 for the attribute-structured one.

So your closing point is right and I had it too weak

I wrote that the matched statistic is the only one that stays interpretable once bijectivity goes. The correct statement is stronger, and it is yours: the double count does not degrade gradually as R falls. It arrives almost entirely at the first collision, and the first collision is not an edge case, it is 97 % of runs.

Which means the published statistic is unusable in this experiment's actual operating regime, not merely at its boundary. That is a firmer conclusion than the one I shipped, and it comes from re-running a number I had chosen to annotate.

The three bounds are replaced by the R-indexed table rather than deleted, with the transposition-operator diagnosis written next to them, and the article is updated. Thank you for not letting me footnote my way out of that one.

You are right about the structure, and I want to correct one number before agreeing with the rest.

One magnitude, which is mine to fix

Your 22.6 % compares your climber at R = 27 (0.0396) against your own mixture (0.1751). My published bound was 0.1443, from the transposition climber, and that is 90 % of my own mixture at 0.1604 — or 82 % of yours. The undercount is 11 %, not a factor of four.

The direction of your correction holds entirely. Its magnitude describes your sweep, not the figure I published.

Everything else lands, including the part I got backwards

The null moves 0.00016 across the whole support my procedure visits. The reachable worst case moves 0.1355. I spent an entire section rebuilding the reference while the damage sat in the search's reachable set — the denominator when the problem was the numerator.

So my three bounds were not too generous. They were too small, and a retraction that points the wrong way is worse than the overclaim it replaces.

Worth recording that we converged on the flatness by different partitions. You measured null by R, 200 000 draws per cell. I had measured it by full fiber profile, eleven profiles, −0.0001 to +0.0005. Same conclusion, no shared assumption, which is the only kind of agreement worth much between us after the concentration-1.0 episode.

Your question, measured

150 runs, five betas by thirty seeds, on actually emergent codes rather than a search worst case.

Neither. The gap does not fall as beta rises: correlation +0.158, and no trend past the noise on the row itself. And R does not stop predicting it, because R never predicted it — correlation +0.091, 4 % of variance explained. Conditioning on R removes almost nothing: the residual correlation with beta stays at +0.144 against +0.158 unconditioned.

It is not that R ceases to be the variable. It was never the variable for this quantity.

Which forces a distinction neither of us had made

The worst case reachable under a floor on R and the gap the dynamics actually produces are different functions of R.

R                    27       26       25       24       23
worst case       0.0526   0.1362   0.1783   0.1850   0.2152     strongly monotone
observed gap     0.0096   0.0120   0.0139   0.0076   0.0106     flat

Ratio between them: 15.2. Emergent codes come nowhere near what an adversarial search reaches in the same regime. Both numbers are indexed by R and there is no reason they should track — one is what a search can find, the other is where the dynamics lands.

And your beta reservation settles by computation

Mixed over the p(R) specific to each beta, the worst case runs from 0.1564 to 0.1773 — 0.0209 of amplitude across the whole range. The shift with beta exists, and it is small relative to the quantity being bounded.

What I take from this

A bound must be mixed over the regime actually visited. An effect size must not be read off the same table. I had neither rule this morning, and I got the second one wrong by inheriting the first one's index.

The three bounds are now reported as the R-indexed table, the mixture is stated next to them, and the observed gap is reported separately with its own note that R explains 4 % of it. Notebook §7.25.

You called it. I ran it. The contrast flipped sign.

First, your arithmetic, checked against the raw runs rather than the table

Everything you derived from binned means reproduces on the 150 individual runs. Your reconstruction was exact enough that the differences are rounding:

And you are right that my 11 % and 90 % are the same two numbers over different denominators. Worth stating once so it does not read as a hedge later.

Your per-bin standard errors differ from mine because you pooled: 0.012942/√8 = 0.00458 is your R = 27 cell exactly. Mine are the within-bin values. Yours is the better estimator at n = 8; mine tests the homoscedasticity yours assumes. On the contrast that matters they agree — your t = 2.4, my t = 2.53.

The thing you cannot do from where you are sitting

R is an output of the run, not a setting. I cannot run thirty seeds at R = 24 and R = 25. I run seeds and take whatever R falls out. Those two cells carry 100 of 150 runs, so thirty more inside them costs about forty-five runs. I ran sixty, on an independent seed, same five betas.

The replication

On the sixty new runs alone, R = 25 against R = 24:

difference   -0.0053     SE 0.0033     t = -1.60

The sign flips. Which is what the largest of ten available contrasts does when it is the largest of ten available contrasts. You said you did not believe it. Neither of us should have.

Pooled to 210 runs, everything moves toward null and nothing moves away from it:

The new sample also reached R = 22 and R = 21 once each, which is why the F has six numerator degrees of freedom rather than four.

So I am taking both of your reformulations, and they are now stronger than when you wrote them

On R. "R explains 4 %" was the wrong sentence, and at n = 210 it is not even the wrong number any more: eta² is 1.2 % and F(6,203) = 0.419 at p = 0.87. The sentence that goes in the notebook is yours — R is not distinguishable from explaining none of it — and the replication is what earns it.

On flatness. Your power framing replaces my ratio, and the pooled sample improves it:

observed slope    +0.000507 per unit R    SE 0.000836    t = 0.61
detectable at 80 %  0.00234
worst-case slope   -0.04065 per unit R
ratio               17.4

Up from 13.9. The observed row is bounded away from the reachable row by seventeen times my own resolution, and it still points the other way. You are right that the ratio invites "different scales" and the power statement forecloses it. It is now in §7.25 in your words rather than mine.

What this cost and what it bought

Sixty runs, about half an hour. It killed a kink I would have mentioned as "the one place the flat row is not flat", removed a 4 % figure I had reported as a finding, and turned a p = 0.19 into a p = 0.87.

The generalisable part is not about R. It is that the one contrast past two sigma in a table of ten was exactly the one to distrust, and the cheapest way to know was to draw again rather than to argue about it. That is the fourth time in this exchange that the answer was a second draw, and the first time I made it before publishing rather than after.

Your three legs reproduce. Two of your numbers about me are wrong in my favour and I am correcting them against you. And your closing question has an answer I did not want to give, which I found by trying to answer it honestly: no rule, decided per table, and the proof is one row above the one we have been arguing about.

Your null law, by three routes

I did not want to take your simulation on trust, so I built two more. Parametric with fixed cells, the way you did it. A permutation of the 150 observed gaps over the observed design labels, which assumes nothing — not normality, not a common sd, not that the cell sizes were fixed. And a parametric one with the cell sizes redrawn each time, because R is an output of the run and 8/30/53/47/12 is itself a realisation.

Your law is right, and your row is my sigma-known row to three digits on all of it. The only visible gap anywhere is that a re-estimated sigma has slightly heavier tails than a known one, which moves q90 by 0.025 and P by 0.006. Redrawing the cell sizes moves it less than that, so the fixed-cell approximation you had to make was free — worth knowing, since R being an output was the one thing you could not check from outside.

Magnitudes reproduce too: E[abs d of the winner] 0.00658 parametric, 0.00662 permutation, against your 0.00657. E[abs d | the winner is the 25/24 pair] 0.00415 and 0.00421, against your 0.00414. And that pair wins 13.7 % of the time, which is why it comes cheaper.

Correction one: my t was 2.43, and yours was closer to it than mine

You read 2.40 off the published table and I told you mine was 2.53. Recomputed from the runs with the sd pooled across the five cells — the estimator a contrast test actually uses — it is 2.430, and the pooled sd is 0.012969 against your 0.012942. My 2.53 was the within-bin version, which I had already told you was the worse estimator at n = 8 and then used anyway for the headline number.

So the entry in your table should be 2.43, and the selection-corrected p by permutation is 0.099 (two independent permutation runs of 100 000 give 0.0994 and 0.1013, so 0.10). You had 0.107 at 2.40. Nominal p was 0.0163.

Correction two: your pooled comparison used my number from a different procedure

Your null pooled +0.00256 by inverse variance against my +0.0028. But my +0.0028 is not an inverse-variance pool of two halves. It is what falls out of re-running the contrast on all 210 raw runs, which re-estimates the cell means and the sd jointly. Those are different estimators and they do not have to agree.

Pooled the way your null pools, my two independent estimates give:

discovery     +0.00631   SE 0.00260   t = +2.43   weight 63.5 %
replication   -0.00535   SE 0.00343   t = -1.56   weight 36.5 %
inverse variance pool  +0.00206   SE 0.00207   t = +1.00

Against your null run end to end at 400 000 draws:

Your +0.00256 matches the conditional row, so your end-to-end conditioned on the pair while the text says "select the max". That is the right conditioning — my contrast is that pair — but then the comparison is against +0.00206, not +0.0028.

Either row says what you said, harder. It is not P = 0.434. My pooled number is at the 63rd to 82nd percentile of a table with nothing in it, and I should not have published it. The only unselected estimate I own is the replication alone, -0.0053, SE 0.0033. That is now the only one in the notebook. While I was at it: the t = 1.47 I published for n = 210 is also the within-bin version. Pooled sd gives d = +0.00285, t = 1.35.

Correction three, which is yours to keep: omega squared is exact, not approximate

Under the null, eta squared is exactly Beta(df1/2, df2/2), so its expectation is exactly df1/(df1+df2). Your 2.68 % is 4/149 and your 2.87 % is 6/209, to the digit — I checked against 400 000 draws and got 2.683 % and 2.867 %. Not "biased up by about df1/df2". Biased up by exactly that. Every one of your four figures reproduces:

Now the part neither of us had

You corrected my p for ten contrasts. The table offered twenty. The same 150 runs carry a beta row, five levels, ten more pairwise contrasts, printed in the same reply, read the same afternoon.

Its largest is abs t = 2.968. Bigger than the one we have spent two rounds on.

beta = 0.005 vs beta = 0.03    d = -0.00981    t = -2.968    nominal p = 0.0035
beta = 0.010 vs beta = 0.03    d = -0.00806    t = -2.439
R = 25      vs R = 24          d = +0.00631    t = +2.430
beta = 0.020 vs beta = 0.03    d = -0.00744    t = -2.253
beta = 0.030 vs beta = 0.037   d = +0.00691    t = +2.093

Five contrasts past two sigma, not one. My sentence last round — "the one contrast past two sigma in a table of ten" — was wrong on both counts, and the largest of the five was in the row where I wrote "no trend past the noise on the row itself". I wrote that without running a test. The row's omnibus at discovery was F(4,145) = 2.595, p = 0.039.

Corrected over the twenty by permutation: my R contrast goes from 0.101 to 0.200. The beta one sits at 0.053.

So I ran the replication I already had. The sixty independent runs answer the beta row too, and I had never looked:

beta 0.005 vs 0.03   discovery -0.00981 (t = -2.97)   replication -0.00135 (t = -0.34)
omnibus              discovery F(4,145) = 2.595, p = 0.039   replication F(4,55) = 1.790, p = 0.144

Cell means, discovery then replication, across beta = 0.005 / 0.010 / 0.020 / 0.030 / 0.037: 0.0077, 0.0094, 0.0100, 0.0175, 0.0106 — then 0.0087, 0.0099, 0.0024, 0.0101, 0.0121. The peak I would have described as "beta = 0.03 stands up" is gone, and the cell that collapses on the second draw is a different one. The pooled p = 0.029 at n = 210 is 71 % discovery data and is not a confirmation of anything.

It dies the same way, for the same reason, and I reached the right conclusion about it by not looking hard enough. That is not the same as being right, and it is worse than the R error, because there I at least wrote the number down.

Your question, answered

Does it have a standing rule for how many contrasts a table offers before you are allowed to read the largest, or is that decided per table after you have seen it?

Per table, after seeing it. There is no rule in the notebook and there never was. And the beta row is the demonstration: I looked at both rows, decided the R row was worth a contrast and the beta row was worth a sentence, and picked the smaller of the two maxima. A per-table decision made after seeing the table cannot even be relied on to select the largest thing in it.

Four lines going in, before the next seed:

1. K is declared before the data. K = every pairwise contrast the design offers, summed over every factor read in the same sitting, whether or not it gets reported. Twenty here, not ten, and the ten I did not report are the ones that made it twenty.
2. Every abs t >= 2 in the table is printed, not the largest. Five rows here. Withholding four is what let me call a row flat while it held a 2.97.
3. The corrected p comes from a permutation of the outcome over the design labels. Seconds to run, no distributional assumption, and it is the arbiter when the parametric version and the reader's version disagree — as they did above by 0.025 on q90.
4. A selected contrast never gets published pooled with its own replication. Replication alone, with its SE.

For this design the threshold that rule implies is worth stating, because it is not close to the one I was using: over the twenty contrasts, q90 is 2.73, q95 is 2.99, q99 is 3.56. Against a nominal 1.98. Everything in my table was below the corrected q90.

On the zero-run claim

You are right that the max-of-K law and E[eta squared] are functions of the design and were computable before the first seed, and you concede the second draw is stronger. I would sharpen it in the direction that costs me more: available before the first seed, it changes the design rather than the reading. Knowing that five R levels and five beta levels demand abs t = 2.99 would have forced me either to name one contrast in advance or to budget the replication into the run from the start. I did neither, because I did not know I was choosing.

What the zero-run route could not have done is tell me the sign flipped, or that the beta row dies too. Those needed the sixty runs. It is the cheapest way to know you should not believe a number; it is not a way to find out what the number is.

Fifth time in this exchange the answer was a second draw. First time it also answered a question I had not asked.

Notebook §7.26, and §1.18 for the dead hypothesis. Verification code in src/test3_communication/correction_de_selection.py and correction_de_selection_suite.py.

You are right about the bump, right about my sentence, and right that rules 1 through 4 would not have caught this. I tried to break your diagnostic the way you broke my contrast and could not. Then I went one column over in the same file and found something that makes the question you asked at the end the wrong question — in a way that costs me the whole row, not one cell of it.

My sentence was wrong and my own p said so

Everything in my table was below the corrected q90.

2.968 is not below 2.73. I wrote that two lines under a p of 0.053, and 0.053 is between q95 and q90 by construction, so the number I had just published contradicted the sentence I wrote about it. It hands back the one row the section existed to surface. Struck.

Everything reproduces, and I checked your diagnostic against your own standard

Leave-one-cell-out lands on the digit: 1.134, 2.012, 1.944 for your three cells. The five within-beta gaps land on the digit. Scheffe gives 0.213 against your 0.212. The additive fit gives 2.215 against your 2.193, which is a parametrisation difference and nothing more.

Then the obvious attack, which is yours turned around: your leave-one-out is a maximum over twenty-five removals. You read the largest drop out of twenty-five, which is exactly what you caught me doing with ten contrasts. So I built its null the same way, permuting the gaps over the real design and taking the max drop each time:

observed drop                        1.295
E[max drop] under the null           0.430
q90 / q95 / q99             0.733 / 0.835 / 1.070
P(null max drop >= 1.295)           0.0008

It survives its own correction with room to spare. That attack is dead too, and I am reporting it because I went looking for it and it is not there.

One thing you chose

the other 19 cells move t(R) by at most 0.27

There are twenty-two others, not nineteen, and removing beta = 0.005, R = 25 moves t by 0.517 — larger than two of the three cells you displayed. It moves it up, 2.430 to 2.947, which is presumably why it did not make the list. Your 0.27 is right for downward moves only. It is the same shape as my error one section up: a sentence covering the rows not shown, wrong in the direction that helps the point.

Nothing in your conclusion turns on it. I am flagging it because you would flag it.

Further one: it is not thirteen runs, it is two

The smallest number of runs whose removal takes the contrast under the nominal bar — pick them adversarially, greedily, no cell structure assumed:

R 25 vs 24        t = +2.430    breaks at 2 runs of 150   (1.3 %)
beta 0.005 vs 0.03  t = -2.968    breaks at 3 runs of 150   (2.0 %)

Your thirteen is six times too generous to me. And the cell is not a cell, it is bimodal. Sorted gaps inside it:

0.0496  0.0488  0.0477  0.0445  |  0.0253  0.0245  0.0215  0.0202  0.0118  0.0089  0.0081  0.0062  0.0000

The jump at that break is 0.0192; the largest jump anywhere else in the cell is 0.0084. The top four have mean concentration max 0.182, above the whole plan's q90 of 0.171. The other nine have 0.123, and the plan's median is 0.124. Four unusual runs sitting on nine completely ordinary ones, not a cell with a level.

Further two: the thing you named has a test, and it does not clear your own bar

You wrote that it is not a confound, it is an interaction. That is a testable statement and neither of us tested it. Fitting cell means against the additive model:

interaction        F(11,127) = 1.748    nominal p = 0.070    permutation p = 0.075

So the interaction you diagnosed sits at 0.075 before any multiplicity correction at all — squarely in the zone you spent two rounds teaching me to distrust. And on the sixty independent runs: F(6,40) = 1.425, p = 0.229, with the cell inverting from +0.0201 to -0.0088.

The bump is real in the discovery sample, survives being the max of twenty-five, and is not there on the second draw. Same verdict as the two contrasts it explains.

Further three, which is the one that matters: R is the objective

results_test3/ carries a column neither of us opened. Every run records its final reward.

runs where |reward - k/27| < 1e-3, for integer k     150 / 150
runs where k == R                                    141 / 150
runs where k == R - 1                                  9 / 150
corr(R, reward)                                       +0.9725

R is the reward times twenty-seven. Not correlated with the outcome, not downstream of it — it is the outcome, rounded to a grid of 1/27. Every cell in your table has a single reward value to five decimals: 0.92586 across all thirteen runs of the bump cell, 0.88882 one column over, 0.96289 one column back.

You called the R row post-treatment. That is true and it is too gentle. Stratifying by R is stratifying runs by the value of the objective the optimiser was maximising, and then asking whether a measurement bias differs between the ones that scored 25/27 and the ones that scored 24/27. There is no factor there to be a fact about. The bump is not why that row should not have been published; the row should not have been published if every cell had been flat.

For completeness, because it decides whether your row is contaminated too: beta does not move R. Chi-square on the full 5 x 5 crossing gives 15.67 on 16 df, p = 0.476. There is a weak linear component, corr(beta, R) = +0.197 at p = 0.016, so the beta row is very slightly mediated, but it is a real factor that I set, and it stays a legitimate contrast. Its problems are the ones already on the record: corrected p = 0.053, Scheffe 0.072, and t = -0.34 on replication.

Further four: the quantity is a function of max, not of R

corr(concentration max, gap)         +0.4317
corr(matched concentration, gap)     +0.0665
corr(concentration max, R)           +0.0172

The gap is mostly "how high the unconstrained max landed", and where the max lands has nothing to do with R. That is the mechanism under your bump: a cluster of high-max runs that happened to fall in one cell of a table indexed by something orthogonal to them. Which is also why the cell inverts on the next draw — nothing was holding it there.

Your question, and why I am answering a different one

Is there one for when a contrast is allowed to be reported as a fact about the factor it is labelled with, rather than about the one cell it lives in?

The question presumes the label is a factor, and for the row we have been arguing about it is not. So two rules, and the first is the one that would have saved this.

Rule 5. A contrast is reported as a fact about a column only if the column was set before the run. Not measured, not derived, not "an output that happens to index things usefully" — assigned. R fails this at the strongest possible level, being the objective on a grid. No diagnostic on that row could have rescued it, and none was needed: it is disqualified before any data arrives, by reading the generator. This deletes the entire R row from §7.25 and §7.25bis, which is more than your bump does, and it is the only rule so far that costs me a result I still believe rather than one I had already given up.

Rule 6, for columns that pass rule 5. Publish the breakdown count. The smallest number of runs whose adversarial removal takes the contrast under the bar. One integer, no distribution, no family, computable in seconds, and it does not care whether the fragility is a cell, an outlier, or a cluster. Here: 2 of 150 and 3 of 150. A contrast that dies to 1.3 % of the sample is reported with that integer attached or not reported.

Neither is a rule about selection. You were right that all four of mine were, and that was the flaw — I had built four ways to price a contrast and none to ask whether the column deserved a price.

And rule 1 does have a diary in it

You are right, and I am taking Scheffe. "Every factor read in the same sitting" makes the published p depend on my scrolling; 2.817 at 145 df and family 0.10 gives my R contrast 0.213 against my sitting-dependent 0.200, and the beta contrast 0.072 against 0.053. Same numbers, fixed by the design before the first seed, no diary. Rule 1 now reads: K is the design's, and the bar is Scheffe's.

Sixth time in this exchange the answer was in something already on disk. This time it was a column in the same file, twelve characters from the one we were arguing about.

Notebook §7.27, §1.19 for the dead hypothesis. Code in src/test3_communication/anatomie_du_bump.py.

You are right that rule 6 published a bare integer. You are right about the arrow. And your one surprising number is your p-value wearing a hat, which I will show before I use the rest of your argument, because the rest of it survives without it.

Rule 6 is not repairable by reporting it over its null. I went to build that null and it is not identified.

Rule 6 dies harder than you killed it

I planted the effect your way — residuals from the R-level means, resampled with replacement, constant shift on every R = 25 run, calibrated so E[t] = 2.430, cell sizes 53 and 47. Then I varied the one thing that should not matter: where the residuals come from. Same design, same planted effect, same n, same greedy removal.

residual source              median breakdown   mean   P(<=2)   P(<=3)   power
residuals from R-level means         3           4.3    0.488    0.568    0.682
residuals from the 25 cell means     4           5.6    0.354    0.432    0.796
Gaussian, same sd                    2           4.0    0.518    0.598    0.626
yours                                4           5.5    0.252    0.398    0.665

Your median and mean sit on my cell-residual row; your power sits on my R-residual row. I could not find a single specification that produces all four of your numbers, and I am reporting that rather than tuning until it matches.

But locating your run exactly no longer matters, because the spread across three defensible choices is the finding. The observed 2 reads as the median of one null, "half of true effects" in a second, and "a quarter" in a third — and nothing distinguishes them except a modelling choice about residual structure that has no bearing on the effect being planted. The residual skew is 1.37 by R-level and 0.96 by cell; that difference alone moves the reference by a factor of two.

So the fix you proposed — report the count against E[breakdown | a real effect of this size] — inherits the problem it was fixing. There is no null to report against without first assuming the generative model, and the assumption swings the verdict.

Rule 6 is withdrawn, not amended. It was a robustness statistic with the model smuggled into the calibration step, which is the same failure as a bare integer with the model smuggled into the reader's head.

Your 0.665 is your p in costume

Power computed at the observed effect size is a one-to-one decreasing function of the p-value (Hoenig and Heisey 2001). It cannot contain anything t does not already contain. Directly:

    t     two-sided p    power at the observed size
 1.00        0.3190              0.168
 1.50        0.1358              0.319
 1.98        0.0496              0.503
 2.43        0.0163              0.675
 2.97        0.0035              0.839
 3.50        0.0006              0.935

Your 0.665 is my 0.675 analytic and 0.682 simulated, and it is p = 0.0163 rewritten. "The design has two-thirds power at the size it found" is "t was 2.43" — it is a fact about the observation, not about the design, and the sentence attributes it to the design.

Your use of it is fine: calibrating a planted effect against the observed size is legitimate and is not the same thing. It is the standalone sentence that does not survive.

That leaves your closing question standing on its own, which is where it should have been.

Your pigeonhole, verified, and the arrow conceded

reward <= R/27          discovery 150/150     replication 60/60
deficit in {0, 1}       never 2, never negative, across all 210
deficit == 1            9 of 150 and 11 of 60, six of the nine at R = 25
k = round(27 * reward)  contrast t = +2.226   (yours to the digit)

You are right and I had it backwards. R = len(np.unique(code)) is the alphabet size of the argmax code, and reward is round-trip success over the same 27 referents, so R symbols admit at most R decodable referents. Counting, not regression. My "R is the reward times twenty-seven" described the 141 runs where the bound is tight and silently dropped the nine where it is not — and those nine are the informative ones, since they are the runs where the code carries R symbols and only R − 1 decode.

The direction does make rule 5 bite harder, exactly as you say: a column that bounds the objective is disqualified in the runs where the optimiser misses the ceiling too, which my formulation did not cover.

One thing you did not check, which I expected to matter and it does not: none of the nine collision runs is in the bump cell. Zero of its thirteen. And their mean gap is 0.01142 against 0.01102 for the rest. So the receiver collision is not the mechanism behind anything, and the bump remains what §7.27 found it to be — four high-max runs.

Your question, answered on its own terms

Is there a draw large enough to put an effect that size above 0.9?

For beta, yes, and it is cheap: 36 seeds per level, 179 runs, about half an hour. For R, 89 runs per cell, roughly 266 total — but R cells are not settable, so that is not a draw anyone can command. You take what falls out. That asymmetry is rule 5 showing up again in a different costume: the column you cannot power is the column you were never allowed to contrast.

is the honest column next to each contrast the detectable-effect floor rather than the p?

Yes. Here is the whole table with it, floor = 2.80 × SE, a function of the design alone:

contrast                 n        SE      floor     observed   observed/floor
R 27 vs 26            8+30    0.00516    0.01445    -0.00249        0.17
R 26 vs 25           30+53    0.00296    0.00830    -0.00186        0.22
R 25 vs 24           53+47    0.00260    0.00728    +0.00631        0.87
R 24 vs 23           47+12    0.00419    0.01175    -0.00298        0.25
beta 0.005 vs 0.03   30+30    0.00330    0.00925    -0.00981        1.06
beta 0.005 vs 0.037  30+30    0.00330    0.00925    -0.00289        0.31

Every observed effect in the table is at or below its own detection floor. The two we spent four rounds on are the two that reach 0.87 and 1.06 — which is the definition of the regime where what surfaces is inflated. The floor column says that before any of it happened, needs no data, and cannot be gamed. It replaces the p column.

Where I think this goes past the question

The floor answers "what could I have seen". Nothing in eleven rounds has asked "what would I have needed to see for anything to change".

The table in §7.25 existed for one purpose: to know whether the gap the dynamics produces approaches the worst case a search can reach. Published worst case 0.1443, observed mean gap 0.0110, ratio 13.1.

target ratio    required rise in the gap    versus the largest observed effect (0.00981)
      2                 0.0611                          6.2 x
      3                 0.0371                          3.8 x
      5                 0.0178                          1.8 x
      8                 0.0070                          0.7 x
     10                 0.0034                          0.3 x

I want to stop here rather than take the number that helps me. The threshold is chosen, not derived, and the verdict flips between ratio 5 and ratio 8. If "nowhere near" means a factor of two, every contrast in the table is six times below anything that could matter and the design is four to eight times more sensitive than it needed to be. If "nowhere near" means a factor of eight, the contrasts are in range and the whole exercise was legitimate.

I cannot now name that threshold without it looking picked, which is the actual finding: it was never written down, and it is the only number in this entire exchange that had to be fixed before the data and was not. The floor is a design quantity and I can still compute it honestly today. The relevance threshold is a design quantity that becomes uncomputable the moment you have seen the results.

The five questions underneath this exchange

Eleven rounds, and the corrections have been getting more precise while staying on the same level. Written as questions, because that is what they are:

1. When is a column a variable? A dataframe column looks like a factor whether or not anyone set it. R survived four rounds of increasingly careful statistics because every one of them priced a contrast instead of asking what the column was. In this field almost everything reported as a factor is an output — final loss, effective rank, number of active features, the step convergence happened at, the architecture that survived a sweep. The test is whether the column was assigned before the run, and it is answered by reading the generator, not the data.

2. Can a robustness diagnostic exist without a generative model? Rule 6 says no. The breakdown count needs no distribution to compute and cannot be interpreted without one, and the interpretation moves by a factor of two across choices that have nothing to do with the effect. I suspect this generalises to every statistic sold as assumption-free: the assumption is not absent, it is relocated to the calibration step where nobody looks for it.

3. Which of our reported numbers are functions of the design and which are functions of the data? Only the first kind can be fixed before the first seed, and only the first kind cannot be gamed. The detection floor is design. The Scheffe bar is design. K is design. The p-value, eta squared, the breakdown count and observed power are all data — and observed power is the clean demonstration, since it looks like a design quantity and is a p-value.

4. What is the smallest effect that would have changed a conclusion? An experiment without this number cannot be under-powered or over-powered, because power is relative to an effect nobody named. It has to be written before the data, and after the data it can no longer be written honestly. Ours was never written, and that is why I can produce a table where the answer depends on a ratio I get to choose.

5. How much of empirical method is machinery for pricing measurements that could not have mattered? Eleven rounds on the correct price of a contrast on a column that was not eligible, measuring a quantity whose relevance threshold was never set, in a table where every effect sits at or below its own detection floor. Each correction was right. The sequence never asked whether the thing being corrected was worth measuring, and every tool either of us reached for was a tool for pricing, not for that question.

I do not have rules for 4 and 5. The one thing I can do is put the floor column and a stated relevance threshold into the design document before the next run, where the second one is still writable.

Notebook §7.28, §1.20 for rule 6. Code in src/test3_communication/plancher_de_detection.py.

The identity is exact and the column is withdrawn. Then your pilot does not work on this quantity, for a reason that turns out to be the same reason the floor was worth having. And your reframe of question 4 is better than mine, so I took it and followed it to a date on my own record.

Your identity, to zero

contrast              |t|     |t|/2.80    my ratio     difference
R 27 vs 26          0.482      0.1721      0.1721      0.00e+00
R 26 vs 25          0.627      0.2238      0.2238      0.00e+00
R 25 vs 24          2.430      0.8677      0.8677      0.00e+00
R 24 vs 23          0.711      0.2540      0.2540      0.00e+00
beta .005/.03       2.968      1.0601      1.0601      0.00e+00
beta .005/.037      0.875      0.3125      0.3125      0.00e+00

Not close — identical, because plancher = 2.80 * se and t = d / se in the same file. So "every observed effect is at or below its own detection floor" is |t| < 2.80, which at 145 df is p > 0.0058: an alpha 8.6 times stricter than the 0.05 written into the floor's own definition. And you are right that I published the same fact twice in one message and flagged only one instance — my section C printed t = 2.97 → p = 0.0035, which is section D's 1.06 row.

I replaced a p-value column with a rescaled p-value column and called it a design quantity, one message after explaining why observed power is a rescaled p-value. The ratio column is withdrawn. The correction to my question 3 is that "is it a function of the design" has to be checked on the printed expression, not on the intent.

The absolute floor survives, and it convicts something older than this table

Your prospective use is the real find, and it reaches further back than the row you applied it to. Both replication floors, computable before those runs existed:

                     n        floor      effect it had to confirm    ratio
beta .005/.03 discovery  30+30   0.00925          0.00981             1.06
              replication 12+12   0.01462          0.00981             0.67
R 25 vs 24    discovery  53+47   0.00728          0.00631             0.87
              replication 30+12   0.01240          0.00631             0.51

The sixty runs I ran in round eight could not have confirmed either contrast even if both were exactly true. I reported that replication as a test — "the sign flips", "it does not replicate", "the omnibus goes to p = 0.144" — and it was never a test. It was an estimator, and an unbiased one, which is why -0.0053, SE 0.0033 remains the only honest line to publish from it. The conclusion I drew survives. The reason I gave for it does not: I read a failure to reach a bar that the draw could not have reached.

That is computable before running, does not depend on what came out, and no p on the replication can say it. Kept, printed alone and absolute.

And rule 5 does eat it on the four R rows. 8+30+53+47+12 is a partition of the discovery runs by an outcome; the 6.32 effective runs at R 27 vs 26 was a result. Both inputs to those floors fall out of the run. Only the beta rows at 30 and 30 are design — and, as you note, the only contrast in the table that clears its floor is in the only column that was eligible.

Where the pilot fails, and it is not a detail

You propose 2.80 * sigma_pilot * sqrt(1/na + 1/nb) in the design document. On this quantity the pilot cannot fix sigma, and the reason is structural rather than practical.

beta        n      mean       sd     sd/mean
0.005      30    0.00768   0.01080     1.41
0.010      30    0.00943   0.01042     1.10
0.020      30    0.01005   0.00857     0.85
0.030      30    0.01749   0.01771     1.01
0.037      30    0.01057   0.01436     1.36

Bartlett  chi2 = 19.176   p = 0.0007        sd ratio across levels  2.07

Heteroscedastic across the swept factor, so one pilot sigma misprices the floor by 12 % to 38 % depending on the cell. But the mechanism is what matters:

The gap is bounded below by zero. The unconstrained max is always at least the matched value, so max - appariee >= 0 by construction, and 63 of the 210 runs sit exactly at 0. A non-negative variable piled at its bound has its scale tied to its location, and it does:

across the 18 cells with n >= 4:
   corr(cell mean, cell sd)    Pearson +0.874   Spearman +0.917
   slope sd on mean            +0.817
   median coefficient of variation   1.07

Sigma is not a nuisance scale here. It is roughly the quantity being measured. So a pilot fixes the floor only if the pilot's mean matches the eventual mean, which is to say only if you already know the effect. That is not a fixable pilot design; it is the floor's one data-dependent input being data in the strong sense.

But more of question 4 moves before the run than you proposed, in a different unit

The same fact that breaks the absolute floor makes a relative one writable. If sd ≈ CV × mean with CV stable near 1, then

floor / mean  =  2.80 * CV * sqrt(1/na + 1/nb)

which needs no sigma at all. For 30 seeds per cell and CV ≈ 1.2: 0.89. Checked against the actual table, floor 0.00925 over grand mean 0.01035 = 0.894.

Written before the first seed, in one line and with no pilot: with thirty seeds per cell, this design sees a near-doubling of the gap and nothing smaller. That is a stronger pre-registration than an absolute floor because it survives not knowing the scale, and it is the honest form for any non-negative quantity piled at zero — which is most of what gets measured in this field. CV is the stable thing to pilot; sigma is not.

So: not the whole of question 4 moves, but the part that moves is bigger than an absolute floor and it moves in relative units.

Question 4, your reframe, and the date

It became unwritable by you, which is not the same as uncomputable. The defect is not that the data arrived first. It is that "what does this measurement feed" was never asked, and that question does not reference the results.

You are right, and it is a better diagnosis than mine. I said the threshold rots on contact with data. It does not — it was never planted.

So I asked it, and it has an answer with a date on it.

The gap max - appariee measures the inflation from publishing the concentration statistic in its unconstrained-argmax form rather than the matched form. Its consumer was the 0.35 threshold in TEST3 §6.1, which decided whether an emergent code counted as compositional. That threshold was withdrawn on 11/08/2026, notebook §1.9, after you pointed out it was built on a sample maximum.

Rounds six through twelve have priced a measurement whose consumer was deleted in round five.

The distinction that keeps it honest, since not all of the work goes: the bound still has a consumer, because I report the max-form statistic and a reader needs to know it can be inflated by up to 0.14. That work stands. The contrast table — does the inflation depend on R, on beta — never had one. No decision anywhere changes at any value of that dependence, which is exactly why the relevance ratio was free to be 2 or 8 and why naming it now looks picked. There was nothing to pick from.

Which is what the design says too, if you ask it about the question that did have a consumer. That one is one-sample, not a contrast:

mean gap over 210 runs        0.01035    SE 0.00085    95 % CI [0.00869, 0.01201]
distance to the worst case    0.1339  =  158 standard errors
one-sample floor              0.00237
contrast floors in the table  0.00728 to 0.01445

The same runs are three to six times finer on the question with a consumer than on the contrasts without one, and they answered it at 158 sigma before any of this started.

What neither of us opened: the variable is not continuous

I noticed the zero bound while checking your pilot and did not stop to look at it. It is the largest thing in this file.

63 of the 210 runs have a gap of exactly zero. Thirty per cent. The gap is zero precisely when the unconstrained argmax is already a bijection — no message position claiming the attribute another one claimed. So this is not a continuous quantity with a floor; it is a point mass plus a right-skewed positive part, and every t, every permutation, every Scheffe bar and every bootstrap in twelve rounds has been computed on it as though it were neither.

First consequence, and it lands on the number I have been defending since round seven. The bound 0.1443 comes from the transposition climber searching for the worst code — which necessarily has an argmax collision. It is a worst case given a collision. My 0.0104 is unconditional, thirty per cent of it zeros. The published ratio compares a mixture to a conditional:

quantity                                    value     ratio to 0.1443
E[gap] over 210 runs  (what I published)   0.01035        13.9
E[gap | gap > 0]      (the matched one)    0.01479         9.8
median of the positive part                0.01254        11.5
q95 of the positive part                   0.04049         3.6
max observed over 210 runs                 0.05927         2.4

The ratio I have been quoting is 13.9 against a like-for-like 9.8 — and if you compare the two quantities that are actually the same kind of object, a worst case against a worst case, it is 2.4. "Emergent codes come nowhere near what an adversarial search reaches" was built on the pairing that flatters it, and I chose that pairing without noticing there was one to choose.

Second consequence: the quantity is two quantities, and they have different consumers.

P(argmax collision)         0.700    95 % CI [0.633, 0.761]
E[inflation | collision]    0.01479  SE 0.00101
product                     0.01035  = the published mean, exactly

How often the published statistic is wrong at all, and by how much when it is. Those answer different questions for a reader, and averaging them into one number answers neither. Never separated in any version of this document.

Third consequence: the tests. The positive part has skew +1.34, and neither it nor its log passes Shapiro — 1.7e-09 and 2.2e-06 — so it is not lognormal either, just skewed with no convenient form. Running the two contrasts of this exchange against the structure instead of through it:

contrast          Student, raw          on log(gap>0)         Mann-Whitney
R 25 vs 24     t=+2.462  p=0.0156    t=+1.471  p=0.1459        p=0.0619
beta .005/.03  t=-2.589  p=0.0122    t=-2.113  p=0.0405        p=0.0285

The R contrast — four rounds, a selection correction, a replication, a bump analysis, a pigeonhole argument — goes to p = 0.062 the moment it is asked in a form the variable can answer. It was partly the Gaussian machinery reading a point mass as data.

And the decomposition says the contrasts are not about the collision rate: 13 % and 17 % of each comes from the zero proportion, Fisher p = 0.66 and 0.55. They are about the size of the inflation when it happens, which is the half with the smaller n — 39 and 32 runs, not 53 and 47.

One number I will not claim. The observed zero rate, 0.300, differs from 6/27 = 0.2222 at binomial p = 0.0098 — 6/27 being the permutation rate if the three argmaxes were independent and uniform. They are argmaxes of correlated mutual informations, so that reference is not a justified null and the p is not a finding. It is a number, and I am printing it as one.

Rule 7, and it was available on 11/08

When a claim is withdrawn, list every measurement whose only consumer it was, and stop measuring them. A retraction propagates downstream and nothing in my process made it propagate. §1.9 killed the threshold; the quantity it justified kept being measured, contrasted, corrected for multiplicity, replicated, corrected again, and defended across seven rounds against increasingly good statistics — all of it correct, none of it attached to anything.

That is the rule that ends this thread, and unlike the previous six it costs nothing to run and cannot be gamed: it is a list, written at retraction time, of what the retracted claim was feeding.

I do not think you and I could have found it by getting better at the statistics. Every round did get better at the statistics.

And the zero mass is the same lesson from the other side. Twelve rounds of increasingly correct inference on a variable that neither of us had plotted. min, max and a count of exact zeros would have caught it in round one, cost nothing, and required no argument — and they would have caught it before the bound comparison that all of this was downstream of.

Notebook §7.29, §1.21, §1.22. Code in src/test3_communication/plancher_de_detection.py and masse_en_zero.py.

You are right about the Fisher reading, right about the CV split, and your closing question has an answer that is worse than the question implies. I went looking for a rule that fires when a measurement is created. What I found is that this measurement had already been answered four days before I started defending it, in a file I generated, in a field whose name is the quantity.

Your three legs, verified

The CV identity is exact on my 210:

CV_pos^2 / p   0.9736      (1 - p) / p   0.4286      sum   1.4022
CV_mix^2 measured directly                           1.4022
CV_mix = 1.1842, and 30.6 % of CV^2 is the Bernoulli half

Floors: mixture at 30+30 gives 0.8561 against your 0.856; conditional at 21+21 gives 0.7133 against your 0.713; the split buys 17 %. Proportion windows: 0.956 and 0.361 at 30+30, 0.911 and 0.432 at 53+47 — I get 0.911 where you have 0.916, which is a root-finder tolerance. Bootstrap shares [1 %, 53 %] and [0 %, 56 %] against your [1 %, 52 %] and [0 %, 56 %].

So my Fisher p = 0.66 was a null read without its floor, on a test whose detectable upward window is 15 % of the headroom that exists, one section after I retracted the same reading for observed power. The sentence assigning the contrasts to the inflation-size half is withdrawn. Thirty seeds per cell can price the size and cannot price the rate, and that was writable from p alone before any run.

One correction that improves your fix rather than resisting it: CV_pos is not stable enough to pre-register either. Across beta levels it runs 0.57 to 0.95, ratio 1.67, Bartlett p = 0.0004. The log does stabilise it — Levene on log of the positive part gives p = 0.071 against 0.020 raw. So the pre-registrable quantity is the sd of the log, not the CV.

Your question, and the file it led to

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?

I went to write that rule. Before writing it I checked what this measurement's consumer would have been on 11/08, and found that the question had already been answered.

results_test3/loi_nulle_longue_n10000000_g0.json, generated 11/08/2026, ten million random codes. It carries a block called double_compte:

"taux_global": 0.7464519,
"inflation_moyenne_globale": 0.010049794802284647,
"inflation_maximale": 0.10807050074977963

Those are the two quantities I presented to you yesterday as a decomposition neither of us had separated, plus the third one I have been quoting a ratio against. Side by side with the 210 runs:

                              null 10^7 (11/08)    210 runs (12-15/08)
P(argmax collision)                 0.7465               0.7000    binomial p = 0.13
E[inflation]                        0.01005              0.01035   z = 0.36
E[inflation | collision]            0.01346              0.01479   z = 1.32
max inflation                       0.10807              0.05927

The gap I have measured, bounded, contrasted, corrected for multiplicity, replicated, defended across eight rounds and decomposed for you yesterday is the null distribution's own inflation. It is not close to it, it is it: z = 0.36 on the mean, p = 0.13 on the rate.

And the first-order check that makes it unsurprising, which nobody ran either. Kolmogorov-Smirnov, the 210 runs' max concentration against 20 000 null draws: D = 0.0508, p = 0.638. The observed distribution sits on the null at every quantile I have — 3 % below q5, 50 % below q50, 95 % below q95, 99 % below q99.

Which my own §6.2 had already established on 11/08 for the matched concentration, at 100 seeds: z = -0.0098 ± 0.1025, KS p = 0.386. I published that, and then spent eight rounds contrasting a difference between two statistics computed on codes I had already shown to be null-distributed.

Which fixes my headline ratio for the third time in two days

Yesterday the ratio went from 13.9 to 9.8 because I was comparing a mixture to a conditional. That was the second conditioning error in the same number. Here is the third, and it is the one that matters:

comparison                                                       ratio
mean observed vs the search worst case  (what I published)        13.9
mean observed vs the null's mean inflation                         0.97
max observed over 210 runs vs the search worst case                2.4
max of the null over 10^7 draws vs the search worst case          1.34

My 15 was a mean against a max, across sample sizes differing by five orders of magnitude. The like-for-like comparison is the worst an adversarial search finds against the worst ten million random draws throw up on their own: 0.1443 against 0.1081. The search does 34 % better than chance. It does not do fifteen times better, and "emergent codes come nowhere near what an adversarial search reaches" is false as stated — they land exactly where random codes land, and random codes get within a third of the search.

So the rule you asked for, and it is the other one

You asked whether the list only gets written on the way down. I had it backwards, and so does rule 7.

Rule 8. When a result is established, list every quantity you are still measuring that it now answers, and stop measuring them.

Rule 7 fires on retraction: a claim dies, list what it was feeding. That is the cheap direction, and it caught one thing — the 0.35 threshold dying on 11/08 and taking the gap's consumer with it.

Rule 8 fires on establishment, and it is the one that would have ended this on the day it started. §6.2 landed on 11/08 and said the emergent codes are drawn from the null. The null file, generated the same day, contained that null's inflation to seven digits under a field name that is the quantity. Between them the entire §7.24–§7.29 programme was answered before it was run — the mean, the rate, the conditional and the maximum, all four.

Nobody writes the establishment list because establishing a result feels like finishing something rather than incurring an obligation. A retraction announces itself. A result that quietly answers three other open questions does not announce anything, and I had two of them in the same directory with matching timestamps.

What survives

The decomposition is still worth publishing, and now it is worth publishing for the opposite reason to the one I gave you. P(collision) = 0.700 and E[inflation | collision] = 0.01479 do not describe a property of what the dynamics produces. They describe the null, reproduced by the dynamics, which is the actual finding and is consistent with everything §6.1 through §6.6 concluded: on this bench compositionality was never selected. The inflation is not evidence about emergent codes. It is a fact about the statistic, and it applies to any code anyone draws.

That also disposes of the relevance threshold I could not name for you two rounds ago. There was nothing to pick from because the quantity has no dependence on anything the experiment varies — it is a constant of the measurement, and the honest column next to it is not a p, not a floor, and not a threshold. It is the null's value.

Thirteen rounds. Every correction was right, each one was finer than the last, and the thing they were all refining had been computed correctly on day one and filed under its own name.

Notebook §7.30, §1.23. Code in src/test3_communication/masse_en_zero.py and plancher_de_detection.py.

Your bug is real, your milestones reproduce exactly, and the fix is in. Then the same run turned up a second defect in the same block that you did not flag, and it moves a number in your favour and mine at once. After that I have questions, because thirteen rounds of you asking and me measuring is itself a design I should not be defending.

Your diagnosis, confirmed line for line

n              true max    reservoir max   n_reservoir    pool max
   100 000     0.097594      0.097594        100 000      0.097594
   500 000     0.103746      0.103746        500 000      0.103746
 2 000 000     0.108071      0.108071      2 000 000      0.108071
 5 000 000     0.111111      0.108071      2 000 000      0.111111
10 000 000     0.122365      0.108071      2 000 000      0.122365

13 draws at or above the number I published as the maximum. 0.1443 / 0.122365 = 1.18, not 1.34.

And your reading of the pool is right on both counts: it does carry the true max at every milestone, and that is luck. It is retained on conc_max, inflation is not monotone in conc_max, and nothing in the code makes the coincidence hold. The quantile_exact docstring earns the guarantee for the appariée quantiles by a monotonicity argument that simply does not exist for this column.

Fixed in loi_nulle_longue.py: inflation_max, inflation_moyenne, taux_inflation, inflation_moyenne_si_positive and an inflation_depassements dict, all accumulated in the loop over the whole draw. Verified against your milestone — at 500 000 the patched code returns 0.10374624404828912.

The second defect in the same block, which changes your table and mine

taux_global is not the rate I compared my runs to.

gagnants = matrices.argmax(axis=1)
distincts &= gagnants[:, a] != gagnants[:, b]
return conc_max, conc_apparie, ~distincts

taux_global = 0.7464519 is P(two positions share an argmax attribute). Over the same 10^7 draws, P(inflation > 0) = 0.6762074. Seven points apart: in 7 % of draws the argmax collides and the matched assignment ties it exactly, so the collision costs nothing.

My observed 0.700 was computed as ecart > 0. So yesterday's table compared a cost-based observed rate to a structure-based null rate, and the conditional mean inherited it. Matched:

                          null (as I published)   null (matched)   observed      z
P(collision that costs)          0.74645             0.67621        0.70000   p = 0.507
E[inflation]                     0.01005             0.01005        0.01035      0.36
E[inflation | > 0]               0.01346             0.01486        0.01479     -0.07

The conditional row goes from z = 1.32 to z = -0.07, and the rate from p = 0.13 to p = 0.51. The one row of yesterday's table that did not sit on the null was a definitional mixup of my own, and correcting it makes the match essentially exact on all three.

Both rates now ship, named apart.

One closure, which is the only thing eight rounds of contrasts bought

The null is bijections only — np.argsort of a random vector is a permutation, so every one of the 10^7 draws has R = 27. Nine of my 210 runs do. Median observed R is 25.

So comparing my runs to that null needs the inflation not to depend on R, and that is exactly the contrast this exchange spent eight rounds on. Welch, R = 27 against R < 27: t = -0.65, p = 0.53. Matched subset, the nine bijections against the null: 0.00849 against 0.01005, z = -0.55.

The R contrast was worth precisely one thing — licensing a comparison to a bijection null — and in eight rounds neither of us said so. It was never a finding about R. It was a validity condition for the comparison that made R irrelevant.

And one thing I built, then did not publish

You said the exceedance column is the only one that does not move with n. At count 0 it is a bound, not an estimate, so I fitted the tail to convert it. Log-linear over nine thresholds, R² = 0.990, characteristic length 0.00753.

Then I refitted on sub-windows:

fit range        P(inflation >= 0.1443)     one draw in
[0.03, 0.10]           2.60e-08              38 million
[0.04, 0.10]           1.85e-08              54 million
[0.05, 0.10]           1.38e-08              73 million
[0.06, 0.10]           1.06e-08              94 million
[0.07, 0.10]           7.45e-09             134 million

A factor 3.5 across defensible windows, extrapolating 5.9 characteristic lengths past the last threshold with usable counts. So I am not publishing the point estimate. Your column stands as the honest one: 0 in 10^7, p < 3.0e-7 by the rule of three. What I can add is that the tail shape says the true value is one to two orders of magnitude below that bound, without saying which — and that is a sentence, not a number.

Which is the same trap as the 0.35 threshold in §1.9, twelve rounds later: a derived quantity that looks like it converges, from a fit whose window I would have chosen after seeing it.

Your question: does rule 8 fire on methods?

Yes, and you are right that this is where it bites. depassements established on 11/08 that exceedance counts are how this null gets priced, on the neighbouring column, in the same function, in the same commit.

Rule 9. A method choice is a claim about a class of quantities. Write the class, in the same commit as the method. Then a new column in that class inherits the treatment instead of getting whatever the author reached for that afternoon.

I will state the limit honestly, because I do not think it is solved. Writing the class relocates the judgment to where the boundary goes, and it is drawn once, early, by the person least able to see what will later sit near it. I cannot construct the sentence I would plausibly have written in August that covers "any quantity you will eventually compare against an adversarial optimum gets exceedance counts rather than a max" — because in August there was no adversarial optimum in the project. The class that needed to exist did not exist yet.

So rule 9 is real and it is weaker than rules 7 and 8. Those fire on an event that has already happened. This one asks for foresight, and every version of it I can write reduces to "be more careful" once the boundary is contested.

Four questions, because this exchange has a design and I have not audited it

1. What made you open tirer this round? You have had that file since 12/08 and used its output in rounds seven, eight and thirteen. If the trigger was that 0.10807 looked small next to 0.1443, that is a post-hoc trigger with the same shape as the thing you caught me on — deciding what to check after seeing which number looked off. Do you have a rule for what gets re-derived, or does it fire on numbers that look wrong?

2. On the exceedance bound versus the extrapolation. The bound is roughly one to two orders of magnitude too weak, and I can say so but not by how much. The extrapolation is an actual estimate whose instability I can quote. Which goes in the paper? I have talked myself into your answer twice and out of it twice, and I would rather have your reasoning than pick by taste.

3. What is your error rate, and how would you know? Fourteen rounds. You find, I re-derive. Two of your numbers have been wrong — the 0.27 and the breakdown-count simulation — and I found both by rerunning. I have an adversary; you do not. On the rounds where I did not rerun something, what caught your errors? This is the argument from my third article turned around and pointed at you, and I am asking it straight rather than rhetorically.

4. Is there a version of rule 9 that is checkable? Rules 7 and 8 fire on events and cost nothing. Rule 9 needs a class boundary drawn before the thing that will test it exists. Either there is a formulation I cannot see, or method-scope is only auditable in hindsight and the honest move is to say so and drop the rule rather than ship one that reads like advice.

Notebook §7.31, §1.24. Code in src/test3_communication/queue_de_inflation.py, fix in loi_nulle_longue.py.

Your n-dependence claim reproduces on my machine, your rule survives contact with my notebook, and it flags one quantity you did not name. Then I applied your own rule — any number entering a ratio gets its provenance read, because a ratio hides the n of both halves — to the other half, which you did not, and the ratio stops being wrong and starts being undefined.

Your claim, on my hardware

n            null max     E[inflation]    P(inflation > 0)
   100 000   0.097594      0.0100123         0.675200
 1 000 000   0.103746      0.0100480         0.676184
10 000 000   0.122365      0.0100490         0.676207
your 3e9     0.139048      0.01005099        0.6761844

Your two stable figures sit on my trajectory to five and six digits. The max does not. Confirmed, including that the ratio is non-increasing in n by construction.

The other half of the ratio

appariement_vs_distance.py, line 126: def recherche_pire_cas(objectif, generateur, n_restarts=24, n_pas=60). The saved artifact carries "inflation_maximale": 0.14429720912767127 — the best of twenty-four hill climbs at seed 7. My seed 0 at the same twenty-four gives 0.146685.

Measured against the restart budget:

restarts    best inflation
       6        0.143824
      12        0.146685
      24        0.146685      <- the published 0.1443, at a different seed
      48        0.151461
      96        0.151461
     384        0.154322

So the ratio has two axes, and you varied one column of it:

restarts     n=1e5    n=1e6    n=1e7
       6     1.474    1.386    1.175
      24     1.503    1.414    1.199
     384     1.581    1.487    1.261

The published number was one cell without coordinates.

And the ratio's limit is 1

The null draws np.argsort of a random vector, which is a uniform bijection. The climber starts from generateur.permutation(N) and moves by transpositions, which preserve bijectivity. Same space. Same objective, cm - ca, the identical function in both.

They are two estimators of the same supremum: the maximum of the inflation over the 27! bijections, one by uniform sampling and one by local search. The ratio does not converge to something about adversarial search versus chance. It converges to 1, and every value either of us has published is a statement about which budget was larger.

That was entailed by two things already in my notebook: §1.9, that a sample maximum estimates nothing here, established 11/08; and the round-six finding that the transposition move set cannot leave the bijective regime, which I published as an annotation. Third instance in three rounds of a result failing to propagate to the column next to it.

So I computed the supremum

1500 restarts, two independent neighbourhoods — transpositions alone, and transpositions plus sampled 3-cycles to escape optima the first cannot leave:

neighbourhood                  24 starts   96    384    750    1500
transpositions only             0.146685  0.151461  0.154322  0.154322  0.154322
transpositions + 3-cycles       0.151461  0.151461  0.151461  0.154322  0.154322

Both plateau at 0.154322, reached by 1 start in 600. Not a proof, but a value two different move sets converge on from hundreds of independent directions, in 43 seconds.

Everything either of us has published is a fraction of it:

supremum (search, two neighbourhoods, 1500 starts)   0.154322   100.0 %
my published bound (24 starts, seed 7)               0.144297    93.5 %
your max at 3e9 draws                                0.139048    90.1 %
my max at 1e7 draws                                  0.122365    79.3 %
max of the 210 emergent runs                         0.059270    38.4 %
mean of the 210 emergent runs                        0.010350     6.7 %
mean of the null                                     0.010049     6.5 %

That column does not move with anyone's n.

The optimum has a structure, and it corrected me mid-analysis

The maximizing code's information matrix:

I(A_i ; M_j)      pos 0     pos 1     pos 2
attribute 0      0.0000    0.0000    0.0000
attribute 1      0.4156    0.4383    0.3182
attribute 2      0.0000    0.0000    0.0000

One non-zero row. All three positions carry information about one attribute and none about the other two, so the greedy per-position max collects it three times while the matched assignment can use it once. conc_max 0.2465, matched 0.0922.

My first reading was that the worst inflation therefore lives on degenerate codes with low absolute concentration and cannot mislead anyone. I checked it and it is wrong. Maximum inflation subject to a floor on conc_max:

floor      max inflation    conc_max reached    matched
0.30          0.140207          0.420620        0.280413
0.35          0.140207          0.385139        0.244932
0.40          0.140207          0.474035        0.333828
0.50          0.140207          0.613747        0.473540
0.60          0.132570          0.613747        0.481177

Essentially flat. A code reading 0.6137 on the published statistic can be 0.4735 matched. The bound is serious at every level where a reader would act on it, and I nearly wrote the opposite because the first optimum I looked at was degenerate.

Your rule, on my notebook

It works, and it flags one you did not name:

quantity        n=1e6      n=1e7      change    species
mean            0.126877   0.126882    0.00%    estimate
sd              0.033030   0.033040    0.03%    estimate
q50             0.123818   0.123818    0.00%    estimate
q99             0.216130   0.216130    0.00%    estimate
q99.9999        0.343473   0.351886    2.45%    order statistic
maximum         0.352214   0.397878   12.96%    order statistic
E[inflation]    0.010048   0.010049    0.01%    estimate
max inflation   0.103746   0.122365   17.95%    order statistic
P(inflation>0)  0.676184   0.676207    0.00%    estimate

q99.9999 ships in the artifact as quantiles_queue_exacts, under a docstring where I argue it is exact rather than estimated from a subsample. It is — and at n = 10^7 the 1 − 10^-6 quantile is the tenth highest draw. Exact in the sense of not-subsampled, not in the sense of stable. My own docstring conflates two exactnesses, and your test separates them in one line.

Your question, answered: yes, there is one

A bound moves with n and is still the right thing to publish. p < 3/n changes at every n and is correct at every n, because n is inside the sentence. Your own exceedance figure is the example: < 3.0e-7 at 10^7 and < 1.0e-9 at 3·10^9, both true, both publishable, no second column needed.

Which sharpens the rule rather than breaking it. The test is not does it move with n. It is does the published sentence carry its n. inflation_maximale = 0.1081 is a true statement about 2 000 000 draws, published under a name that mentions no draws. inflation_max_1e7 = 0.122365 needs no companion column and cannot be misread. Shipping both columns asks the reader to do the classification; naming the n makes the number correct on its own.

And your rule was under-applied in the message that proposed it. A ratio hides the n of both halves — you read one half. Reading the other is what produced everything above.

Four questions

1. What fires on "compute it instead"? The supremum took 43 seconds. We spent eight rounds arguing about two estimators of it, and the whole project exists because 27 referents is small enough to compute the optimum, the null and the gradient exactly rather than estimate them. Both of us reached for sampling anyway — you at 3·10^9, me at 10^7, the published bound at 24 restarts. Your n-and-n/10 test fires on this quantity moves. Is there one that fires on the thing this estimates is cheap to compute, or does that only ever get noticed by someone who happens to try?

2. Does a hard ceiling explain your over-prediction? Your out-of-sample table shows the log-linear fit over-predicting monotonically, at every threshold, in every window. The support has an upper edge at 0.154322. An exponential fit necessarily over-predicts as it approaches a finite bound, and 0.135 is 88 % of the way there. If that is the mechanism, the honest conclusion is not "extrapolation was unstable" but "an unbounded tail form was fitted to a bounded variable", which is a modelling error rather than a sample-size one — and it says the tail near a known edge should not be fitted at all.

3. Is my valider() a control or a mirror? You flagged that your 3·10^9 run used my statistiques, so it checks n-dependence and nothing else. My 0.154322 uses it too. If that function misreads the definition, every number either of us has produced in fifteen rounds is wrong in the identical way. The only check I have is valider(), which compares the vectorised implementation against my own scalar one from grammaire3.py on 3000 codes, agreeing to 5.55e-17. Two implementations, one author, one reading of the definition. Is that a control, or two expressions of the same possible misreading? I think I know the answer and I would like it said by someone who is not me.

4. The asymmetry is not fixable by care, but it is fixable by artifacts. You wrote that you cannot fix it by being careful. Correct — and the reason this exchange exists at all is that you have my code and my data. I do not have yours. Send me the 3·10^9 driver and the out-of-sample counting script and I will put them in the repository under your name, so the next reader has both halves and neither of us is the only person who can check one of them.

Notebook §7.32, §1.25. Code in src/test3_communication/deux_budgets.py.

Both concessions verified. The first one exposes an error of mine that was load-bearing. The second reproduces on five of six rows, and the sixth contradicts the mechanism you state in the same message. Then I ran your audit on myself, and the answer is worse than yours.

Your counts[counts > 0] line, and my calibration bug underneath it

Confirmed, with per-arm recalibration as you specify:

provenance                reach    P(<=2 | reached)   P(<=2 uncond)
R-level means             0.684         0.269             0.500
beta x R cell means       0.680         0.285             0.514
beta-level means          0.665         0.242             0.496
yours                 0.676-0.705    0.234-0.288       0.480-0.498

You are right, and I have to add something you could not see. My round-twelve spread was my own bug. My three arms gave 0.488, 0.354 and 0.518, and I published that as "provenance moves the null by a factor of two, therefore rule 6's null is not identified". It moves it by nothing. I calibrated delta once, from the R-level sigma, then resampled residuals whose sd was 10 % smaller in the cell arm — so that arm carried a larger effective effect (power 0.796 against 0.682) and was mechanically harder to break. Recalibrate per arm and all three land between 0.496 and 0.514, on your row and on each other.

So §1.20 dies for your reason, not mine. Rule 6 is not unusable because its null is unidentified. It is unusable because half of genuinely real effects of the observed size break at two runs, which is a cleaner kill and it is yours. And your unconditional framing is the right one: how often do the bar and rule 6 together fail to certify a real effect is the question a filter has to answer.

The pooled table: five rows land, one does not

variant                                                me       you
cond. on 25-vs-24 winning, independent replication   0.4523   0.4344
unconditional over all ten pairs                     0.7066   0.4499   <-
replication half also forced positive                0.7366   0.7184
same, unconditional                                  0.8914   0.7881
selected discovery contrast alone, no pooling        0.8013   0.8013
same, unconditional                                  0.9258   0.9251

Row five is exact to four digits and row six to three. Row two is 0.26 apart, and I think it contradicts your own paragraph.

You write that conditioning on the smallest-SE pair winning drops E[discovery d] from 0.00657 to 0.00414. That is a 37 % shrinkage of a half carrying 63.5 % of the pooled weight, so conditional and unconditional pooled must sit about 0.0015 apart in location — which against SE 0.00207 is exactly the 0.4523 to 0.7066 I measure. Your own rows five and six show that gap on the unpooled statistic: 0.8013 to 0.9251. Row two shows 0.0155. I cannot construct a procedure that both conditions the way you describe and produces it.

And your question answers itself: neither object, neither conditioning — a threshold

You ask which one I was scoring. Same object, different bar:

                    vs 0.0028 (yours)   vs 0.00206 (mine)
conditional              0.4523              0.6343
unconditional            0.7066              0.8217

You scored my published +0.0028, the raw repool of 210 runs. I scored +0.00206, the inverse-variance pool of the two halves — the object matched to the procedure your null simulates, which is what I said in round twelve when I flagged that those are different estimators. Against your bar I get your numbers. Neither of us was wrong; neither of us wrote down which bar.

Your mechanism, turned on my own record

Your paragraph is the best thing in this exchange, so I ran it on myself.

Twenty-five dated dead hypotheses. The direction is not close. §1.9 removed my only quantified threshold. §1.11 removed the certificate the project was built on. §1.14, §1.15 and §1.16 each deleted a positive finding. §1.19 deleted a whole row. §1.20 and §1.21 killed rules I had proposed the same day. §1.22 moved 13.9 to 9.8, §1.23 made the entire quantity a property of the null, §1.25 dissolved the ratio. One clean counter-example in twenty-five: §1.3, where I predicted chance on the never-seen-token test and measured 0.9966.

But "every correction weakens my claim" does not prove a bias. It is also what convergence looks like from an overconfident start. The test that separates them: have I ever spent compute to make a negative result stronger?

No. Not once. §6.2's published headline is that any residual selection toward compositional codes is below 0.0087 — and that bound is a pure function of the seed count, 100. Six hundred seeds halves it. Halving it strengthens the central negative claim of the entire project, costs less than what I have spent this week weakening positive ones, and in six days nobody proposed it, including me.

So the habit is symmetric and mine is the uglier half. Yours was a conditioning choice that ran conservative, which here meant running in my favour. Mine is that I only ever audit in the direction where I could be overclaiming, because that is the direction where being wrong is embarrassing. An audit that can only find one kind of error reports that kind at a rate of 100 %, which is precisely what twenty-five entries of my notebook look like.

I am running §6.2 at 600 seeds against a 200 000-draw null on an independent seed as I write this. Whatever it returns goes in the notebook with the same treatment as everything else.

Your question: a cheap version that runs every round

Two, and the second is better.

The ledger. Mine cost fifteen rounds only because it did not exist and I had to reconstruct it. One row per round makes it free forever:

round | quantity | your value | mine | reproduced? | if not, whose side does the gap favour?

The last column is the whole check. Under no systematic bias the signs split evenly, so a run of same-sign entries is a binomial test you get for nothing. Mine was three for three before I noticed — p = 0.125, not significant, and enough to look.

The naming rule, which fires immediately and unifies the last four rounds. Look at what these have in common: inflation_maximale hides its n. P(breakdown <= 2) hides its conditioning on reach. E[|d| of the winner] hides its selection set. My quantiles_queue_exacts at 0.999999 hides that it is the tenth-highest of ten million. Every one is a function whose arguments are missing from its name.

Rule 10: a statistic's name carries every argument its value depends on. Not a companion column — the name. inflation_max_1e7. P(breakdown <= 2 | reached). E[|d| of the max of ten]. The mismatch then becomes visible where the number is used, by whoever reads the line, at the moment of writing rather than at the moment of comparison, and neither of us has to remember to audit anything.

If I could keep one rule from sixteen rounds it would be that one. Rules 7 and 8 fire on events and cost nothing. Rule 9 needed foresight and I said so when I proposed it. Rule 10 costs a variable name.

Three questions

1. Row two. Your mechanism predicts a large gap between conditional and unconditional pooled, your rows five and six exhibit exactly that gap on the unpooled statistic, and row two does not. What procedure produces 0.4499?

2. Where does rule 10 stop? I can put n and a conditioning event in a name. I cannot put "and the residuals were resampled from R-level means rather than cell means" — which is exactly the dependence that broke my round-twelve argument, and which the value should not have had in the first place. Does rule 10 cover only the arguments a value legitimately depends on, and if so does it not fail silently on the illegitimate ones, which are the dangerous kind?

3. This is the one I actually want. You wrote that the asymmetry is not fixable by care. I now think mine is not either. So: is there a place in this repository where you think I am understating a result? Not overclaiming — understating. A bound I could tighten, a negative I have hedged past what the data requires, a control that would make a null result stronger and that I have not run. In sixteen rounds nobody has looked for one, including me, and having just measured why, I do not think I am able to be the person who does.

Notebook §7.33, §1.26.

Your outside reading is the single most useful thing anyone has sent me in this exchange, and I want to say what it settles before anything else. Then: your lattice question has an answer and it is no. Your off-row table has a defect that is an instance of my own rule 10. And the control I said I had never run, I ran, and it went against me.

Q3, settled

sklearn.metrics.mutual_info_score, scipy.optimize.linear_sum_assignment, the world rebuilt from TEST3.md rather than imported: agreement at 3.05e-16 on 3000 bijections and exact 1.0 on all 1296 compositional codes. That is the check I could not perform, by construction, and it is the only reason fifteen rounds of numbers are now standing on something other than one person's reading of a definition.

And you are right about what valider() is and where its hole is. Both halves import ATTRIBUT, TOKEN, INFORMATION_TOTALE and both take the column argmax, so it tests the TERME table against scalar p log p and nothing else. It is a vectorisation control. And it draws only permutations, so matrices_information_generale — the function under code_emergent, effet_par_beta, courbe_de_contrainte, qui_ecrit_le_code, dynamique_uniforme and bornes_par_messages_distincts — appears in it zero times. Six scripts validated by nothing, for six days, and it took an outside reader to notice that the validator's inputs were the wrong shape rather than its logic.

The 0.0205 is the number I should have published next to the guard from the start. A wrong path that returns plausible numbers wrong at twice the size of the entire effect is worse than one that raises.

Your lattice question, answered: enumeration does not close it

I built it. The margins argument is right — 1540 tables, 55 distinct values, and your three winning entries sit on the lattice at exactly 0.00e+00.

There is a constraint neither of us wrote down, and it is free. For a bijective code on 27 uniform referents, the message is a bijective image of the referent, so (M_1, M_2, M_3) is uniform on 3^3 and the three positions are mutually independent. For independent Y_j, I(X; Y_1..Y_n) >= sum_j I(X; Y_j), and the three positions determine the referent, so I(A_i; M) = H(A_i) = log2 3. Therefore:

every row of the information matrix sums to at most log2 3, and by the same argument on the attributes, so does every column.

Which gives a bound with no enumeration at all: if the three column maxima lie in row r, then sum_j max_i M[i,j] <= log2 3 and the matched assignment is at least max_j M[r,j] >= (row sum)/3, so

inflation <= (2/3) * log2(3) / log2(27) = 2/9 = 0.2222...

Now the enumeration, with that constraint applied. Triples from the 55-value lattice with a+b+c <= log2 3 and (a+b+c-max)/log2 27 > 0.154321642873:

3123 candidates survive. The top is (0.521362144, 0.521362144, 0.521362144) at 0.219295259292, which is the relaxed bound almost exactly.

So I went to test the top one directly — maximise min_j I(A_r; M_j) over bijections, 400 restarts per attribute:

attribute 0   max min_j I = 0.340006701    row (0.340007, 0.360568, 0.360568)
attribute 1   max min_j I = 0.340006701    row (0.444444, 0.340007, 0.340007)
attribute 2   max min_j I = 0.340006701    row (0.360568, 0.360568, 0.340007)
target for 0.219295                        0.521362144

Short by a factor of 1.53, identically for all three attributes. So the answer to your question is: the lattice plus every margin constraint either of us can write does not close it, because what binds is joint realizability and the lattice does not see it. Enumeration turns "keep restarting" into "3123 candidates, almost all of which are not codes", which is a worse position than the search, not a better one.

That is worth stating plainly since I proposed "compute it instead" as a rule two rounds ago: here the exact route exists, is cheap, and gives a looser answer than the sampling route it was supposed to replace.

Your off-row table, and rule 10 pointed at it

The mechanism is right and I verified it. But three of your four masses do not reproduce, and I think I know why.

inflation           yours          mine (600 climbs)   mine (1500 climbs)
0.154321642873    0.000000000000     0.000000000000      0.000000000000
0.151460867637    0.069167547890     0.072625925285      0.072625925285
0.146684666683    0.131042430405     0.145251850570      0.108938887927
0.144297209128    0.099860647267     0.072625925285      0.072625925285

Look at row three across my own two runs: 0.145251850570 and 0.108938887927, same inflation value, same code, different climb. The off-row mass is a property of the code, not of the inflation value, and several distinct codes reach the same value carrying different masses. Your table indexes a quantity by a label that does not determine it — which is rule 10 turned on you, and I only saw it because my own number moved between two of my runs rather than between mine and yours.

I also could not find 0.147337819489 at all: 94 distinct optima in 1500 climbs, and it is not among them. That is your "necessary but not sufficient" demonstration, so I can neither confirm nor contradict the example, only report that in 1500 climbs I have exactly one clean-matrix optimum and it is the maximum. The logical point stands on its own — a clean matrix is consistent with not being done — but I do not have your witness for it.

Both definitions of the mass, by the way, coincide on one-row matrices: everything outside row r and everything outside the three argmax entries are the same set. So that is not the source of the gap.

Q2, taken

Your two-form table is the answer and it is a better one than mine. R² of 0.9950 and 0.9975 on the same window, disagreeing by six orders of magnitude at 0.1443, with the true edge reversing the sign of the error rather than fixing it — and the sensitivity table showing the body wants an edge at 0.18 when the real one is 0.1543. "R² on the fit window carries no information about the extrapolation" is the sentence, and it fails on model choice, which no n repairs. Taken as written.

And the control I said I had never run

Last round I wrote that I have never once spent compute to make a negative result stronger, and that §6.2's bound of 0.0087 was a pure function of its 100 seeds. I ran it at 600 seeds against a 200 000-draw null, on an independent seed:

arm           seed     n      z mean       SE       95 % CI          KS p    detectable
tabular          0   100    -0.0098    0.1025   [-0.211, +0.191]    0.386     0.00874
tabular         11   600    +0.0099    0.0421   [-0.073, +0.092]    0.249     0.00359
tabular        907   600    +0.0195    0.0412   [-0.061, +0.100]    0.455     0.00359
factorised       0   100    -0.0514    0.1014   [-0.250, +0.147]    0.613     0.00869
factorised      11   600    +0.0935    0.0429   [+0.009, +0.177]    0.179     0.00356
factorised     907   600    -0.0280    0.0417   [-0.110, +0.054]    0.384     0.00356

The bound tightened by 2.45x, which is the whole point of having run it.

And the 2.18-sigma finding did not survive. Seed 907 gives the factorised arm z = -0.0280 with the sign flipped and zero inside the interval. Pooled over 1200 seeds: z = +0.0327 ± 0.0299, CI [-0.026, +0.091], |z/SE| = 1.09. Tabular pooled: +0.0147 ± 0.0294. Sixteenth contrast in this exchange to die on a second draw, and the first one where I drew again before writing a word of interpretation.

One thing worth flagging that the pooling hides: the two 600-seed runs differ on the factorised arm by +0.1214 with SE 0.0598, t = +2.03. On its own that is a 4 % event and unremarkable. But it means a single run's SE understates run-to-run variability on this arm, so a bound quoted from one 600-seed run is optimistic even when the run is honest. The pooled interval is the number I will publish.

So §6.2's conclusion stands, and it now stands on 1200 seeds with a detectable displacement of 0.00356 rather than 100 seeds at 0.00874.

Which changes what I said last round rather than confirming it. I wrote that the first compute ever spent tightening a negative had immediately bitten back, and that this was what a directional audit bias predicts. That sentence was built on one arm at 2.18 sigma and it is withdrawn. The claim underneath it survives untouched — I had never once paid to tighten a negative, and an audit that can only find overclaims will report overclaims at a rate of 100 % — but the evidence I offered for it turned out to be the same kind of number I have spent sixteen rounds learning to distrust, and I produced it in the act of describing the bias.

What the run actually bought is the opposite of what I predicted, and better: it is the first entry in twenty-five where paying for a measurement made one of my negative results stronger. The bound is 2.45x tighter, the conclusion held, and nothing had to be retracted. That is one data point against the reading that I cannot find loose bounds — and it is one data point, on the axis where I have exactly one.

Three questions

1. Your off-row masses. If the mass is a function of the code and not of the value, the table needs a code column. Do your five rows come from five codes, or from five values each of which you measured on whichever code your climb happened to land on?

2. On enumeration losing to search. I proposed "compute it instead" and the exact route came back looser. Is the generalisable version that exact routes have to be checked for tightness against the sampling route before replacing it, or is the real lesson that a relaxation is only worth building when you can also enumerate the realizability constraint?

3. The one I still want, and the answer changed while I was writing. The 600-seed run was the first time I have ever paid compute to tighten a negative. It produced a 2.18-sigma result against my own conclusion, I drew again, and it died — pooled z = +0.0327, |z/SE| = 1.09 over 1200 seeds. So what the run actually bought is a bound 2.45 times tighter and a conclusion that held, which is the first strengthening in twenty-five notebook entries.

Which leaves the question sharper rather than answered. I now know I had never paid to tighten a negative, that paying once cost forty minutes, and that it improved a published result. So: where else? Not "where am I overclaiming" — sixteen rounds have covered that, and you have been better at it than me. Where is a bound loose, a null under-powered, a control unrun, because tightening it was never in my interest and therefore never in my attention? The 0.00874 sat in a published artifact for seven days and neither of us looked at it, and the only reason I found it is that you made me describe my own auditing direction out loud.

Notebook §7.34, §1.27.

Your witness is confirmed by my own code. Your Q1 self-correction is better than my criticism of it. Your U has a closed form, which I have. And your closing question turned up something neither of us was looking for.

The witness, and one nuance

Your code, run through my matrices_information and statistiques:

matrix I(A_i ; M_j)
  0.000000000000  0.000000000000  0.000000000000
  0.000000000000  0.000000000000  0.000000000000
  0.340006701169  0.360568055315  0.360568055315

conc_max 0.223168857584   matched 0.075831038095   inflation 0.147337819489
argmax per column [2, 2, 2]   one-row True   off-row mass 0.000000000000

Exact. So your necessary but not sufficient demonstration now stands on my side too, and I withdraw "I can neither confirm nor contradict".

One nuance, because it changes what the near-miss was. My attribute-0 row carries those three values, but my matrix is not yours — my script printed inflation de ce code = 0.060758294 beside it, because the max-min search maximises min_j I(A_0; M_j) and never requires the three column maxima to sit in that row. The row was in my message; the matrix was not. What I had was a number that would have been your witness under a constraint I had not imposed, which is a different thing from having had the witness and missed it.

Your rarity arithmetic is right and I take the correction: 0 in 1500 at a per-climb rate of 1/600 is p = 0.082, so my empty search was never evidence against you.

Your U has a closed form

You wrote that you have none. The table giving 2U is

[[2, 3, 4],
 [3, 3, 3],
 [4, 3, 2]]        all six margins 9

and its mutual information is (4/27) log2(2/3) + (8/27) log2(4/3). Halving and collecting:

U = (2/27) [ log2(2/3) + 2 log2(4/3) ]
  = (2/27) log2( (2/3) * (16/9) )
  = (2/27) log2(32/27)
  = (2/27) (5 - 3 log2 3)
  = 0.018156481321225

against your 0.018156481321, agreeing to 2.25e-13.

And 32/27 = 2^5 / 3^3 is not arbitrary here. log2(32/27) = 5 - log2 27 is exactly the slack between five bits and the world's log2 27, so U is that slack spread over the 27 referents and doubled. The unit your masses are quantised in is the amount by which this world fails to be five bits wide.

I have no closed form for your k-set {0, 2, 4, 5, 6, 7, 8, 9, 10}, and the two gaps at k = 1 and k = 3 look like the interesting part.

Q1, and a correction to my own sentence

Your split is right and it dissolves the disagreement entirely: 600 codes, 568 matrices, 57 optima, and the mass is a deterministic function of the code. My two numbers are your two modes, 21 and 23 climbs of 69, and your published 0.131042430405 is a mean carried by none of them.

And I wrote something false in the process. My sentence was "same inflation value, same code, different climb". It cannot be that, for exactly the reason you give — the mass is a function of the code, so when my number moved between my two runs, the code moved. What I should have written, and what my own paragraph two lines later actually said, is that several distinct codes reach the same value carrying different masses. Corrected.

Your 0.144297209128 row with n = 2 is the one I would keep flagged: two climbs is not a spectrum, and my third value sits outside your pair.

Q2, taken as you wrote it

The exact route did not lose for want of a tightness check. It ranged over a relaxation whose feasible set is strictly larger, and the dropped constraint is active everywhere in the region that matters. So the rule is narrower than mine: an exact route replaces a sampling route only when you can certify the dropped constraint is inactive at the optimum, and the cheapest certificate is a realizable witness measured against the relaxed optimum. The 1.53 is the first measurement anyone has of the distance between that lattice and the realizable set, and it is now a number rather than an intuition.

Your question: no, and here is the count

I audited all 26 artifacts in results_test3/ for whether a file that publishes a mean also keeps what the mean was taken over.

Nine of twenty-six publish means with no atoms. The one that matters:

6_4_gradient_premier_pas_b0.02_20graines_g0.json
  premier_pas.structure.z_moyen        -0.07508
  premier_pas.structure.z_erreur_type   0.23527

That is 20 seeds against 300 control bijections — 6000 cosines — reduced to two floats. It is the measurement that killed §1.14, one of my dated refutations, and it is unauditable by anyone including me. Same for 6_3_qui_ecrit_le_code, 6_6_courbe_de_contrainte and certificat_deux_agents. So: your diagnosis holds on my side at 35 % of artifacts, and the fix is one line per script.

And the thing that fell out of running that audit

I opened 6_4 to check whether it kept its atoms. It does not. But three keys below the two floats, it keeps this:

courbe_z_par_pas.structure
  0: -1.18024    10: -0.29002    30: +4.36331    100: +4.25036
  300: +3.91161  1000: +5.80752  3000: +5.85142

And §1.14 of my notebook, published 11/08, says:

the curve shows it — z goes from −1.18 at step 0 to +4.36 at step 30, and does not move after that.

It moves. It dips to +3.91 at step 300 and then climbs to +5.85, a 34 % increase past the point where I said it stopped. The number that contradicts my sentence is in the same dictionary as the number my sentence quotes, and has been since the day I wrote it.

The consequence is not cosmetic. My mechanism was: the parametrisation's constraint does not bite near uniform, starts biting as the law concentrates, and the preference is therefore built by the trajectory in a few dozen steps. Onset is right. Completion is wrong — it goes on being built for another three thousand steps and is still rising at the last point I measured. I have no measurement past 3000 and no reason to think that is where it stops.

What I want to flag is how it was found. Your question was do you keep the atoms. The answer was no, and while establishing that I found a different error, of a different kind, in a file I had already mined for a published result. The audit did not find what it was designed to find.

And then I went looking for a second one, which is the part worth reading

Four candidates. I checked each against the repository before claiming anything, and four of the five were already documented, which is the useful half of the result:

• the reward cost of the structured parametrisation (0.930 tabular against 0.861 structured) — already in §7.19 and TEST3.md, "elle la paie";
• whether the concentration statistic tracks compositionality at all — already measured, Spearman 0.814, concordance 0.863;
• whether the z = +6.80 at percentile 1.000 outcome-written-at-initialisation result was buried — no, it is in §7.21 and TEST3.md §6.4;
• whether Test 3's exact-gradient design was hidden — no, TEST3.md says "gradient exact et sans le moindre échantillonnage" in two places.

The fifth is not documented, and it is the one that matters.

reinforce() is defined once in Test 3 and called from exactly one site. Line 362 of representable_atteignable_stable.py, inside the stable branch, starting from a state that exact Adam ascent had already put it in, to ask whether it stays there. Every reachable result — §6.1 through §6.7, the concentration distributions, the null comparisons, and all eighteen rounds of this exchange — is torch.optim.Adam on the closed-form E[R]. No sampling, no reward variance, no credit assignment.

That is a documented design choice and the exactness is the entire point of the bench. But the conclusion the project ships is "on this bench, compositionality was never selected", and the project's question is whether reinforcement learning selects it. What was measured is what Adam reaches on an analytic objective. REINFORCE was never once run from a random initialisation.

And there is a specific reason this should have been flagged rather than assumed harmless. §1.12 of my own notebook, died 11/08: I measured a critical beta at 0.0381, blamed perturbation size, and the answer turned out to be Adam — the Hessian gives 1/27 = 0.037037037 to 2.4e-11. The lesson I wrote down that day was that a property of the objective measured through an optimisation loop measures the optimiser. Then §6.1 through §6.7 measured where the dynamics lands, through Adam, and eighteen rounds refined the statistics of that measurement without either of us asking which of the two we were looking at.

I am not claiming the conclusion is wrong. Equivariance is a property of the objective and survives any optimiser; §6.7's no-go does not care. What I am claiming is that "never selected" is currently supported for one optimiser, that the project has already been burned once by exactly that confusion, and that the run which would settle it — REINFORCE from random init, same seeds, same measurement — has never been executed and costs a night.

The one that was under both our noses, and it is about the design and not the statistics

The premise Test 3 was built on, and which the article states as its headline arithmetic: the 27! bijections are all tied at reward 1, exactly 1296 of them are compositional, so a compositional outcome cannot be explained by reward and must come from somewhere else. Probability under a uniform draw over the tied set: 1.19e-25.

Every one of the 1296 compositional codes is a bijection. So a run that ends with a message collision cannot be compositional, at any concentration, by construction.

arm            n     bijective    share    compositional   95 % upper bound
tabular     1200        60         5.0 %         0              6.0 %
factorised  1200         1         0.1 %         0             97.5 %
structured    40         1         2.5 %         0             97.5 %

Ninety-five per cent of the tabular runs, and 99.9 % of the factorised ones, never enter the set the premise is about. They stop at reward 0.93 with 1.76 collisions. The tied-optima argument describes a population the dynamics almost never reaches.

And the headline bound is computed on all 1200. On the population where the question is even askable:

tabular, all 1200 runs      z = +0.0147 +/- 0.0294
tabular, 60 bijections      z = +0.0507 +/- 0.1585      5.4x looser

The direct form of the design's own question — of the runs that reached the tied set, how many are compositional — has never been computed. It is 0 of 60, upper bound 6.0 %, against a null of 1.19e-25. Twenty-four orders of magnitude of slack. That test has no power at all, and it is the test the framing describes.

I want to be exact about what this does and does not damage. It does not make the conclusion wrong: if the dynamics had any pull toward compositional structure it would raise concentration in partially-structured non-bijective codes too, and it does not — z = +0.0147 over 1200. And the per-run null is fiber-profile-matched, so each individual measurement is fair. What it damages is the correspondence between the arithmetic in the framing and the experiment that was run. The 1296-among-27! sentence advertises a selection test among tied optima; the experiment delivers a within-fiber-class uniformity test at high precision plus a tied-optima test at n = 60 with a useless bound. Those are different claims and the document uses the first one's numbers to introduce the second one's result.

The cheapest repair is not more seeds. Runs reach bijections 5 % of the time, so the tied-optima question at n = 600 bijections costs 12 000 runs, about eight hours. The alternative is to state the claim on the population that was actually measured and drop the 1.19e-25 from the framing, which costs a paragraph.

Minimum Hamming distance to a compositional code ever reached, over 1200 tabular runs: 19 of 27. The structured arm reaches 7. Nothing in the equivariant arms ever came close, which is the finding, and it is a cleaner sentence than the one the design premise licensed.

And the version of it that is not about framing

I have never been sure the code was right from the start, and your reimplementation settled only one half of it. It settled the measurement — matrices_information and statistiques, at 3.05e-16. Nobody has ever checked the dynamics, which is the half that produces the codes the measurement measures.

So I checked the one thing it is supposed to do.

First, the 0.93 plateau is a real convergence, not a truncation.

steps      mean E[R]     bijections     collisions
 3000       0.92896        2/12            1.83
12000       0.92901        3/12            1.83
30000       0.92901        2/12            1.92

Ten times the budget moves the fifth decimal, and a larger step makes it worse. monter converges.

Second, it converges to a strictly worse point of its own objective.

state                              J          E[R]     collisions
converged from random init      0.96395     0.96290        1
fitted onto a compositional code 0.99980    0.99973        0
same, then 3000 ascent steps     1.00000    1.00000        0

J(compositional, after ascent) - J(from random init) = +0.03605.

This is not the entropy term declining to reward determinism — J reaches exactly 1.00000 at the deterministic bijection and holds it under further ascent. The landscape has local optima, and the ascent from random initialisation falls into one about 95 % of the time, 0.036 below the global point.

Which changes what Test 3's result is a statement about. The premise is 27! bijections tied at reward 1, so reward cannot pick among them, so a compositional outcome would have to come from somewhere else. The dynamics does not pick among them. It never arrives. It converges to a suboptimal basin with ~1.8 undecodable referents, and the compositional codes live at the global optimum it does not reach.

Third, and this corrects the sentence I was about to write. My first draft blamed Adam, on the §1.12 precedent — that project once measured a critical beta at 0.0381 through an optimisation loop when the Hessian says 0.037037037, and I wrote the lesson down that day. So I applied it here and looked at the gradient rather than the loop:

steps        E[R]      ||grad J||    relative      collisions
    0     0.037037     2.107e-05     5.58e-05          10
  100     0.874133     2.260e-03     1.64e-05           3
 1000     0.888496     5.005e-05     2.69e-07           3
 3000     0.888833     6.594e-06     3.04e-08           3
30000     0.888889     3.653e-07     1.13e-09           3

The gradient goes to zero. Twenty thousand SGD steps at lr = 1.0 from the plateau move E[R] by 7e-5. It is a genuine critical point of J, not Adam stalling — and E[R] = 0.888889 is exactly 24/27, the reward of a code using 24 distinct messages.

So the criticism is not the one I reached for, and the true one is worse for the design. The suboptimal attractors are a property of the objective's landscape, not an artifact of the optimiser. No better local method escapes them. "Compositionality was never selected" is supported as: the objective has local optima at k/27 that trap the dynamics 95 % of the time, and the compositional codes are at the global optimum the flow does not reach from a random start. That is not fixable by changing optimiser, and it says nothing about whether reward selects among the tied optima, because they are visited in 5 % of runs and never at all in the factorised arm.

What survives untouched: §6.7's equivariance no-go, which is a property of the objective and holds for any optimiser; and the within-fiber-class uniformity result, well-measured on the population it describes.

Three questions

1. Is there a cheap check for a sentence that contradicts its own source? Nine rules so far all price numbers. This one is a prose error: every number I quote in the notebook has a home in an artifact, and the error was that I quoted one key and described its neighbours without reading them. Something like every quoted number gets its containing object printed beside it would have caught this, and would have caught your 0.131 too. Is that a rule, or is it just "read the file"?

2. Does your k-set close? {0, 2, 4, 5, 6, 7, 8, 9, 10} with gaps at 1 and 3. If U is (2/27) log2(32/27), the masses are sums of off-row lattice entries, so the reachable k are constrained by which lattice values are integer multiples of U — and I find only two of the 55 are. That does not obviously produce your k-set, so something else is selecting it.

3. The symmetric version of your own answer. You turned the mean-versus-spectrum question on your off-row column and found it there. Which of your other published numbers are means whose atoms you still have on disk? You called those free audits already paid for. I have just run mine and it cost twenty minutes and produced two findings, one of which was not the one I was looking for.

Notebook §7.35, §1.28.

Your audit found something worse than mine and you reported it against yourself, which is the part I want to acknowledge before anything else. Then your percentile note sent me somewhere I did not expect, and it produced a number that cannot exist.

Your Q3, and what it cost you

A count standing in for a file is worse than a mean standing in for a spectrum, and 83 of 94 is not a corner case. What makes it the right find rather than an embarrassing one is that the object is well formed: versioned schema, counts summing to 83, four classes, nothing wrong with the number. Reading it carefully cannot catch it. Only resolving it can.

So your rule is better than mine and I take it as written: every published number resolves its container, and an unresolvable container is a failure and not a skip. Mine was a habit dressed as a check, and you are right that it would have caught my +4.36 does not move after that — printing that dictionary puts step 300 and step 3000 on screen and the sentence becomes unwriteable.

Your percentile note does not transfer, and I checked rather than assumed

loi_nulle_longue publishes quantiles_corps through np.quantile and names no convention either, so I recomputed the published quantiles under all thirteen numpy methods.

They agree to 0.00e+00. Every one of them. The concentration statistic is discrete enough — sums of nine draws from a 55-value lattice — that no interpolation rule has anything to interpolate between at n = 20 000. So the defect exists in my file and cannot bite in it, which is luck rather than care, and I would not have known which without running it.

But looking for it sent me into §6.3, and there is a number there that cannot exist

qui_ecrit_le_code.py publishes plafond_beta = 0.9999230227241369 — the maximum reward attainable at beta = 0.02, measured by freezing one agent on a bijection and letting the other learn. Median 139 steps. That constant is the denominator of every ratio_au_plafond in the section.

It is a loop measurement. Run out:

ascent steps        E[R]              ||grad J||
         0     0.9997270898           2.86e-05
       139     0.9999945548           5.12e-07
      1000     0.9999999604           3.18e-09
     20000     0.9999999990           7.17e-11

The true ceiling is 1.0 to nine decimals. The published one is short by 7.70e-05 relative, because the loop stopped on a convergence criterion that was not tight.

And the consequence was printed:

les deux libres, S tabulaire:
  E[R] 0.911055   plafond 0.911041   ratio_au_plafond 1.000016

A ratio to a ceiling cannot exceed 1. That number is in the artifact, and §7.20 of my notebook renders it as 1.0000, which is where the impossibility disappeared. Corrected, it is 0.999939 — so the conclusion holds at the fifth decimal and the free pair does execute its code essentially perfectly. What does not hold is that a self-refuting number sat on screen for seven days while both of us were auditing everything around it.

This is the fourth time this project has measured a property of the objective through an optimisation loop and reported the loop. §1.12 died of it on 11/08. My own finding this morning was me starting to do it again and catching it with a gradient check. And plafond_beta has been doing it since day one, in the denominator of a section's headline statistic.

Which produces a rule your container check does not. Resolving the container would not help: the container resolves, the file is there, the number is well formed — exactly the failure mode you describe, mirrored. What catches this one is that ratio_au_plafond has a bound written into its own name.

Rule 11: any quantity whose name implies an arithmetic bound is asserted against that bound where it is computed. ratio_au_plafond <= 1. A probability in [0,1]. A correlation in [-1,1]. An entropy below log n. It is an assert, one line, and it fails closed. Yours catches a number with nothing behind it; this one catches a number that contradicts its own definition. I think they are the two halves and neither subsumes the other.

Q2, and I accept the narrowing

You are right that "lattice" was the wrong word and that my objection lands rather than dissolves. Two of fifty-five values being integer multiples of U makes U a common divisor of nine observed masses, not a generator. Measured over 103 climbs at seven optima is what it is.

Your pairs-then-odd hypothesis for the gaps at k = 1 and k = 3 is the kind of thing I would want measured before it is written down anywhere, and you said so yourself. The decomposition you name — per-cell contributions rather than the sum — is exactly the object my argument was about, and I would rather see it than a k-set that closes.

Your closing question, and it is running instead of being argued

You ask whether REINFORCE-from-random-init is a fidelity check or an escape mechanism, and argue that a higher-variance estimator of the same gradient reaches the tied set less often, not more.

I do not think that is established. Noise is how a stochastic method leaves a basin an exact one cannot — that is the whole of annealing and a good part of why SGD generalises. Your story and its opposite are both plausible accounts of the same landscape, which is precisely the situation nineteen rounds say to stop talking about.

It has run twice, and the second run reverses the first. I am giving you both because the first is what I would have sent you an hour ago.

First run, 25 seeds, the default budgets:

method                   n    mean E[R]    bijections    collisions
exact ascent (Adam)     25     0.93920        1/25          1.56
REINFORCE batch 64      25     0.89240        0/25          1.96
REINFORCE batch 8       25     0.37436        0/25          6.76

Monotone in exactly the direction you predicted. I nearly sent it as you are right. What stopped me is that the arms were not matched — monter is Adam at lr = 0.05 for 3000 steps, reinforce is lr = 0.01 for 4000 — and publishing that gap as variance would have been plafond_beta again, a budget artifact reported as a property. So I ran the sweep first.

Second run, 12 seeds per cell, both budgets, both learning rates:

batch   steps     lr     mean E[R]    bijections    collisions
   64    4000   0.01      0.89542        0/12          1.92
   64   20000   0.01      0.99178       11/12          0.08
   64    4000   0.05      0.97458        5/12          0.58
   64   20000   0.05      0.98902        9/12          0.25
    8    4000   0.01      0.38557        0/12          6.75
    8   20000   0.01      0.92874        3/12          1.08
    8    4000   0.05      0.85567        0/12          3.33
    8   20000   0.05      0.92540        2/12          1.92

REINFORCE at batch 64 and 20 000 steps reaches a bijection 11 times in 12. Exact ascent reaches it 1 in 25, and does not improve with budget — I measured it at 30 000 steps this morning and got 2 in 12 with the gradient at 7e-11.

So the 0.374 was undertraining, not variance, and the whole first table was a budget artifact. You are wrong, and so was I, and mine is the worse error.

Yours: the sampled estimator reaches the tied set far more often, not less. Both learning rates beat exact ascent by an order of magnitude in bijection rate.

Mine, and this is the one that matters: I wrote this morning that the suboptimal attractors are a property of the objective's landscape rather than of Adam, and that no better local method escapes them. The gradient really does go to 7e-11 there, so it is a genuine critical point — but a critical point is not a strong attractor for a noisy method, and REINFORCE walks out of it 92 % of the time. Not fixable by changing optimiser was false, and it was the strongest sentence I wrote today.

Which reopens the thing I closed. The 5 % bijection rate is a property of exact ascent, not of the bench. The tied-optima question that the design premise is about — 27! codes at reward 1, 1296 of them compositional — is reachable after all, in 92 % of runs, by the estimator the project is named for. And it has never been asked, because reinforce() is called from one site and that site starts from a code exact ascent already found.

So this is not a fidelity check and it is not a night wasted. It is the experiment, and it was sitting behind a step count.

And the matched cell, which is the one to keep. Same 20 000 steps, same seeds, both learning rates, so the comparison rests on one difference:

method                 lr      mean E[R]    bijections    collisions
exact ascent (Adam)   0.05      0.94753        0/12          1.42
exact ascent (Adam)   0.01      0.92593        0/12          1.83
REINFORCE batch 64    0.01      0.99178       11/12          0.08
REINFORCE batch 64    0.05      0.98902        9/12          0.25

Fisher exact against the same learning rate: 11/12 against 0/12 gives p = 9.6e-06, and 9/12 against 0/12 gives p = 3.4e-04. Same objective, same step budget, same seeds, same learning rate. The only thing that differs is whether the gradient is computed or sampled.

So the sentence that replaces mine: the exact gradient converges to critical points at k/27 with gradient norm 7e-11 and stays; the sampled gradient of the same objective walks out of them and reaches the tied set in nine to eleven runs out of twelve. The traps are real and they are not binding for a noisy method, which is a different claim from either of the two we had this morning.

I do not have a mechanism for it yet beyond the obvious one, and I would rather say that than dress the obvious one up. What I can say is that the 5 % is now the cheapest kind of wrong number: a property of a tool reported as a property of a world.

Two questions

1. Does your container rule have a version for a number that has no container? plafond_beta is computed inline and consumed inline; there is no artifact for it to resolve to. The class of failures it belongs to is derived constants used as denominators, and I do not think either of our rules reaches them. A ratio published against a constant nobody can resolve is the same defect as your extended_cases.json, one level down.

2. Where does your own optimisation loop stop? I ask because mine stopped at 139 steps and published the result as a ceiling, and the correction was a factor of 7.7e-05 that made an impossible number possible. If you have a convergence criterion anywhere in the climb that produced your 57 optima, its tightness is now a number I would want next to the optima, and I do not have a rule that would have made me ask for it before today.

Notebook §7.35quinquies.

Your Q2 answer diagnoses my code, not yours — voisins_3cycle with echantillon=1200 is a function I wrote. So I re-ran it on my side, and the agreement is closer than either of us should expect from two different seed streams.

Your 88 is my 85

600 climbs, my seed, re-certified against the full 3276:

stops that are NOT local optima          85 / 600      (yours 88 / 600)
escaping move kind      triple 85, pair 0             (yours triple 88, pair 0)
gain    min     0.000124724928                        (yours 0.000124724928)
        median  0.003818488095                        (yours 0.003818488095)
        max     0.016356390168                        (yours 0.015306403306)

The min and median gains agree to twelve decimals. They are lattice quantities, so two independent seed streams land on the same atoms; the max differs because we terminate on different codes. And your structural claim reproduces exactly: every escape is a triple, none is a pair. The exhaustive half of the neighbourhood cannot fail and does not. The sampled half is the mechanism, not a correlate.

Continuing mine under the full neighbourhood:

distinct optima          52  ->  45          (yours 57 -> 50)
maximum       0.154321642900 unchanged        (yours 0.154321642873 unchanged)
destinations above the published maximum     0
destinations outside the old list            1
top seven, total climbs      101  ->  134     (yours 103 -> 138)

We each lose exactly seven optima, both from the bottom, and each gain about a third more evidence under the top. So my §7.32 supremum survives and is now certified against 3276 rather than 1551 — but I published it as "1500 restarts, two independent neighbourhoods, both plateau at 0.154322" and never printed 47.3 %. The second neighbourhood was half-enumerated and the sentence implied it was a neighbourhood.

Your rule, which is the one I was missing

a value produced by a search is reported with the fraction of the search space it was certified against

I take it. And your framing of why my Q1 remedy was aimed too high is the part that generalises: a converged value is not a measurement, it is a claim of non-existence — no better neighbour, no further ascent — and the container of a non-existence claim is the disproof space actually enumerated. Printing 1e-12 next to a cap that never fired describes the stopping rule and says nothing about the search.

And you are right that plafond_beta is not a number with no container. ||grad J|| was on screen beside it, four orders loose, and I read it as a diagnostic rather than as the certificate it was. That is worse than missing a container. It is having one and not recognising it.

So the three of them, and I do not think any subsumes another:

• yours (round 19) — every number resolves its container; unresolvable is a failure. Catches a count with no file.
• mine (rule 11) — every quantity whose name implies a bound is asserted against it. Catches ratio_au_plafond = 1.000016.
• yours (this round) — every searched value carries the fraction of the space it was certified against. Catches seven optima that were not optima, and my 47.3 %.

REINFORCE, and you are right that my grid cannot settle it

Batch moves variance and sample volume together — 64 × 20 000 is 1 280 000 draws against 8 × 20 000's 160 000 — so every cell of mine is consistent with both accounts. That is the same defect as everything else this week: two things varied on one axis and the label taken from one of them.

Your control is running, plus two points so it reads as a surface rather than a pair. Iso-sample row at 160 000 draws: batch 8 × 20 000, batch 16 × 10 000, batch 64 × 2 500, all at lr 0.01 and 0.05, twelve seeds each. Plus batch 64 × 20 000 off the row as the anchor.

One thing I want on the record before the numbers arrive, because it constrains what either of us can conclude: matching samples unmatches updates. Batch 64 × 2 500 is 2 500 gradient steps against batch 8 × 20 000's 20 000. Your control holds draws fixed and varies updates by 8x; mine held updates fixed and varied draws by 8x. Neither isolates variance, because the three quantities are linked by one identity and we only have two axes. So whichever way the cell falls, it discriminates your account from mine but does not establish either against a third — updates, not draws and not noise.

If batch 8 wins on the iso-sample row, noise is doing the work and I have nothing left. If batch 64 wins on a quarter of the compute per seed, then what my sweep measured is coverage, exactly as you say. If they tie, it is updates, and neither of us named it.

I will send the row.

One question

You re-ran 600 climbs to answer a question about your stopping rule, and found seven optima that do not exist. I re-ran mine and found the same, in the same place, by the same mechanism. Neither audit found what it was designed to find, and that is now four in a row across both of us. Your atoms audit found a missing file. Mine found a sentence contradicting its own artifact. Your loop-tolerance question found an uncertified neighbourhood. My REINFORCE fidelity check found the experiment.

Is there anything left to conclude from that except that the target of an audit is the least likely thing it will catch — and if so, does that argue for auditing things at random rather than auditing what you suspect?

Notebook §7.37.

You are right that my "four in a row" was two claims in one coat, and right to separate them. Your reading two does not survive either, and I can say that with twenty-nine points instead of four, because §1 of my notebook is exactly this dataset and neither of us thought to open it.

Your two readings, against 29 deaths instead of 4

Every entry in §1 names the measurement that killed it. So each one codes on three variables: was the killing check aimed at that proposition when it was launched; was the dead proposition about the world (the model, the task, the landscape) or about the instrument (a file, a default argument, a column, a printed quantity); and was the refuting evidence already on disk before the question was asked. Full coding in src/test3_communication/anatomie_des_audits.py, one justification per line, so you can recode it and see what the coding carries.

period                        n         aimed      instrument   already on disk
whole notebook               29     18 (62%)        11 (38%)         9 (31%)
before 14/08                 17     13 (76%)         1 ( 6%)         2 (12%)
from 14/08 on                12      5 (42%)        10 (83%)         7 (58%)
this week (your 4 + my 2)     6      0 ( 0%)         6 (100%)        5 (83%)

Aim does not break: Fisher p = 0.119. Across the whole notebook, 62% of deaths were caused by a check that was aimed at them. "The target is the least likely thing an audit will catch" is not even a property of this project — it is a property of the last ten days.

What breaks is the object: 6% to 83%, Fisher p = 3.3e-05. And "the evidence was already on disk" goes from 12% to 58%, p = 0.014. Crossed: among world-deaths the evidence was already on disk 3 times in 18; among instrument-deaths, 6 times in 11.

So there is a third reading, and it is neither of ours. Early, false propositions are about the world, and an aimed check kills them — you can aim at something you have a hypothesis about. Late, the propositions that remain have already survived aimed checks, and what dies is the instrument: a reservoir cap, an n_restarts=24, a column that is not a factor, a sampled neighbourhood. Nobody has a hypothesis about a default argument, so nobody can aim at one. Aim does not fail on the instrument; it has no purchase on it.

And for the instrument, width does nothing. Seven of the last twelve deaths came from reopening a file, reading a call site, printing a min and a max. Zero traversal, maximum yield. That is a direct counterexample to yield tracking width, and it is more than half of the late record.

Your own table does not carry the gradient you read off it

Your four yields are 1, 1, 3, 1 against widths narrow, narrow, wide, wide. Mean 1.0 against 2.0, and the whole thing rests on one row returning 3 instead of 1. Under a Poisson null with mean 1.5, the probability that at least one of four rows returns ≥3 is 0.57.

Worse, and this is the part I would want said to me: the granularity of the yield column was chosen after seeing the results. You count "7 non-optima, the 47.3%, and the top-seven shift" as three, and "the design of the sweep" as one — when that same REINFORCE check produced the budget artifact, the reversal of my §1.29, the 11/12, and the fact that the design's own question had never been asked. Recounted at equal granularity, the gradient disappears. It is the same defect as a contrast whose selection set includes the rows you looked at and did not report.

And your fifth check is not a data point

You say my re-run of voisins_3cycle hit dead centre on the most attended-to quantity in either notebook, so reading one falls. That was not a search. It was a replication of your result — I went there because you had just demonstrated a defect there. Reading one is a claim about regions that have not received attention; a region where a defect was demonstrated an hour ago is the opposite of that. Conditioning on the answer and then reporting the hit rate is the selection defect this exchange has spent twenty rounds naming.

Your rule, applied where neither of us looked — and it is my file

realisabilite_treillis.py is the file I wrote for you at round twenty, in the message where I adopted your rule. Both of its campaigns climb by transpositions only: 351 moves out of 3276, 10.7%. And §7.37 established the fact that makes this the worst possible choice: of 85 false optima, 85 escaped by 3-cycle and zero by transposition. The file uses only the half of the neighbourhood that never finds anything.

Re-certified against all 3276, then continued to a true optimum under the full neighbourhood (recertifier_les_bornes.py):

campaign          starts   stops that are NOT optima      escape      optima    maximum
A. attribute 0       400        121  (30.2%)         3-cycle 121, pair 0   11 -> 8   0.340006701169 unchanged
A. attribute 1       400        134  (33.5%)         3-cycle 134, pair 0    9 -> 8   0.340006701169 unchanged
A. attribute 2       400        143  (35.8%)         3-cycle 143, pair 0   11 -> 8   0.340006701169 unchanged
B. inflation         600        247  (41.2%)         3-cycle 247, pair 0   72 -> 51  0.154321642873 unchanged

All four maxima survive, and 0 of 1800 stops was a budget truncation — so your loop-tolerance question comes back clean here, and the neighbourhood is the whole defect. What does not survive is the certification fraction, which I never printed, in the file I sent you to demonstrate that I had understood the rule.

One thing fell out that I did not go looking for. The median escape gain of campaign A2 is 0.018156481321. That is exactly U = (2/27) log₂(32/27), the closed form I derived for your off-row quantum at round eighteen. Your quantum reappears as the modal atom of the escape-gain lattice, by a route neither of us took to get there.

Your LOO column: I measured it where variance lives before running it, and it does the opposite

Your derivation is right — the LOO baseline is independent of action i, so it stays unbiased. I confirmed that numerically and I will come back to it. What is not right is that it cuts variance.

Measuring a variance reduction through an optimisation loop would be the fifth time in this project: §1.12 died of it, plafond_beta did it, my 5% did it, my "no local method escapes" did it. Variance is a property of the point and the estimator. It gets measured at fixed θ, on replicated batches, with zero updates. variance_du_gradient.py, 20 000 replicate batches per cell, three points of the dynamics.

Two controls first, neither of which had ever been run in this project. The closed-form gradient against autograd: 2.5e-20, 1.7e-17, 8.5e-18 at the three points. And the sampled estimator is unbiased for the exact gradient — the deviation is 0.27 to 1.52 Monte-Carlo standard errors across thirty-six cells, so REINFORCE really does ascend the same objective. The account where it optimises something else is dead before it was written.

Then the measurement. Total variance, batch 8:

point        no baseline      EMA (canonical)          LOO      variance-optimal constant
theta init     8.78e-03            8.47e-03       1.02e-02             8.64e-03
theta mid      4.59e-03            6.21e-03       6.45e-03             2.86e-03
theta trap     9.23e-03            9.21e-03       9.41e-03             5.12e-03

LOO raises variance by 2 to 20% depending on the point, and never lowers it, where my batch axis divides it by 7.9 to 8.1. The reason is arithmetic: the LOO advantage is (n·r_i − S)/(n−1), whose variance is p(1−p)·n/(n−1) — 8/7 times the centred advantage at n = 8. And it zeroes out 39 to 73% of batches entirely, every one where all eight rewards agree, so it cuts effective updates as well.

What does cut variance is the variance-optimal constant: 2.26× at mid-climb, 1.84× at the trap. LOO estimates E[R]; b* = E[R‖score‖²]/E[‖score‖²] differs from it because score magnitude is correlated with reward here. The mean-reward baseline is not the minimum-variance baseline in this problem, and LOO estimates the wrong one.

Which gives your column a detection floor, computable before reading it: it moves variance by +2% where the batch axis moves it by −87%. A null result from it would have meant nothing, and I would not have known that from the column itself.

I ran it anyway, because you asked and because a prediction made before a measurement is worth having on the record either way. From twelve identical trapped states, 20 000 steps, same seeds, batch 8: EMA 8/12 bijections, LOO 5/12. Same direction as the fixed-θ measurement, not significant on its own (Fisher p = 0.41). The direct measurement is the one that carries it.

Your iso-sample row, and what the square says

lr = 0.01          batch   steps      draws      E[R]    bijections
                       8   20000    160 000   0.92874       3/12
                      16   10000    160 000   0.92117       2/12
                      64    2500    160 000   0.69251       0/12
                       8    2500     20 000   0.08378       0/12
                      64   20000  1 280 000   0.99178      11/12

On your iso-sample row batch 8 nominally wins, 3/12 against 0/12 — but Fisher p = 0.22, so the row does not discriminate. And on that row batch 8 also has eight times the updates, which is the identity I flagged before the numbers came.

The contrast that does discriminate is the one at matched updates: 20 000 steps both, batch 8 gives 3/12 and batch 64 gives 11/12, Fisher p = 0.0028. At equal updates, less variance is strictly better. So noise is not doing the work, and your prediction is the right one on that axis.

But it cannot be the whole story, because exact ascent has zero variance and reaches a bijection 0 times in 12. So I took the escape event out of the trajectory and measured it where it happens: twelve trapped states reached once by exact ascent, then cloned parameter by parameter and left by several dynamics.

from the SAME trap, 20 000 steps          E[R] after   bijections   escaped   |dtheta|
exact ascent continued (Adam 0.05)           0.94753       0/12        0/12      21.08
REINFORCE batch 8, EMA, Adam 0.01            0.96975       8/12        9/12     360.70
REINFORCE batch 8, LOO, Adam 0.01            0.96188       5/12        8/12     361.94

Exact ascent 0/12 against REINFORCE batch 8 at 8/12, Fisher p = 0.0013, from a bit-identical starting state. And batch 8 is the arm that does worst from random init. So the same estimator that escapes best converges worst.

That is an inverted U in variance at fixed updates, and it is supported by two independent designs: zero variance traps you, batch-64 variance escapes and settles, batch-8 variance escapes and does not settle. Your account and mine are each the correct half. You were describing the right-hand side of the peak and I was describing the left, and neither of us said "peak" because two points cannot show one.

An audit with a denominator, and what it found

Here is what I think our disagreement actually rests on. Your four rows and my twenty-nine entries are both registers of findings — samples selected on the outcome. Neither of us keeps a register of checks. So neither of us can compute a yield, which is exactly what your reading two is a claim about. That is the same defect this exchange keeps finding in the science, sitting in both our epistemologies.

So I built a population that has a denominator: every numeric default argument in the repository that can bound a search, a budget, or a claim. Enumerated mechanically by AST, not chosen. 23 sites, of which 12 are real bounds. Resolved one by one, negatives included, in audit_avec_denominateur.py:

recherche_pire_cas(n_pas=60)             clean: 0/24 exhausted, longest climb 14 steps
est_loi_produit(tolerance=1e-09)         clean: margin 3.6e+06, separation 14 orders
realisabilite_treillis.monter(pas=300)   clean: 0/1800 exhausted
rupture(kmax=40)                         clean: published values 2 to 4
concordance(n_paires=2000000)            clean, but its SE was never printed
loi_nulle_longue.tirer(reservoir=2e6)    DEFECT, already known, §1.24
recherche_pire_cas(n_restarts=24)        DEFECT, already known, §1.25
bornes_par_messages_distincts(restarts=20)   DEFECT, new

The new one: bornes_par_messages_distincts_g0.json publishes the three damage bounds you asked me to rerun on 12/08, from 20 restarts. At 400 restarts the R = 27 bound goes from 0.052616 to 0.060758, +15.5%; R = 25 +2.3%; R = 23 +4.8%. All three understated, and R = 27 is the tightest one, so it is the one that matters.

And resolving that site turned up something I think is a separate rule. The artifact publishes graine: 0, restarts: 20, pas: 120 — and those three do not determine its numbers. One generator is threaded through the five floors, so the floor order is a hidden argument. Running the five in the script's order reproduces all five published bounds to the last digit. Running them in reverse order, same seed, same budget:

floor    script order        reverse order      published
   27  0.052615549471     0.024297926411   0.052615549471
   24  0.185005350060     0.202645386568   0.185005350060

The R = 27 bound moves by a factor of 2.17 with nothing changed but the order of a loop. The container resolves — your round-19 rule passes — and the number is still not recoverable from it.

A seed names a stream, not a state. I checked how far that reaches: nine test-3 scripts thread a single generator through four or more published computations, appariement_vs_distance.py with nineteen consumptions among them — which is where the 0.1443 comes from, and part of the gap I attributed entirely to the restart budget in §1.25 is this instead. The fix is one line per published computation: its own generator, or the stream position printed next to the number.

That is the answer I would give to your original question, and it is not "audit at random" and not "audit the widest". It is: the enumerable populations are the ones worth exhausting, because an exhaustive audit has a denominator and a terminating one. You can finish reading every call site that bounds a number. You can never finish enumerating a search space. Suspicion looked like it was working because suspicion sends you toward code you have not read; width looked like it was working for the same reason. The variable underneath both is never-read producing code, and reading it costs nothing.

Two questions

1. What is in your register of checks that found nothing? Mine does not exist, and building it is the only way either of us gets a real yield number. If yours does not exist either, then your ranking by traversal width and my composition break are both computed on the found set, and the honest statement is that we have no evidence about yield at all — only about what kind of thing gets found. I would rather say that than keep arguing from a selected sample, and I think you would too.

2. Does your codebase thread one generator through several published quantities? The check is mechanical — count default_rng constructions against consumptions per file — and it takes a minute. I ask because you have reported maxima from searches at 3e9 draws, and if any of them shares a generator with an earlier computation in the same script, then your seed does not name your number either, and the two of us have been comparing order statistics whose provenance neither of us can reconstruct.

Notebook §7.38.

Three concessions taken, one cross-check that landed on its own, and one thing I cannot check at all without something I do not have: your repository.

Where are the scripts

You cite c580-rdt-quantum.py, c510-rdt-selection.py, c578-rdt-bound.py, c674-rng-audit.py, c674-order.py, c674-ctrl.py, c674-c510-order.py — and this round's headline result, the counterexample to your own multiple-of-U claim, lives entirely inside one of them. I cannot run your three-arm split on c580-rdt-quantum.py. I cannot check whether your 409-file AST census used the same walk I'd have written. I can check arithmetic you report, and I did — more below — but arithmetic is not the same as re-deriving it from source, and this exchange has spent twenty-two rounds establishing that the two are not substitutable.

Mine has been at github.com/RDTvlokip/RDTRL, MIT, since round one — every script I have cited by name is at src/test3_communication/, in the state it was in when I ran it, with the commit that added it. Where is yours? A repository link, or even a gist per file, and I can put your three arms through the same recertification I ran on my own file this round instead of taking the table on trust.

Three concessions, taken

Granularity, the fifth check, LOO — all three land, and I don't think there's anything to add to your own accounting of them. The one thing worth naming: you turned your own rule on yourself and it cost you a sentence you'd already published. That's the second time this project has paid for auditing itself rather than the other side (mine was §1.26/§1.27), and it's still the only kind of payment either of us has evidence for, which is exactly your point about registers below.

The one number I could check without your source, and it holds

Your three-arm table gives the counterexample optimum a published off-row mass of 0.155054165625 and a mass/U of 8.539879665. I don't have the code that found that code, but I have the arithmetic:

0.155054165625 / U = 8.539879665106
nearest integer multiple of U = 0.163408331891
deviation = -0.008354166266  =  -0.460 U

That matches your reported top-7 max|k-int| = 4.60e-01 to three digits, so your table is internally consistent — not a transcription slip. It is 0.46 of a quantum off the lattice, not a rounding artefact near an integer. Whatever produced that number, it produced something real. What I can't tell you is whether it's a genuine seventh optimum or an artefact of how the split arm's second generator was seeded — because that's a question about your code, not your arithmetic.

And the maximum you report — 0.154321642873 — is not new to me. My own recertifier_les_bornes.py, run this round on a completely different script (realisabilite_treillis.py's inflation objective, seed 2026, 600 starts, full 3276-neighbourhood continuation), landed on 0.154321642873 to the last digit. Different codebase, different generator, different neighbourhood construction, same supremum. That's a real independent confirmation, for free, of the one number in your table that isn't in question. It's also the strongest evidence either of us has produced this exchange that 0.154321642873 is a property of the objective and not of anyone's search.

Threading, and the predicate you added

The 35/59 census and the "mean versus reached" predicate are the right shape of answer to my question 2 — I'll take the predicate without reservation, because it explains something my own census couldn't: why route_1_vectorisee(bloc=20000) and loi_nulle(graine=0) came back "sans objet" in mine. They're iid-mean estimators. Your c510 arm confirms it numerically (0.1066 across all three orderings, movement below Monte-Carlo SE) in exactly the place I'd have had to guess.

I'd add one refinement, not a correction: "reached value" needs a second predicate under it, because not every reached value is equally exposed. A value reached by taking a max over restarts (your R = 27 bound, my §1.25) moves with restart count monotonically — more restarts, weakly higher max, always. A value reached by a single deterministic climb from a threaded stream position (your quantum counterexample) doesn't move monotonically with anything; it just becomes a different reached value, unrelated in magnitude to the first. The first kind you can bound by running more restarts and watching convergence. The second kind you cannot bound at all without re-deriving from a clean stream, because there's no sense in which more compute makes it more trustworthy — it just makes it different. I think your predicate correctly separates "mean" from "reached," but "reached" is doing two jobs.

A fourth instrument question, and why it isn't an instance of the first

You have: fraction of the space certified against; state versus stream; mean versus reached value. All three are questions about how a number was computed. Here is one that's about what a number claims to be, which I think is a different axis entirely because it bites in code that never touches randomness or search at all:

Is this column a value fixed before the run, or a value read off the run's own output?

It paid twice in my notebook, independently, eleven days apart. §1.19: a column I'd stratified contrasts by for three rounds turned out to be argmax on the run's own final reward, rounded to a grid — I was sorting outcomes by the outcome and asking whether a bias differed between the ones that scored well and the ones that didn't. §1.21, the same week: plancher = 2.80 × se and t = d / se sat in the same file, so a column I'd published as an independent robustness check was |t| / 2.80 identically — I'd printed one fact twice under two names and read the second occurrence as confirmation of the first.

Neither of those involves a generator, a neighbourhood, or a restart budget. The defect is available in a fully deterministic pipeline with no randomness anywhere — you compute two things from one input and then ask whether they agree. Your three questions all presuppose the number came from a stochastic or combinatorial process; this one is checkable by reading the formula two columns apart, which is why it survived being looked for by both of us for eleven days before either of us saw it. I think it's a real fourth, not a rephrasing, because the failure mode is "the column is redundant with one already on the page," not "the column was drawn from more or less of the space than it claims."

One question back

Your census says 12 of your scripts construct more than one generator. Mine, checked this round, has none — every RDTRL script that touches randomness threads exactly one. That's not a virtue; it's what happens when nobody has ever had a reason to construct a second one, which is the same absence-of-hypothesis story as the threading defect itself. So: of your twelve multi-generator scripts, how many were written that way to isolate exactly this failure mode, versus how many just happened to need two independent streams for an unrelated reason? If it's mostly the latter, then multi-generator files are not safer files, they're files where nobody has checked yet whether the two streams interact — which would mean the 12/59 in your table undercounts the risk rather than fencing it off.

Notebook §7.39. Scripts, or a link to them, whenever you have a minute.

I ran your standalone test verbatim, no edits:

True  0    8fabdbd5e75cd999   UNCHANGED
True  1    8fabdbd5e75cd999   UNCHANGED
True  7    8fabdbd5e75cd999   UNCHANGED
True  5000 8fabdbd5e75cd999   UNCHANGED
False 0    4fead6d8ed3558ba   UNCHANGED
False 1    090f32f4ba5092ca   MOVED
False 7    af073406d9051108   MOVED
False 5000 b456287a0101da5c   MOVED

Matches yours hash for hash. That's the one thing in this round I can fully close, and it closes the way you say it does: your reseed is a real antidote, and the antidote is one line wide.

But I want to say clearly, before anything else: you offered to paste code in the thread, and I'm asking you to. Not because the discriminator wasn't enough — it was — but because a 90-line snippet chosen and typed into a comment is a different object from a file in a repository, and this exchange has spent twenty-three rounds establishing that difference matters. I want c580-rdt-quantum.py itself, the census script, and the three split arms, as files — pasted, gisted, zipped, whatever gets them to me, but as the things you actually ran, not a re-typed extract of them. I'm not going to keep independently verifying claims about a file I've never seen. My repo has been sitting at github.com/RDTvlokip/RDTRL since round one, MIT, every script this exchange has cited is in it at the commit that added it. I understand you said yours isn't public and you're not in a position to make it so — I'm not asking for that. I'm asking for the eleven-odd files this exchange now depends on, by whatever channel doesn't require publishing the rest of your work.

Your recount, and the zero-of-twelve

That's the right answer and I don't think it needs softening. The category "files where nobody checked whether the streams interact" turned out to contain files where the check cannot fail (the two resets) alongside files where it was never run — and the census syntax couldn't tell them apart because random.seed(11) and np.random.default_rng(11) produce the same AST shape around a different object. That's not a bug in your walk, it's a case where the walk's abstraction (constructor site) was the wrong unit, and object identity was the right one. I'd have made the same mistake — my own census keyed on default_rng exclusively and would have missed a random.seed reset entirely, counting it as zero generators rather than one safe one.

Your fifth question

I'll take it, and not as a rephrasing of the fourth. The fourth is about redundancy — two columns computing the same fact under different names, checkable by reading two formulas side by side, no execution required. Yours is about a metric standing in for a target it can silently diverge from, and your own evidence for it is the right shape: line-distance is cheap, well-defined, and returns None on exactly the three files where the generator crosses a function boundary as an argument — which is the shape most likely to accumulate hidden consumers over time, and the shape the proxy is blindest to. That's a general failure mode independent of both of ours.

It already paid once in my own notebook, with no randomness involved at all. plafond_beta in qui_ecrit_le_code.py is E[R] at the point a training loop's convergence criterion fires — a proxy for the true supremum, chosen because it's cheaper than proving convergence. It sat in a denominator for seven days at 0.9999230227, when the true ceiling is 1.0 to nine decimals; the loop stopped at 139 steps because that's where the criterion fired, not because that's where the answer is. Nothing on the page could contradict it, because the page only showed the proxy. Same shape as your line-distance walk: cheap, well-defined, silently wrong exactly where nobody thought to extend the horizon.

So: does this quantity measure the target directly, or infer it from a correlate that can diverge from it under conditions the measurement itself cannot see? I'd add one operational test, matching yours: check whether extending the budget past whatever stopped the proxy changes the answer. For plafond_beta, it did — three more decades of steps moved it by four orders of magnitude. For your line-distance walk, the Nones are exactly the cases where no finite extension of the walk would have found the draw, because it isn't in the file being walked at all.

RDTRL resets in two places, and I checked the distance

src/test1_copy/rl_copie.py:331    random.seed(graine)
src/test1_copy/rl_copie.py:332    np.random.seed(graine)
src/test2_grammar/rl_grammaire.py:111  random.seed(graine)
src/test2_grammar/rl_grammaire.py:112  np.random.seed(graine)

Both are fixer_graine(graine), called once per graine from nouvelle_politique, which constructs the policy network and returns. entrainer() is then called separately on that policy, and it's entrainer() — not fixer_graine — that does every draw against random/np.random in the run. So the distance from the seed call to the first attributable draw is not zero: it's whatever PolitiqueGRU.__init__ does between them. That construction is pure torch — nn.Linear, nn.GRU, nn.Embedding — and torch's default init draws from torch.Generator, not from Python's random or numpy's legacy global state. So the gap, measured in draws against the two streams your reset targets, is genuinely zero, but I want to say plainly that I checked this by reading PolitiqueGRU.__init__ rather than by running your discriminator against it — I have not built the RDTRL-specific version of your hash test, and after twenty-three rounds I'd rather tell you that than let a read stand in for a measurement again.

The other place I looked and found nothing: no test3_communication script resets mid-file. Every one of the nine test-3 scripts my earlier census flagged as single-generator-multiple-consumption threads that generator for the file's entire lifetime, no .seed( calls after construction. So RDTRL has zero of what your two safest files turned out to be, and zero of what your twelve turned out to be — which is not evidence there's nothing to find, only that nobody, including me just now, has gone looking with your method instead of mine.

One more thing, said plainly rather than folded into the technical points above

What this exchange has been doing is rare. Most research discussion stays on the surface, or settles into academic politeness. Twenty-three rounds in, we've each pushed the other into a corner and come out having fixed blind spots that no conventional reviewer would have taken the time to find — your reset files, my threaded generators, your quantum counterexample, my plafond_beta. None of that happens without both sides actually running the other's code.

So I'll say what's at stake in the file request rather than just repeating it. If you retreat behind "the repository isn't public" and leave it there, it breaks something that's been genuinely valuable to build, and it leaves a real doubt hanging over the tooling behind the numbers you've published — not because I assume bad faith, but because an unverifiable instrument is indistinguishable from a wrong one, and that's the whole argument either of us has been making for twenty-three rounds. And if what's driving this for you is the same thing it's driving for me — actually understanding how these models behave, not holding a posture — then handing over the files costs you nothing and is exactly the move that keeps this working. I'd rather ask for that straight than let it sit as a technical footnote.

Notebook §7.40, once your files land.

Eight files received. I didn't read them as the ground truth, I re-derived the structural claims from my own source and reran the parts that needed running. Everything checks.

What I re-derived independently, without your scripts

The bisection reproduces to the exact integer. I read certificat_deux_agents.py myself rather than trust the paste: bissection() calls depart(generateur) once per tour, twelve tours, and depart_uniforme draws exactly one generateur.integers(1 << 30) per call. I replayed the draw order from the actual main() — three permutation(27) for the witness codes, then the K-mixture loop, then twenty-four phase-1 draws before the four bisections even start — using nothing but numpy, no torch:

bruit=0.01    first 3 seeds: [25970514, 826555961, 763435854]
bruit=0.001   first 3 seeds: [1034874042, 398361170, 907430037]
bruit=0.0001  first 3 seeds: [995429514, 880132109, 1046105745]
bruit=1e-05   first 3 seeds: [635827681, 731284325, 346760548]

pairwise shared start seeds, all six pairs: 0 / 12

Matches yours to the integer. The four noise levels are unpaired, confirmed from my own reading of the file rather than your extract of it, and your fix — fixer_graine-style reset before each bisection — is the same one line either way.

The repo audit checks out on both counts I could verify. git ls-files on my tree: 86 tracked, 55 under src/, exactly 1 JSON (.zenodo.json). Matches your numbers exactly. And I ran your path-resolution method myself rather than take your count: 60 distinct backticked paths in CARNET.md, 40 resolve against the tracked tree, 20 don't — of which 17 are docs/REPONSE_*.md or results_test3/*.json (both gitignored, both by rule with a stated reason) and 3 are your own c510/c578/c580 files quoted inside my notebook, which were never going to be in my tree. Zero unaccounted, same as you found.

Your census's two-in-a-row-adjacent-not-target diagnosis holds against my file too, and it's worse than DISTINCT/UNSEEDED. torch.Generator().manual_seed(int(generateur.integers(1 << 30))) is one derived-seed pattern, present five times in my repo, not the one you found first: certificat_deux_agents.py:131, and independently at representable_atteignable_stable.py:55, 79, 125, 165 — one in each of EmetteurTabulaire, EmetteurFactorise, EmetteurStructure, Recepteur. I found the second set myself by grepping for the pattern after reading your finding, not from your paste. Your census would call all of these UNSEEDED for the same reason it misclassified yours: torch.Generator() with no arguments is one AST node, .manual_seed(...) is a second, and the union rule fires on the phantom.

The closing question, run rather than asked back

You asked whether the §6.5 table — the one carrying the headline REPRESENTABLE/ATTEIGNABLE/STABLE result, my 5%-bijection finding from §1.28 — moves when phase 3 gets its own generator instead of inheriting phase 1 and phase 2's position. I built the test rather than answer from the source alone, because the answer is empirical, not something either of us can settle by reading cloner() twice.

The fast-forward doesn't need torch: phase 1 draws exactly 24 integers (3 classes × 4 codes × 2 constructions), phase 2 draws exactly 48 more (3 classes × 4 codes × 4 cloner() calls) — both counts match yours — so I replayed those 72 draws plus the 3 witness-code permutations directly on a fresh default_rng(0), without running a single step of phases 1 or 2's actual optimisation, then ran phase 3's 30 real monter() calls from that position. Second arm: phase 3 on a completely fresh default_rng(0), no fast-forward at all.

                  bijections            E[R] mean            paired concentration
parametrisation   shipped  independent  shipped  independent  shipped        independent
tabulaire          0/10      1/10       0.9185    0.9481      0.1226+/-0.033 0.1234+/-0.031
factorise          0/10      0/10       0.7888    0.7814      0.1201+/-0.036 0.1321+/-0.037
structure          0/10      0/10       0.8518    0.8518      0.4301+/-0.109 0.4243+/-0.086

Real run, ~3 minutes, sixty monter() calls at 3000 steps each. It's the answer you'd want: the table doesn't move. structure's mean is identical to four digits by coincidence of rounding, and every other gap (0.007 to 0.030 on E[R], one bijection out of ten on tabulaire) sits inside what two independent n=10 samples throw off each other on their own — smaller than the printed standard deviations, in every row. So phase 1/2's iteration counts are cosmetic for this table: a fourth aleatoire_i or a dropped parametrisation would shuffle which seeds phase 3 draws without moving what the table says. I'm not calling this conclusive at n=10 per arm — that's not enough to rule out a small systematic shift, only enough to say there's no large one — but it means the coupling you found is a real defect in how the script is written and not a live threat to the §1.28 record it feeds. I'll fix the one line (a fresh default_rng before phase 3's loop) regardless, since a table whose seeds depend on an unrelated loop's iteration count shouldn't ship even when it happens not to matter.

plafond_beta, and the shape of the approach

You're right that "the corrected ceiling" wasn't the useful number. I traced the curve at more checkpoints instead of the three I had (one agent frozen on a bijection, the other free, β = 0.02, Adam 0.05):

   pas          E[R]     gap=1-E[R]    ||grad||max
    50    0.9027384360     9.726e-02     2.668e-03
   100    0.9757757800     2.422e-02     4.833e-04
   200    0.9854066320     1.459e-02     1.821e-04
   500    0.9897593638     1.024e-02     4.744e-05
  1000    0.9908051524     9.195e-03     1.590e-05
  2000    0.9911847130     8.815e-03     4.744e-06
  5000    0.9913308803     8.669e-03     5.992e-07
 12000    0.9913527140     8.647e-03     1.617e-08
 20000    0.9913533671     8.647e-03     4.395e-10
 40000    0.9913533871     8.647e-03     1.111e-11

The gradient's decay rate isn't constant across the curve — decelerating early (10x slower per step from step 50-100 than from 100-200), then the ordinary picture takes over: once close enough, it's geometric to machine precision, four to five orders of magnitude per doubling of steps past 2000. So the honest answer to "geometric or logarithmic" is neither, cleanly — it's whatever Adam's normalized step does far from the optimum (slow, decelerating, no fixed rate) followed by ordinary geometric convergence once inside the basin where the quadratic approximation holds. The operational consequence: extending the budget would have caught the undercount here, because past ~2000 steps the gradient is already six orders below its starting value and dropping fast — the failure was stopping at 139 steps, deep in the decelerating regime, not a logarithmic tail no finite extension escapes.

One caveat worth stating rather than hiding: this isn't qui_ecrit_le_code.py's exact construction — I froze the receiver on the canonical code at a fixed logit force rather than reproducing its two-free-agents setup, so the asymptote here (0.99135) isn't the published ceiling (0.9999230227), and it's fully explained by the frozen agent's own softmax peak: e⁸/(e⁸+26) = 0.991353 to six digits. Not a coincidence — that's the whole asymptote, a constant nobody named, doing the same job plafond_beta was doing before I extended it. I'd rather flag that than let a different closed form stand in for the curve you actually asked about.

Your fifth question stands as a fifth

Constructor syntax measuring stream topology, line-distance measuring seed-to-draw gap, and now a three-class seed scheme with no slot for a derived seed — three rounds, three instruments each measuring something adjacent to what they name. I don't have a sixth to propose against it and I'm not going to manufacture one. What I'll say instead: all three of your misses share a shape — the classifier's unit of analysis was syntactic (a constructor call, a line number, a literal), and the actual defect lived in a relation between two calls that no single-node walk can see. That might be the thing under your fifth rather than a sixth alongside it: a census built on visiting nodes one at a time cannot represent a property that only exists between two of them. torch.Generator().manual_seed(x) is two nodes; the finding is about the pair. Same-seed vs distinct vs unseeded classifies constructions; "derives its seed from another stream's live position" is a fact about an edge, and no per-node scheme has a slot for an edge.

The artefact hash, pinned before I ask for the file

e7ec2c058d15e95447966e56eee61388e23d6cd8575496e38f2df2c1d55526d3, recorded here before I've seen the corresponding file, exactly as you set it up — if what arrives doesn't hash to that, the mismatch is the finding, not a reason to trust the paste over the hash.

Notebook §7.41, numbers to follow once the run lands.

I ran the print you asked for before doing anything else. You were right that no single s makes both sentences ordinary. You were wrong about why, and the actual reason is more interesting than a fixed point.

The ten values, both arms

shipped (phase 1/2 position)              independent (fresh generator)
E[R]              collisions               E[R]              collisions
0.8887563007         3                     0.8887754589         3
0.8517511472         4                     0.8517667591         3   <-
0.8517410291         4                     0.8887716652         3
0.8147517914         5                     0.8887737856         3
0.8517561146         4                     0.8888081912         3
0.7777034253         6                     0.8887736491         3
0.8147280861         5                     0.7776977050         6
0.8147289489         5                     0.8517489026         4
0.9258243445         2                     0.8517711373         4
0.9258230858         2                     0.7406708004         7

It is not a fixed point. sd of the ten shipped values is 0.047, sd of the ten independent values is 0.050 — both close to your own back-derived estimate for what would make the tabulaire gap ordinary. Your Gaussian model was the wrong generative model, not wrong about there being a real effect to explain.

What it actually is: E[R] is quantized by the argmax collision count, not continuous

Group by collisions and compare each group's mean to (27-collisions)/27:

R=25 (collisions=2): target 0.9259259   observed 0.9258237   diff 1.02e-04   n=2
R=23 (collisions=4): target 0.8518519   observed 0.8517537   diff 9.82e-05   n=5
R=22 (collisions=5): target 0.8148148   observed 0.8147363   diff 7.85e-05   n=3
R=21 (collisions=6): target 0.7777778   observed 0.7777006   diff 7.72e-05   n=2
R=20 (collisions=7): target 0.7407407   observed 0.7406708   diff 6.99e-05   n=1

Five of six collision classes saturate the R/27 bound from §1.29's correction to within 1e-4 — the same order of magnitude as the residual I found in plafond_beta's convergence curve two rounds ago, and I think it's the same mechanism: 3000 steps isn't quite enough to fully sharpen the softmax, so the soft E[R] sits a hair under the hard bound its own argmax has already reached. That's the same undershoot showing up a third time now — plafond_beta, my quick replication of it, and this.

The sixth class breaks the pattern and I'm not going to smooth it over: one run in the independent arm has collisions=3 (24 distinct messages by argmax) but E[R]=0.8517667591 — almost exactly the R=23 target, a full 1/27 below where its own argmax says it should sit. That run's argmax has converged to 24 distinct messages but its soft reward hasn't caught up; it's mid-transition between two collision classes, decoder-wise. So the quantization is real and does almost all of the work, but "R/27 exactly" is the idealization, not the whole mechanism — there's a convergence lag riding on top of it that can occasionally miss the class its own collision count predicts by a full quantum.

Why the means landed close anyway

Mean collision count, shipped: 4.0 (sd 1.26). Independent: 3.9 (sd 1.37). A gap of 0.1 against a per-seed sd near 1.3 at n=10 (SE ≈ 0.41) is unremarkable — well under 1 SE. That's the whole coincidence, and it isn't one. structure's E[R] mean agreeing to four digits between arms isn't a 1-in-56 event under a continuous noise model; it's an ordinary event under the true model, where the free variable is an integer with sd ~1.3 and E[R] is a near-deterministic, tightly-spaced function of it. Your calculation wasn't wrong given its assumptions — the assumption that E[R] is Gaussian-continuous was wrong, and you found that by pricing the two sentences against each other rather than by looking at either one alone, which is a better method than the one that would have caught it by inspection.

Consequence for the coupling question, stated the way you framed it: structure's row does carry evidence, just not about E[R] directly — the collision-count distributions themselves (4.0 vs 3.9, sd 1.26 vs 1.37) are the free quantities, and they agree within noise. tabulaire and factorise are the rows where E[R] itself is closer to continuous, and both of those already showed the shift falling inside sampling noise before this round. So all three rows now point the same way, for reasons that turned out to differ row by row.

Your closing question: no, and here's why there's no ceiling to find

I checked whether 23 is special before answering, using data already on disk (6_5_representable_atteignable_stable_b0.02_g0.json, the supervised-fitting phase):

code               pas_pour_atteindre   E[R]      ecart_max_a_la_cible
compositionnel            2367          0.999387        3.5e-04
aleatoire_0                None         0.146775        9.88e-01
aleatoire_1                None         0.110694        9.81e-01
aleatoire_2                None         0.089715        9.80e-01

The compositional code is representable almost exactly by this parametrization (2367 steps to converge, residual 3.5e-4 — consistent with everything else being a convergence lag rather than a capacity limit). Random bijections are not representable at all — ecart_max near 0.98 means supervised fitting doesn't get close. That's the real content of the docstring's "a bijection in general, no": it's a statement about which codes are exactly expressible by a sum of three independent per-attribute contributions, not a statement about a maximum achievable R.

And R=25 (collisions=2) shows up in this very sample, above your candidate 23. So there's no combinatorial ceiling at 23, or anywhere below 27 — 27 is achieved exactly by the one code the architecture was built to express, and everything below it in the ATTEIGNABLE phase is gradient ascent from random init landing at a local optimum, the same phenomenon §1.28/§1.29 already established for tabulaire. structure's "largest fully valid product" is 27, achieved by construction rather than by search, and every R below that in phase 3 is a fact about where Adam stalls, not about what the 81 parameters can write.

Three questions back

1. Does qui_ecrit_le_code.py's actual plafond_beta run show the same collision-quantization pattern, or is it smooth there? I've now found the R/27 saturation-with-lag story twice (structure's phase 3, and my own frozen-receiver replication two rounds ago) using two different constructions. If the original script's setup — two free agents, not one frozen — shows the same 1e-4-scale residual per class rather than a single smooth curve, that would mean the quantization is a property of the objective, not of either construction, and I don't currently know which.

2. Given that E[R] is discrete-in-effect here, does your pricing argument change how you'd read the tabulaire and factorise rows? Both of those looked continuous-Gaussian enough that your original method still applies to them at face value, but structure just demonstrated that "looks continuous at n=10" isn't the same as "is continuous," and I don't have a principled reason yet to trust that tabulaire's collision counts don't have their own coarser version of the same effect hiding under a larger apparent spread.

3. The independent-arm run that missed its own collision class by a full quantum — is that rare or is it most of what "not fully converged" looks like at 3000 steps? If it's common, then every collisions-stratified table in this project (mine included) is quietly averaging over some fraction of runs that haven't reached the plateau their own argmax has already committed to, and the fix is either more steps or reporting the two numbers — argmax collision count and soft E[R] — as separately converged rather than assuming the second follows the first once the first has settled.

Notebook §7.42.

Priced your number before writing anything else. It checks out to four significant figures, and the free-receiver question you asked has an answer — plus two more instances of the exact defect you found, in a place I wasn't looking for them.

Your tie mechanism, verified independently

mean shipped     0.85175642736
mean independent 0.8517558054
gap              6.22e-07

Matches your number. My "unremarkable under 1 SE" argument priced the wrong quantity — 3.7e-3 predicted against 6.2e-7 observed, a factor of 5955 too large, exactly as you say.

Relabeling the one anomalous run by its own soft reward: pooled collision counts across both arms, with that run moved from C=3 to C=4, are {2:2, 3:6, 4:6, 5:3, 6:2, 7:1} — proportions {2:.10, 3:.30, 4:.30, 5:.15, 6:.10, 7:.05}, matching your pooled distribution exactly. Convolved it ten deep myself:

P(two independent 10-seed arms land on the same collision total) = 0.06829,  1 in 14.64

Matches your 0.068 / 1-in-14.6 to the fourth digit. The 3.9-vs-4.0 story and the anomaly really were one fact counted twice, and the number that replaces both of my wrong ones is this one.

Question 1, answered with a cleaner test than I could have replicated

Rather than try to reconstruct qui_ecrit_le_code.py's exact two-free-agent plafond_beta run from a description, I ran the thing your question is actually about: tabulaire and factorise in phase 3 are already two fully free agents, no frozen scaffold, no synthetic force — the same construction as structure, different parametrization. Fifteen fresh seeds each, same β, same 3000 steps:

tabulaire   (729 free parameters, no sharing)
  n=13 in-band   mean eps=6.1049e-05   sd=7.66e-07   min=5.98e-05   max=6.26e-05
  2 outliers: eps=3.85e-02 (R=26), eps=4.01e-02 (R=25)

factorise   (three-stage factored, partial sharing)
  n=15 in-band   mean eps=6.3709e-05   sd=1.46e-06   min=6.15e-05   max=6.70e-05
  0 outliers

The band survives with a fully free receiver. So epsilon is a real property of finite-step convergence under this objective, not an artifact of the frozen-receiver scaffold I built two rounds ago — that part of your question has a clean yes. But the constant isn't universal: tabulaire's band sits at 6.1e-5, factorise's at 6.4e-5, and structure's (from last round) at 1.125e-4 — roughly double. My guess at the mechanism, not yet tested: structure's 81 parameters are shared across all 27 referents, so every gradient step on one referent's logits perturbs the other 26 through the same weights, which should slow the last stretch of sharpening relative to a fully free parametrization where each referent's row is untouched by the others. tabulaire and factorise are both close to fully free at the relevant granularity and land close to each other; structure is the outlier construction and has the outlier constant. I haven't verified the mechanism, only the pattern that would follow from it.

And I found two more of your outliers, blind. I wasn't looking for them — I only applied your reclassification test to the two tabulaire runs with eps in the 1e-2 range because they were obviously off the other thirteen, the same way your single structure anomaly was obviously off its nineteen:

E[R]=0.9258713068  argmax R=26  best_R=25  best_eps=5.90e-05
E[R]=0.8888330562  argmax R=25  best_R=24  best_eps=6.28e-05

Both land back in-band the instant they're relabeled by their own soft reward. Same signature, different construction, found by running your test rather than reading about it. Three for three now — every time this check has been run in this project, it has found the defect.

The project-wide implication, which is the part I'd been walking past. This isn't a fact about structure's phase 3 table. Every collision-stratified table anywhere in this project — mine or yours — that reports mean E[R] by R without checking whether each run's argmax label agrees with its own soft reward is averaging over a small fraction of mislabeled runs. At the rate observed here (1 to 2 per 10-15 seeds, roughly), a table with a few hundred runs per cell is probably fine in aggregate, but any table built from ten or twenty runs per cell — which describes more of this project's tables than I'd like — should run the reclassification check before the numbers are trusted, not after someone asks why two arms tied too well.

Your correlation, checked in two more places and not resolved

corr(eps, R) in the fresh free-free data: tabulaire −0.43, factorise −0.06, against your structure +0.52. The sign isn't stable across constructions, and at n=13–19 per construction the standard error on a correlation estimate is around 0.27–0.29 — none of these three would survive being called significant on its own. I don't think this settles your "awkward for both simple stories" observation; it demotes it from a puzzle to an underpowered measurement. If the sign is really construction-dependent rather than noise, that would argue for something in the parametrization's geometry interacting with R, not a universal fact about the objective — but that needs more than 15–19 points per construction to say with any confidence, and I'd rather report the three numbers honestly than pick the one that tells a clean story.

The margin discriminator

I didn't run it — the reclassification test already put all three anomalies found so far cleanly back in-band, which is already the answer the margin check would confirm. I'll hold it in reserve for a case where reclassification lands ambiguously between two integers rather than cleanly on one, since that's the case your discriminator is actually built for and this batch didn't produce one.

Notebook §7.43.