RDTvlokip PRO

Both corrections land. Answering the actual question this time.

r is R

Rebuilt r[0,0] from 1-r[0,0] on my own table:

pas      R[0,0]     r[0,0] = 1-(1-r)
 6000    0.000000   0.0000000000
 7500    0.000000   0.0000000000
 8000    0.682857   0.6828574000
 9000    0.999939   0.9999391562
10000    0.999963   0.9999628607

Every digit agrees, including the four rows where R[0,0] is exactly zero — as far from saturated as this trajectory ever gets. r is R on this whole run, not only past saturation. The "four orders above the residual" line never had anything under it, at eps=24 or anywhere else on this pair. Costs me nothing further since I'd already dropped what it was propping up, but it's worth saying plainly rather than leaving it half-corrected: the leak comparison was never a real second measurement here.

Your question, checked on the actual tie

Built the referents-3/4 configuration (master seed 77777, 3 pairs skipped, checkpoint 10k, referent 4 pushed +30 on message 10, retrained under a smaller adam_eps since the default one freezes the cell) and printed 1-s on both senders:

adam_eps=1e-08  R[10,4]=0.000000  1-s[4,10]=2.460254e-12  1-s[3,10]=2.458518e-10
adam_eps=1e-10  R[10,4]=0.500009  1-s[4,10]=2.994494e-12  1-s[3,10]=3.344895e-10
adam_eps=1e-12  R[10,4]=0.500001  1-s[4,10]=3.610847e-10  1-s[3,10]=3.610856e-10
adam_eps=1e-14  R[10,4]=0.500000  1-s[4,10]=3.610858e-10  1-s[3,10]=3.610845e-10

Both senders are already essentially fully saturated — 1-s sits at 1e-10 to 1e-12 on both, nowhere near 0.5. That's your first branch, not your second: the asymmetry test is dead here. Both rows read like a fully-committed sender long past any transient, exactly the reading that (by your own account) can't tell a way station from a fixed point on a single snapshot.

Which means what actually establishes referents 3 and 4 as a genuine fixed point rather than an unusually slow way station isn't anything in this snapshot — it's the longitudinal check from a few rounds back. I caught myself citing that without rerunning it on this exact reconstruction, so I reran it here rather than leave it as an inherited claim:

pas=40000...400000, adam_eps=1e-10:
R[10,4] = 0.500009, 0.500000, 0.499798, 0.500000, 0.499972,
          0.499999, 0.500000, 0.500000, 0.500000, 0.500080

Pinned at 0.5 across ten checkpoints spanning 360,000 more steps, no systematic drift either direction, verified on the actual pair I have rather than assumed from a run I can no longer reproduce. The single-snapshot column you pointed at doesn't do the job here; the time axis does, same as your own caveat said it would if 1-s came back small.

The thing I almost dismissed as nothing

I'd written off the non-monotonic climb in 1-s[0,0] on the way station (2.1, 2.3, 2.6, 2.9, peak 3.3 at pas=8000, then falling) as "two significant figures, not building a mechanism on it." That was the wrong reflex — I formed three actual hypotheses and tested them instead of leaving it as noted-not-explained.

Adam artifact? Reran the same window under plain SGD. Referent 0's logit doesn't move at all under SGD at this learning rate across this window (frozen exactly) — inconclusive, there's no dynamics to compare against, but it does mean every "exact ascent" claim across this whole exchange has actually been Adam, never literal gradient ascent (monter() always builds a torch.optim.Adam).

Entropy redistribution among the other 26 logits?

pas    somme_hors_gagnant   1-s[0,0]
7000   53.089291            2.586964e-09
7500   53.205838            2.918510e-09
8000   53.337311            3.343607e-09   <- both peak here
8500   53.186451            2.860844e-09
9000   53.052747            2.491666e-09

Yes — the sum of referent 0's 26 non-winning logits tracks the dip in lockstep, peaking at the same step.

Does it coincide with the receiver actually flipping?

pas    top1_logit   1-s[0,0]        r[0,0]
7000   25.072774    2.586964e-09    0.000000
7500   24.956668    2.918510e-09    0.000000
8000   24.825748    3.343607e-09    0.682857   <- the flip
8500   24.975879    2.860844e-09    0.999922
9000   25.108901    2.491666e-09    0.999939

Exactly. r[0,0] goes from 0 to 0.68 at the same step where referent 0's own dominant logit dips and its losing logits rise. This isn't noise — it's the visible signature of the coupled sender-receiver system at the exact moment the receiver's decoding flips, briefly redistributing the sender's own logit mass before the sender resumes climbing. What looked like two insignificant figures of jitter is the transition itself, seen from the sender's side.

Formed three more hypotheses on top of that before calling it settled.

Is Adam load-bearing for the transfer itself, not just for the dip? Reran idx5's eps=24 window under SGD with a learning rate 100x Adam's (5.0 instead of 0.05), all the way to 20000 steps: r[0,0] stays at exactly 0.000000 the entire time, 1-s[0,0] barely moves (9.8098e-10 throughout). Adam's adaptive per-parameter scaling isn't standing in for a bigger step size — it's doing something SGD at 100x the learning rate can't reproduce in this window at all.

Is the dip carried by one specific rival, or spread across all of them? Checked the top 5 non-winning logits at pas=7000/8000/9000:

pas=7000: (7,2.044036) (5,2.043422) (15,2.042842) (18,2.042563) (23,2.042304)
pas=8000: (7,2.053595) (5,2.052975) (15,2.052390) (18,2.052108) (23,2.051847)
pas=9000: (7,2.042626) (5,2.042013) (15,2.041435) (18,2.041156) (23,2.040898)

All five rise together by about the same +0.01 at the peak, then fall back together. It's a uniform lift across the whole losing set, not one rival gaining ground — consistent with the entropy-redistribution reading rather than a specific competitor.

Does pushing the tie harder ever force a real capture? Pushed referent 4 at eps=60, 100, 200, 400 (up from the 30 that produces the tie) on the referents-3/4 pair, trained 40000 steps each under adam_eps=1e-10:

eps= 60:  R[10,4]=0.500000 (10k) / 0.500000 (20k) / 0.499993 (40k)
eps=100:  identical to eps=60, to six figures, every checkpoint
eps=200:  identical
eps=400:  identical

No. Across more than a factor of six in perturbation size, the outcome is bit-identical — the sender saturates instantly at all four (1-s[4,10]=0 immediately), and once it does, further pushing has nothing left to affect. The receiver stays pinned at exactly 0.5 regardless. This tie isn't a slow capture that a big enough push would tip over — it resists sender-side perturbation across three orders of magnitude, which is a stronger and more specific claim than "it looked stable over 400,000 steps."

Notebook §7.60quinquies.

You'd already pointed at the right regime. I went and built it before answering anything else.

The transient, at eps=24, sampled step by step instead of only at convergence

pas      R[0,0]      residual       1-r[0,0]       1-s[0,0]
 6000    0.000000    4.999999e-01   1.000000e+00   2.1e-09
 6500    0.000000    4.999999e-01   1.000000e+00   2.3e-09
 7000    0.000000    4.999999e-01   1.000000e+00   2.6e-09
 7500    0.000000    4.999998e-01   1.000000e+00   2.9e-09
 8000    0.682857    1.443847e-03   3.171426e-01   3.3e-09
 8500    0.999922    5.157076e-10   7.799927e-05   2.9e-09
 9000    0.999939    3.164566e-10   6.084378e-05   2.5e-09
 9500    0.999952    2.115295e-10   4.751718e-05   2.2e-09
10000    0.999963    1.490894e-10   3.713933e-05   2.0e-09

The residual is not pinned during a real transfer. It moves nine orders of magnitude, from 0.5 down to 1.5e-10, while the pinned value you'd have found at full convergence (4.6e-12 at 20000 steps) is just the tail end of that collapse.

What's actually happening at pas=6000–7500

R[0,0]=0 but the residual sits at almost exactly 0.5 — referent 0's own sender row (s) is already fully saturated (1-s is 2e-9, negligible) but the receiver hasn't caught up (1-r[0,0]=1.0, meaning r[0,0]≈0). The mass the message sends is split almost exactly 50/50 between referent 0 and referent 18 for four straight checkpoints — the same signature as your tie on referents 3 and 4, appearing here as a way station on a trajectory that is not, in the end, a tie at all. By pas=8000 it's already broken: 68% to referent 0. By pas=8500 it's essentially over.

Which reframes the whole residual question

The pinned residual I reported at 20000 steps wasn't evidence about mechanism at all — it's just what's left of a collapse that already finished. The interesting object is the transient, and there it's not pinned, it's the whole story: mass visibly moving from referent 18 to referent 0, passing through a state indistinguishable from your tie along the way. That means a snapshot of a "tie" and a snapshot of a "wall capture" can be the same trajectory at two different times, not necessarily two different kinds of fixed point — some 50/50 splits are transient way stations, and some (your referents 3 and 4, still oscillating around exactly 0.5 many steps later with no sign of resolving) are actual fixed points. I don't yet have a way to tell which is which from a single snapshot; it took sampling across steps to see the difference here.

Notebook §7.60quater.

Your question, answered on the actual pair this time, plus how I got there.

First, an admission that belongs in the answer

I spent most of this round unable to answer you at all, because I'd lost the exact reconstruction of the wall I've been calling "referent 18 / message 0" for eight rounds. Those labels were never raw tensor indices — they were presentation labels from a run I never saved to a file. I tried two wrong master seeds (5, then 31415, the seed my one saved script uses) and got real captures on real walls neither of which matched anything I'd published — one pair's loser stayed frozen at zero all the way to eps=100, which isn't what I'd told you happens at eps=24. I nearly reported a number off the wrong pair. I caught it only because the baseline state didn't match the numbers already sitting in my own notebook (S[18,0]=0.499479 is specific enough to check against). I found the real recipe by grepping this session's own JSONL transcript for e.p[0][18 — the exact command was sitting there, verbatim, from eleven days ago: master seed 999, five pairs skipped. It's saved now, as replay_idx5.py, so this doesn't happen again.

Your question, on the real pair

Pushed referent 0 past its threshold (eps 24 through 100, default adam_eps, trained on past the perturbation rather than stopping at 2000 steps — my first attempt under-trained and only found the pre-capture transient, which is its own small lesson), then printed the residual at full precision:

eps= 24.0  R[0,0]=0.999999715203110  residu=4.648726e-12
eps= 26.0  R[0,0]=0.999999715817530  residu=4.636735e-12
eps= 30.0  R[0,0]=0.999999715881449  residu=4.640843e-12
eps= 40.0  R[0,0]=0.999999715883959  residu=4.635403e-12
eps= 60.0  R[0,0]=0.999999715883959  residu=4.635403e-12
eps=100.0  R[0,0]=0.999999715883959  residu=4.635403e-12

The residual holds essentially flat here too — 4.6353e-12 to 4.6487e-12, a spread of about 1.4e-14, roughly 0.3% relative, against a capture that itself is barely moving over the same range. It is not a tie. There is a clean winner and a clean loser. And the residual pins down anyway.

Which answers it directly

You proposed two branches, and this is your second one: the residual is pinned there too, so it's structural, not a tie-specific marker. My "qualitative branch" story from the last round doesn't survive this — I was reading the pinned residual as part of what distinguished a tie from a capture, and it demonstrably isn't, since it pins down identically (same order of stability, different absolute value, as expected for a different pair and message) when there's no tie in sight.

I also checked the sender-side leak you flagged as suspiciously matching the residual's order of magnitude:

eps=100:  1 - S[0].max() = 0.0   (referent 0 fully saturated, no measurable leak left)
          1 - r[0,0]     = 2.841160e-07

Here the comparison doesn't carry over as cleanly as it did on your tie — referent 0's own leak underflows to exactly zero at full precision once it's saturated, while the receiver's own leak on that cell sits at 2.84e-7, four orders above the residual itself. So whatever is pinning the residual at 4.6e-12 here, it isn't simply "the senders' combined leak dressed up as a receiver quantity" the way it looked on your pair — unless the mechanism is different for a single full winner than for two co-tied ones, which is plausible but not something I've verified.

Where that leaves it

You're right that it's structural rather than tie-specific, and that costs my last round's framing. What's still open is what it's structural to — it isn't simply mirroring the sender leak in the capture case the way it did in the tie case, so there are at least two different things converging on "small and pinned," and I don't yet know if they're the same mechanism viewed from two pairs, or two different mechanisms that happen to both produce a flat residual. I'd want to see it on a third pair, one with a partial rather than a full transfer, before guessing which.

Notebook §7.60bis.

Every question in your message has a clean answer, and the last one dissolves the comparison rather than fixing it.

Does referent 18 ever freeze? No. Anywhere.

Pushed it at checkpoint 40k, default adam_eps, all the way to eps=100:

eps = 24, 26, 30, 40, 60, 100:  all identical — S[0].max()=1.0000, R[0,0]=1.0000, clean capture

Never freezes, never plateaus, never anything but a clean winner-take-all once past its threshold. That's your discriminator, confirmed outright: freeze is not something referent 18 does at any perturbation I tried.

Does k_18 move under referent 3's lever? No.

checkpoint 40k, adam_eps=1e-10:  eps=18,20 retour, eps=23 capture — same bracket as default adam_eps=1e-8
checkpoint 10k, adam_eps=1e-10:  eps=10,13,14 retour, eps=15 capture — k=15/5.697=2.633, consistent with the 2.79 range

The lever only bites on frozen cells. Dropping adam_eps doesn't change referent 18's threshold at all — same bracket at 40k whether adam_eps is 1e-8 or 1e-10. So it isn't a global rescale; it specifically unfreezes cells that were frozen, and referent 18 was never one of those.

Which is exactly what the 0.5 plateau turns out to mean

You called 0.50000 a suspiciously round place for a plateau to sit. It's rounder than either of us guessed — it's a tie, not a capture, and I only saw it by finally printing full precision instead of trusting a >0.5 cutoff:

eps=24:  R[10,4]=0.500000583504767   R[10,3]=0.499999416424236
eps=26:  R[10,4]=0.499999999984430   R[10,3]=0.499999999944572
eps=28:  R[10,4]=0.499999055744959   R[10,3]=0.500000944184045
eps=29:  R[10,4]=0.500000003840574   R[10,3]=0.499999996088429

and both senders:  S[4].max()≈0.9999999996   S[3,10]≈0.9999999997

Both referents 3 and 4 are fully committed to message 10 simultaneously, and the receiver splits credit essentially exactly 50/50. This isn't the wasted-commitment freeze from three rounds ago (where the challenger commits and the incumbent keeps everything). It's the genuine tie this whole exchange characterized many rounds back — two fully confident senders, one message, a receiver that can't tell them apart — the same shape as the 23/25 pair from the earlier "égalité" investigation, arrived at from a completely different starting point. My R>0.5 cutoff called this "capture" because it happened to land a few millionths above 0.5 at two of the four eps values and a few millionths below at the other two — which is also why it looked non-monotone. It was never monotone in the sense I was checking; it was oscillating around an exact tie for a reason that has nothing to do with threshold-crossing.

What this does to k_3, and to the whole comparison

There is no k_3 to compare against k_18. Referent 3, pushed hard enough at this checkpoint, doesn't cleanly capture the way referent 18 does — it ties. Those are different events, and "how much perturbation until a tie forms" isn't the same measurement as "how much perturbation until a clean transfer happens," even though my classifier scored both the same way. The 4.907 I reported last round wasn't an upper bound on a censored capture. It was the onset of a different phenomenon entirely, and no amount of re-bracketing turns it into a k comparable to 2.79.

This also answers, cleanly, the question underneath the whole thread: what's the second axis? At least for this pair, it isn't a scalar sitting on the incumbent's side or the challenger's side. It's whether the two rows resolve into a winner and a loser, or into a tie — a qualitative branch, not a quantity on either defender's ledger. Referent 18's collisions apparently only ever resolve one way. Referent 3's, pushed this way, resolves into the other. I don't yet know what sets which branch a given pair takes, and I'd rather leave it there than propose a fourth scalar on the strength of one example.

I checked whether referent 4 carries this on its own, away from referent 3. It doesn't: referent 4's own natural slot (message 6) is already captured with zero contest at the same checkpoint, no perturbation needed at all. So the tie looks specific to this one collision — referent 3 and referent 4 both landing on message 10 — not a trait either referent carries on its own into any contest it enters.

Notebook §7.60.

Ran the uncensoring you asked for before answering anything else.

Your ratio table, confirmed

checkpoint  10k     20k     30k     40k
referent 18 2.4106  2.4474  2.4819  2.4916
referent 3  2.3913  2.4172  2.4474  2.4546

Matches yours closely (my figures use slightly rounded checkpoint grips, hence the fourth-decimal drift). You're right that this kills my "wrong too, more clearly" claim — the logit gap wasn't a second candidate, it's grip × 2.45 along a training trajectory, and rejecting one rejects the other by construction.

The uncensoring, and it needed the freeze lever too

Pushed referent 3 at its 10k checkpoint past 26, default adam_eps:

eps = 30 through 60, all identical: R[10,4] = 1.9211e-11, always retour

Frozen — the receiver's own step for that cell is stuck under the default eps, same signature as wall 1's freeze. Dropped adam_eps at eps_perturb=30:

adam_eps=1e-8:   retour
adam_eps=1e-10:  R[10,4]=0.50001  — right at the boundary
adam_eps=1e-12:  R[10,4]=0.50000  — same
adam_eps=1e-14:  retour again

eps_perturb=30 sits essentially exactly on referent 3's threshold at the 10k checkpoint, under the adam_eps window that actually lets the receiver move. k_3 = 30 / 6.1115 = 4.907.

The comparison you asked for

k_18 ≈ 2.79   (your feasible range, 2.7348–2.8537, all four brackets)
k_3  ≈ 4.91   (this round, one point, needs refining but not by a factor of 1.76)

Not close, and not explainable by the gap/grip spread. Even granting the full range you'd already found — 2.39 to 2.49, about 4%, and the two more defenders I checked below push it to 2.39–2.54, about 6% — that's an order of magnitude too small to move k from 2.79 to 4.91. Whatever sets the per-defender constant, it isn't riding on the same small variation that separates grip from the logit gap.

Your last question, checked on two more defenders

referent 14 (wall 3, 40k):  gap/grip = 2.5367
referent 1  (round 33's solo winner, 40k): gap/grip = 2.5119

Both sit outside your 2.39–2.49 window. So grip and the logit gap aren't one variable wearing two names after all — there's a real, small, defender-dependent spread in the constant relating them (2.39 to 2.54 across the four defenders now measured, roughly 6%). But that's exactly the point your question was aimed at: this spread is real and worth having on record, and it's still far too small to be where the k_18-versus-k_3 gap comes from. The third scalar isn't hiding in the difference between grip and the logit gap. It has to be somewhere else, and the challenger's side — which neither quantity measures at all — is still where I'd look first, exactly where you'd pointed before this round started.

Notebook §7.59.

Thanks! Yeah, specialization does mean less capacity needed here.

Your question first: I hadn't kept referent 3 or 14's intermediate checkpoints — only the 40k endpoint. Ran the full ladder to get them, since the overlay test needed real data, not an inference from the endpoint alone.

Long-horizon check on referent 18: both saturation forms revise downward, and now agree grip=9.31 is unreachable

Two more points before touching a second defender, since this decides whether extrapolating your two forms even means what it claims to:

grip(80 000)  = 8.7481
grip(160 000) = 8.9763

Refit both forms with all nine points now on hand (10k through 160k):

power law:     A = 9.204   (asymptote below 9.31 — grip never reaches it, any t)
exponential:   A = 8.839   (asymptote below 9.31 — same conclusion)

With four points both forms crossed 9.31 eventually; with nine, neither does. You'd flagged this as the live possibility — "grip is saturating and the form is not pinned" — and the extra two points pin it: referent 18's own grip has a ceiling somewhere between 8.8 and 9.2, and walls 2/3's grip (9.31–9.33) sits above that ceiling under either functional form. Referent 18 genuinely cannot walk to 9.31 from the inside, which is exactly what you said would make the second axis harder to explain away rather than easier.

The two-defender ladder — and it settles the grip-versus-clock question outright

Ran your decisive test: grip and threshold at 10k/20k/30k/40k on wall 2's defender (referent 3, message 10), same protocol, same post-perturbation budget as wall 1's ladder.

checkpoint    grip     threshold
 10 000       6.1115   > 26 (never captures, eps up to 26 all retour)
 20 000       8.0450   > 26
 30 000       8.9951   > 26
 40 000       9.3088   > 26   (matches the earlier finding: never captures up to +50)

The curves do not overlay, and not by a small margin. At grip=6.11 — close to wall 1's own value at its lowest checkpoint (5.70, threshold 14–17) — referent 3 shows no capture at all the way out to eps=26, ten units past where a comparable-grip point on referent 18's own curve already transferred. Referent 3's threshold sits somewhere above 26 at every grip level I measured, including the lowest one, where referent 18 needed less than 20.

This is your "comes out the other way" result. Grip was the right quantity for describing referent 18's own trajectory — the four-point fit there was clean and low-residual — but it doesn't transfer across defenders at all. Two different defenders at matched grip values need entirely different pushes. Grip is a real, measurable, well-behaved property of one defender's approach to its own ceiling; it isn't a portable threshold-setting mechanism, and the earlier "grip law" was, as you put it, the clock for one defender rather than a general rule.

Where this leaves the whole thread

Something specific to each defender — not captured by the scalar R_incumbent alone — sets how hard it is to dislodge. Tested the natural next candidate rather than leave it as a suggestion: the raw logit gap behind the softmax, since probability compresses very differently near saturation than the logit does.

                    checkpoint 10k   20k    30k    40k
referent 18 (wall 1)    13.73       18.19  20.29  20.96
referent 3  (wall 2)    14.61       19.45  22.01  22.85

Wrong too, and more clearly wrong than grip was. The raw logit gaps are close between the two defenders at every matched checkpoint — closer than the probabilities were — while the thresholds still diverge completely (referent 18 already captures around eps≈17–24 across this range; referent 3 doesn't capture at eps=26 anywhere in it, including at 20k where its own gap, 19.45, is barely above referent 18's 40k value of 20.96). If the incumbent's logit gap were the gating quantity, similar gaps should predict similar thresholds. They don't. Whatever sets the threshold isn't a property of the incumbent's row in isolation, at least not one either of these two scalars captures — it may depend on the challenger's own starting logit at that message before perturbation, or on some interaction between the two rows that a single number from either side can't see. Both untested; I'd rather say that than propose a third scalar without checking it first.

Notebook §7.58.

Ran your checkpoint design before defending anything. It's the right experiment, it gives a clean answer to the question it was built for, and it also produced a result I didn't expect and can't currently explain.

The grip metric, your recovery of it, and the one number I under-printed

9.33 for wall 3 was rounding — full precision gives 9.3303, matching your recovered 9.301 (the small remaining gap is wall 2 vs wall 3 genuinely differing in the fourth digit, not an error). Confirmed both to fifteen digits before answering.

Walls 2 and 3 are one defender, not two — accepted, and it's why I ran your experiment instead of pushing walls 2/3 further

You're right that two walls sharing message 10 give one grip value measured twice, and that one measured threshold plus one lower bound can't separate multiplicative from additive. Rather than spend runs pushing walls 2/3 toward a possibly-nonexistent threshold, I ran the checkpoint design: same message, same defender (referent 18, message 0), grip varied by reading it at different points in training time rather than across different walls, threshold found at each with the same post-perturbation budget (40 000 steps) used everywhere else.

checkpoint    grip     threshold bracket
 10 000       5.70     (14, 17]
 20 000       7.43     (20, 22]
 30 000       8.18     (22, 24]
 40 000       8.41     (23, 24]   (already established)

Four points, one defender, no wall confound. Fit both forms:

additive:       thr = -1.40 + 2.98·grip     residuals: -0.09, +0.25, +0.01, -0.17
multiplicative: thr = 6.43 · 10^(0.068·grip) residuals: -0.14, +0.52, -0.02, -0.36

Both fit comparably well over this range — the data doesn't cleanly separate the two forms here either, but for a different reason than before: they've converged onto nearly the same curve locally, not because the range is too narrow to distinguish them, but because both are locally well-approximated by the same line over four points spanning less than three decades of grip. Where they'd disagree is far outside this range, which is exactly the region I don't need them to agree in for what comes next.

Both extrapolate to the same place for walls 2 and 3's grip:

additive:        thr(9.31) = 26.4
multiplicative:  thr(9.31) = 27.5

The prediction, checked against data I already have — and it fails

Walls 2 and 3 sit at grip 9.31–9.33. Both fitted curves say their threshold should be around 26–27 — inside the range I already tested. But I pushed both walls to +50 last round and found R frozen at a constant near-zero the whole way, never crossing 0.5 anywhere from 25 to 50.

The single-defender calibration predicts a threshold that the independent two-wall data says doesn't exist in that range at all. Grip clearly matters — the four-point fit within one defender is clean, low-residual, and moves in the right direction as training proceeds — but it isn't the whole story once you cross to a different defender. Something about referent 3 or referent 14 (walls 2 and 3's incumbents) versus referent 18 (wall 1's) makes the threshold behave differently than grip alone predicts, and I don't know what yet. Runner-up mass was your own ruled-out candidate — walls 2 and 3 differ 2.3x on it and behave identically, so it isn't reviving here either. This might be a second axis entirely (something about the shape of the sender's own row, or the specific logit configuration reached by 40 000 steps of training on a different random draw) that the grip number doesn't capture.

Your last question, answered, and it resolves cleanly in the other direction

Grip of the frozen wall-1 receiver at eps_perturb=26, full precision:

R[0,18] = 0.999999996115699
1-R = 3.884301e-09
grip = 8.4107

Exactly the unfrozen base value, to four decimals — not raised. Freezing holds the receiver's parameters fixed, so its grip is whatever it was at the 40 000-step checkpoint before freezing, unchanged by how hard the sender is subsequently pushed. Your hypothesis was the sharper of two ways this could have gone, and it's the one that didn't happen: the freeze result and the grip law are independent findings, not the same one measured through two knobs. Freezing prevents the receiver from lowering its grip at all, regardless of what value that grip started at; the grip law describes how hard it is to lower a grip that's still allowed to move. Different mechanisms, and now confirmed as different rather than assumed to be.

Notebook §7.57.

Checked the scoring before defending the claim. You were right, and it's worse than a labeling slip — walls 2 and 3 have never shown a genuine capture at any perturbation I've tried, up to +50.

Were walls 2 and 3 scored on S or on R? On S. And it was wrong.

wall 2, R[10,4]  at eps_perturb = 25, 26, 30, 35, 40, 50:
  6.51e-12, 6.67e-12, 6.67e-12, 6.67e-12, 6.67e-12, 6.67e-12  — frozen at a constant near-zero, never crosses 0.5

wall 3, R[10,20] at eps_perturb = 25, 26, 30, 35, 40, 50:
  1.41e-11, 1.49e-11, 1.49e-11, 1.49e-11, 1.49e-11, 1.49e-11  — same shape

Every "capture" I reported for walls 2 and 3 was the same wasted, frozen commitment I caught on the receiver-frozen test two messages ago — I just hadn't checked for it here. S.max() saturates to 1.0, argmax lands on the target message, and the receiver's actual credit for that cell sits frozen at a constant nine to twelve orders below chance, completely unmoved across a 2x range of perturbation strength. The "three for three, mechanism generalizes" claim collapses to one for one. Wall 1 is the only wall I've verified with a genuine capture anywhere in this exchange.

Your incumbent-grip prediction — confirmed, and it explains exactly what just happened

Before any perturbation, the receiver's own decode distribution at the contested message:

wall 1, message 0:   incumbent R=0.9999999961  (8.41 decades of grip)   runner-up 7.93e-10
wall 2, message 10:  incumbent R=0.9999999995  (9.31 decades of grip)   runner-up 1.19e-10
wall 3, message 10:  incumbent R=0.9999999995  (9.33 decades of grip)   runner-up 5.26e-11

Message 10's incumbents grip about one decade tighter than message 0's, and that's exactly the pattern that predicts what I found: walls 2 and 3 needed far more than the extra push that moved wall 1, and didn't move at all even at +50 combined with adam_eps down to 1e-16. Tried the same unfreezing move that worked on wall 1 — smaller adam_eps at eps_perturb=26 — and it made things worse, not better: R[10,4] and R[10,20] both shrink monotonically as adam_eps drops (1.34e-13 → 3.26e-15 → 1.77e-16, same shape on wall 3). Wall 1's escape needed a smaller adam_eps because its incumbent's grip was the weaker of the three; walls 2 and 3 sit behind a materially tighter incumbent and the same lever doesn't reach them in this range. Your prediction wasn't just directionally right, it's the first number in this whole exchange that anticipated a result before the perturbation was run rather than explaining one after.

The two cells that actually do the freeze work

eps_perturb=24:  unfrozen (adam_eps=1e-8) CAPTURE, R[0,0]=1.0000   |   frozen: retour
eps_perturb=25:  unfrozen CAPTURE, R[0,0]=1.0000                    |   (bracket confirmed: (23,24])
eps_perturb=26:  unfrozen CAPTURE, R[0,0]=1.0000                    |   frozen: S=1.0000, R[0,0]=4.4e-10

Both comparisons you flagged as load-bearing hold on real capture, not the S-only proxy. The freeze conclusion stands on the two cells, not the seven — noted as you asked.

Where this leaves the whole line of argument

One confirmed wall. A prediction that correctly anticipated why the other two haven't budged, tied to a measurable pre-perturbation quantity — incumbent grip — rather than to seed identity. That's a real result, and it's a narrower and better-grounded one than "the mechanism generalizes across walls": it's now "the threshold is set by how hard the incumbent is gripping, measurable before you perturb anything," which makes a testable prediction I haven't yet run — push walls 2 and 3 far enough (into the hundreds, going by the extra decade of grip) that they should eventually show the same two-part structure wall 1 did, sender push plus small adam_eps, just at a proportionally larger scale.

Notebook §7.56.

Ran your positive control before writing anything else. It reverses what I sent last round.

The apples-to-apples grid — you were right, my window was the problem

Wall 1 on the exact reduced grid I'd used for wall 2 (eps_perturb in {15,18,20,23}, adam_eps from 1e-8 to 1e-16):

adam_eps=1e-8:   all four retour
adam_eps=1e-10:  eps=23 TRANSFERT, rest retour
adam_eps=1e-12:  eps=20,23 TRANSFERT, rest retour
adam_eps=1e-14:  eps=20,23 TRANSFERT, rest retour
adam_eps=1e-16:  eps=20,23 TRANSFERT, rest retour

Wall 1, tested on wall 2's own window, comes back mostly retour too — exactly your prediction. At default adam_eps, all four cells revert, same as wall 2. The 18–20 convergence I published only shows up once adam_eps drops to 1e-10 or below. So the negative result I reported for wall 2 wasn't testing a window where wall 1 itself reliably transfers either — it was testing a window where both walls mostly revert at default settings, and I never checked whether wall 2 had its own version of the story one or two eps_perturb units further out.

eps_perturb=24–26 on walls 2 and 3 — both transfer

wall 2 (referent 4, message 10):  eps=24 retour, eps=26 CAPTURE, eps=30 CAPTURE
wall 3 (referent 20, message 10): eps=24 retour, eps=26 CAPTURE, eps=30 CAPTURE

Both walls transfer, at a threshold two units above wall 1's. The "no generalization" claim from last round is wrong, and it's wrong for exactly the reason you gave: wall 2's tested range (15–23) never reached the cell where the effect would show, the same way wall 3's single tested point (20) was a cell where wall 1 itself has never transferred. I retract the idiosyncrasy conclusion. Every wall I've checked — three for three now — has a real capture threshold under this perturbation; the threshold sits at 23–24 for one seed and 25–26 for the other two, which is ordinary seed-to-seed variation in a real mechanism, not evidence the mechanism doesn't exist outside one seed.

What I checked and couldn't confirm in the time I had: whether wall 2's threshold also drops under smaller adam_eps the way wall 1's did. A quick sweep at eps_perturb 20–25 under adam_eps down to 1e-12 stayed retour throughout — but that's below wall 2's own threshold (26), so it isn't a fair test of convergence either, for the identical reason the last round's tests weren't fair tests of transfer. I'd need to sweep adam_eps right at wall 2's own boundary (25–27) to check whether it also converges downward, and haven't done that yet.

Your factual question, answered directly

One optimizer, not two: torch.optim.Adam(parametres(e, r), lr=lr, eps=adam_eps), and parametres(e, r) is the sender's and receiver's parameters concatenated into one list. So yes — the sweep sets eps on both. Referent 18's row does see 1e-6 in arm B, and your ratio table is exactly right (I recomputed it independently before answering): 1.00000 at the receiver's own minimum, climbing to 35.25x at sqrt(v)=5.29e-07 — referent 18's row — and 91–100x beyond that.

Which means the reciprocal "confirmation" from two rounds ago has the problem you're describing, and I don't think I can defend it as stated. The receiver block matching under arms A and B was guaranteed by the census, not evidence — every receiver coordinate sits below 1e-9, so of course a change from eps=1e-8 to eps=1e-6 looks uniform there. But referent 18's own row sits in a regime where arm B is not a faithful rescaling.

Rather than leave that open, I isolated it — two separate Adam instances, one per agent, so I could give the receiver the reciprocal settings while holding the sender at the original ones, and the reverse:

receiver alone at (eps=1e-6, lr=5.0), sender held at (eps=1e-8, lr=0.05):
  eps_perturb=18,20,23:  all retour — the receiver's rescaling ALONE never produces a transfer

sender alone at (eps=1e-6, lr=5.0), receiver held at (eps=1e-8, lr=0.05):
  eps_perturb=18,20:  chaos (argmax elsewhere)
  eps_perturb=23:     TRANSFER — sender alone is sufficient, at the same threshold as the combined test

Settled: it's the sender, not the receiver. The one genuine transfer in the original reciprocal test wasn't the receiver's uniform equivalence doing the work — the receiver alone can't produce it at all, at any of the three perturbation sizes I tried. It's referent 0's own row getting an oversized kick from lr=5.0, exactly the mechanism your ratio table flagged, and it reproduces the transfer on its own with the receiver held at completely ordinary settings. The lr/eps equivalence claim survives on the receiver census and the freeze direction, which are genuinely about the receiver. The transfer direction was never about the receiver at all — I was crediting the wrong half of the system for something the sender's own dynamics were doing by themselves.

Your idiosyncrasy question

0.037037 unperturbed is 1/27 — you're right that this is the generic maximally-indecisive state, not a special one, and I should have caught that before calling it evidence of anything. Wall 3's unperturbed continuation (checked last round) also lands at 0.037 across every adam_eps tested. I don't have wall 2's unperturbed continuation yet. Given that walls 2 and 3 both turned out to have their own real capture thresholds a few units past where I'd stopped looking, I no longer think the unperturbed S.max() was ever going to distinguish anything — it's the same generic starting point for a wall whether that wall does or doesn't have a nearby escape threshold, and the threshold's existence is a separate fact this observable can't see.

One more, since I asked myself whether the receiver even needs to learn at all

If the sender alone (with the reciprocal settings) reproduces the transfer, does the receiver's learning matter, or is it just reflecting whatever the sender currently does? Froze the receiver's parameters entirely — never updated, sender trains alone at completely ordinary settings (eps=1e-8, lr=0.05):

eps_perturb=18 through 24:  all retour
eps_perturb=26:             S[0].max()=1.0000, argmax=0 — looked like a transfer

Before calling that a transfer, checked R[0,0] rather than trust R[0,18] — which, with the receiver frozen, can only ever equal its original fixed value and tells me nothing about whether referent 0 earned anything:

R[0,0] = 4.4e-10

Not a transfer. The same frozen, wasted commitment as the referent-1 test, six rounds back. Referent 0's row fully commits to message 0 given a large enough push, purely as a self-reinforcing runaway under Adam — but the frozen receiver still assigns all decode credit to referent 18, exactly as it always did, so referent 0 earns nothing for it. I nearly mislabeled it the same way I've now corrected twice this exchange, and caught it this time before publishing rather than after. So the honest answer to my own question is closer to the opposite of what the first pass suggested: the receiver's learning isn't incidental to a genuine transfer, it's required for one — every real capture this whole investigation found necessarily involved the receiver itself shifting credit, and a sender committing on its own, with nothing on the other end willing to update, produces the emptiest kind of "success" this project has a name for.

Notebook §7.55.

Ran both directions of your test before writing anything, and reported both as clean confirmations. One of them wasn't. Correcting in place before this goes further, since nothing here has been answered yet.

adam_eps=1e-8 (default), lr=5e-4, "a reason with no eps in it":
  eps_perturb=18   retour
  eps_perturb=20   FROZEN, NO VALUE   (stronger than you predicted — you named 23,24, this froze too)
  eps_perturb=23   FROZEN, NO VALUE
  eps_perturb=24   FROZEN, NO VALUE

adam_eps=1e-6, lr=5.0, reciprocal:
  eps_perturb=18   S[0].max()=1.0000, R[0,18]=0.0000 — looked like REAL TRANSFER
  eps_perturb=20   S[0].max()=1.0000, R[0,18]=0.0000 — looked like REAL TRANSFER
  eps_perturb=23   S[0].max()=1.0000, R[0,18]=0.0000 — looked like REAL TRANSFER

The freeze prediction lands exactly, and even harder than you predicted — eps_perturb=20 froze too, which had been a retour under every setting I'd tested until now.

The reciprocal did not. My two-column check (S[0].max()>0.5, R[0,18]<0.5) said all three transferred, and I reported that as confirmation. It's the same blind spot as the bug from two rounds ago, one level further in: the check never asks which message referent 0's argmax actually points to. lr=5.0 is a wild learning rate for logit space, and instead of cleanly reverting or cleanly capturing message 0, it overshoots — referent 0's logit at position 0 crashes from +22 to -53 in a handful of steps at eps_perturb=20, not toward the uniform 1/27 the smaller-lr arm reaches, but straight through zero and out the other side. Checked where referent 0's argmax actually landed:

eps_perturb=18:  argmax = message 9   (not 0 — chaos, not capture)
eps_perturb=20:  argmax = message 22  (not 0 — chaos, and now colliding with referent 23 instead)
eps_perturb=23:  argmax = message 0   (genuinely captured — the one real transfer)

Two of the three "transfers" are the system being thrown into an unrelated configuration by an absurd learning rate, not the predicted mechanism playing out. R[0,18] dropped to zero in the first two cases for a reason that has nothing to do with referent 0 capturing anything — referent 18 lost its claim on message 0 through some other route while referent 0 landed somewhere else entirely, and my column check couldn't distinguish that from the thing it was meant to detect. Only eps_perturb=23 — the cell already closest to the boundary under ordinary settings — shows a clean capture of message 0 specifically.

So the reciprocal test is confirmed once, not three times, and I don't think lr=5.0 was ever a fair test of "same ratio, same physics" the way lr=5e-4 was. 5e-4 is a small, orderly reduction that keeps every row inside the smooth regime the linear step approximation describes. 5.0 is a hundred-fold increase on a system already balanced on a knife edge, and at that scale Adam's steps stop being small perturbations and start being able to jump a saturated logit clean across zero in one move — which is a different, cruder kind of evidence than the one-directional test provides.

I tried two gentler multipliers to get a clean confirmation rather than leave it on the one contaminated cell:

x2  (adam_eps=5e-7, lr=0.1):   eps=18,20 retour (argmax happens to land on 0, but S[0].max()~0.037 — noise, not capture)
                                 eps=23 REAL capture — matches default behaviour almost exactly
x10 (adam_eps=1e-7, lr=0.5):   eps=18,20,23 all retour, argmax elsewhere, no capture anywhere

Neither adds clean support. x2 reproduces what the default settings already do at this seed — it isn't evidence the ratio is doing anything beyond ordinary variation this close to the boundary. x10 shows less transfer than x2, which isn't the monotone trend the equivalence claim would predict, and at n=1 seed this deep in the sensitivity range I'd read that as noise near a threshold rather than a real reversal. The equivalence argument survives on the freeze direction and the census, which are both clean. The transfer direction has one genuine confirming data point (lr=5.0 at eps_perturb=23) and two more attempts that neither confirm nor cleanly contradict it — I don't have a gentle multiplier that reproduces the clean three-for-three result on this seed, and I'd rather say that than paper over it with a second imprecise test.

And the correction needed correcting once more. Once I'd found chaos at lr=5.0, I formed the hypothesis that large lr generally throws referent 0 off-target rather than producing either a clean revert or a clean capture — and that my own earlier lr=2.0 result from two rounds ago, which I'd already relabeled once from "BASCULE" to "FROZEN, NO VALUE," might have the same problem, since that relabeling also only checked S[0].max() and R[0,18], never the argmax location. Checked it:

lr=2.0, eps_perturb=18:  argmax = message 6    (not 0 — "frozen" label was also wrong)
lr=2.0, eps_perturb=20:  argmax = message 20   (not 0 — same)

Hypothesis confirmed, and it wasn't frozen either — it's the same chaos as lr=5.0, just landing somewhere else. So of the five large-lr cells I've now checked for argmax location (three at lr=5.0, two at lr=2.0), four are chaos and none is a genuine freeze on the perturbed target. My classification vocabulary was missing a category: "retour" (uniform), "real transfer" (captures the intended target), and what I'd been calling "frozen, no value" turn out to split into two genuinely different things — a row that stays put on the perturbed logit without earning credit (which I haven't actually observed at large lr once I check properly) and a row that gets thrown elsewhere by an oversized step (which is what both lr=2.0 and lr=5.0 actually produce). The headline conclusion doesn't change — lr still never produces a targeted capture of message 0 across the whole range I've tested, eps=23 under lr=5.0 aside — but the mechanism I attributed to those cells was wrong twice, not once, and I'd rather have both corrections on the record than let the second one stand uninspected because the first one already felt like enough humility for one round.

I checked your arithmetic before trusting the prediction rather than after:

(g+1e-6)/(g+1e-8) at g=max, p50, min:  99.85, 99.998, 99.9997 — uniform to 0.15%
gain g/(g+eps) for sqrt(v)=5.29e-07 (referent 18's row):  0.9814 at eps=1e-8, 0.3460 at eps=1e-6

Both match your numbers exactly. So the receiver's whole matrix moves as one scalar-scaled block under eps in {1e-8, 1e-6} — the 99.85–99.9997x ratio is uniform enough that no rotation happens — while referent 18's own row sits in the one band where the two eps values genuinely diverge (0.98 against 0.35, not ~100x), which is the "localized band" branch you flagged as the stronger of your two possible outcomes. Given that eps=1e-6 still moves the boundary despite referent 18's row barely being touched, the effect is carried almost entirely by the receiver's scalar rescaling, not by that one row — so the weaker branch (uniform lr-equivalent effect) is the one the data actually landed on, not the localized-band one. Worth being precise about which of your two branches this is, since you offered both.

Your switch-not-knob framing is now the operative one: at 1e-8 and 1e-6 the receiver is running momentum-SGD at lr/eps, not Adam, on every coordinate; at 1e-14 it's sign-like Adam everywhere; 1e-12 is the only setting in the original sweep that actually sampled the interior. I don't have a correction to make to that — it's confirmed twice now, once by the census and once by the test that could have broken it.

Ran the untested interior point rather than leave it as a caveat:

adam_eps=1e-13:  eps_perturb=18 retour, 20 REAL TRANSFER, 23 REAL TRANSFER

Same pattern as 1e-12 and 1e-16 — already on the plateau, not between it and the boundary. So the plateau's left edge is somewhere below 1e-13, consistent with your ~3×10⁻¹⁴ estimate rather than contradicting it, but I haven't isolated the exact edge — 1e-13 was the one cell missing from the original sweep, and it's already flat. If the edge matters for anything downstream, the next untested gap is between 1e-14 and min|g|=2.86e-14, which is closer than a cell width away and probably not worth chasing further on this one seed.

The full audit, since two corrections in a row is exactly the signal to check everything else rather than stop

I'd only verified argmax location on the cells that had already broken (lr=2.0, lr=5.0), not on anything else. Everything else published this exchange — the original 23/24 threshold, the full 18–20 convergence table, the schedule test's arm A, and the eps=1e-6 freeze itself — had only ever been checked on S[0].max() and R[0,18], never on where the argmax actually landed. Went back through all of it, and further still: does the referent that's supposed to cede its claim actually land cleanly on its other message, and does the total collision count genuinely improve, or does resolving one collision quietly create another?

adam_eps=1e-12, eps_perturb=23:  referent 18 -> message 8 (S=1.0000000000, clean)   distinct=26/27, 1 collision left, elsewhere
adam_eps=1e-8,  eps_perturb=24:  referent 18 -> message 8 (S=0.9999999997, clean)   distinct=26/27, 1 collision left, elsewhere

Both checked cleanly — referent 18 lands on its other message without ambiguity, and the collision count drops by exactly one with no new collision appearing as a side effect. Full audit, not the partial one:

original threshold, adam_eps=1e-8, eps_perturb=24:                    argmax=0, genuine capture
convergence table, every published REAL TRANSFER (1e-10 through 1e-16): argmax=0, genuine capture, all of them
schedule test arm A, K=50/100/200:                                     argmax=0, genuine capture, all of them
eps=1e-6 freeze, eps_perturb=23 and 24:                                argmax=0, genuinely frozen ON the target, not chaos

Everything else holds. Every prior "real transfer" is a real transfer, every "frozen" cell under an eps-only perturbation is genuinely frozen on message 0, not thrown elsewhere. The chaos I found is specific to extreme lr — 2.0 and 5.0 — and doesn't touch anything in the adam_eps sweep down to 1e-16, nor the schedule test, nor the original threshold this whole line of argument is built on. That's the boundary of the damage: two cells out of roughly twenty I've now individually checked by argmax, both under a learning rate two orders above anything the base runs ever used.

A much bigger problem than the argmax bug, found by finally asking whether any of this generalizes

Every number in this five-round thread — the 23/24 threshold, its convergence to 18–20, the latch, the lr/eps equivalence — comes from one seed's one collision, perturbed by a hand-added scalar on one specific logit. I never checked whether that collision was typical of a wall, or whether the whole mechanism exists without the artificial push. Both checks say no.

The unperturbed wall never moves, at any adam_eps. Same seed, same referent 0, zero artificial perturbation, 300 000 further steps:

adam_eps=1e-8:   S[0].max()=0.037, still uniform
adam_eps=1e-12:  S[0].max()=0.037, still uniform (a *different* referent's collision resolved on its own, unrelated)
adam_eps=1e-16:  S[0].max()=0.037, still uniform

Nothing in the entire five-round mechanism shows up without a hand-crafted push that never happens during ordinary training. Every threshold, every latch, every equivalence I've verified this exchange describes what happens to an artificially destabilized row, not what happens to a wall on its own.

And the same artificial push doesn't reproduce anything on a different wall. Found two more walls from two different generator streams, same construction, same perturbation range (15–23), same full adam_eps sweep (1e-8 to 1e-16):

wall 2 (message 10, loser=referent 4):   20 cells, ALL retour — no threshold anywhere in this range
wall 3 (message 10, loser=referent 20):  unperturbed, 300k steps: never resolves, any adam_eps
                                          perturbed +20: 3 cells, ALL retour, no threshold

Not one of the other two walls shows any adam_eps sensitivity at all, at the exact perturbation strengths and eps values that produced a clean, precisely-characterized boundary on the first. Whatever makes idx5's referent 0 sit close enough to a genuine escape threshold that a hyperparameter five orders of magnitude away can tip it — that's a property of that row's specific position in logit space after that specific 40 000-step run, not a property of walls in general. I spent five rounds building an exact, mathematically verified account of one seed's idiosyncrasy and never checked whether it was an idiosyncrasy until asked directly whether the results were weak. They were, and now I know in what specific sense: everything upstream of this paragraph is a real, carefully-verified description of one row, not a mechanism.

Notebook §7.54.

Your question, answered first

Gradient magnitude on the receiver at step 1, all 729 coordinates:

min=2.86e-14   p10=1.50e-13   p50=2.38e-13   p90=1.09e-12   p99=9.53e-12   max=1.52e-11
716 of 729 coordinates sit in [1e-13, 1e-9]. All 729 are under 1e-9.

Every single receiver coordinate is already in your sensitive band at step 1, not just some subset. The receiver had already converged in the base 40 000-step run before I applied the perturbation, so its whole gradient is small everywhere — there's no separate "band" of near-zero coordinates to isolate by masking, because the entire matrix is that band. Your masking test (freeze the 1e-9–1e-13 coordinates, see if that alone reproduces the shift) would freeze essentially the whole receiver, so I ran your other falsifiable test instead, adam_eps=1e-6, since it doesn't depend on finding a sub-population that isn't there.

Your two algebraic points — I trust them as algebra and didn't re-derive them

lr scales the whole update by one scalar and cannot rotate it — that's true by construction of Adam's update rule, not something that needs a toy to confirm, and it matches what I'd already found (nothing moved until lr was cranked to an unrealistic 40× the base rate, and even then non-monotonically). beta2 can't touch t=1 because bias correction forces v_hat = g² at the first step regardless of beta2 — also algebra, and it explains cleanly why beta2 did nothing in my sweep down to 0.5: if the door closes inside the first fifty steps, as the K=50 schedule flip showed, beta2 never gets enough steps to diverge from its universal t=1 value before the outcome is already decided.

eps=1e-6, and this is where I found a real bug in my own criterion

First pass, using my existing classifier (S[0].max() > 0.5 counts as "bascule"):

eps_perturb=18,20: retour   eps_perturb=23,24: BASCULE   (non-monotone, unexpected)

That looked like a genuine reversal — bigger eps making escape easier — so I traced it step by step instead of trusting the label, and it exposed the same failure mode as your referent-1 test from three rounds ago. S[0,0] saturates to 1.0 from the raw perturbation, and at adam_eps=1e-6 it stays frozen there for all 40 000 steps — but R[0,18] stays at exactly 1.000000 the entire time too. Referent 18 never gave up anything. Referent 0 is sending message 0 with full confidence and getting zero credit for it, permanently — the same wasted, frozen commitment as before, not an occupancy transfer. My classifier only checks the sender's own saturation and never checks whether the receiver actually moved, so it can't tell a real transfer from a frozen artifact that happens to look identical in S alone.

Corrected, checking R[0,18] explicitly on everything, including my own previously published numbers:

adam_eps=1e-8  (default) :  18,20,23 retour  |  24 REAL TRANSFER          <- unchanged, matches what I published
adam_eps=1e-12 (my "18-20"): 18 retour | 20,23,24 REAL TRANSFER            <- unchanged, matches what I published
adam_eps=1e-6  (new)      :  18,20 retour  |  23,24 FROZEN, NO VALUE       <- was misclassified as BASCULE, corrected

The two numbers I've already sent you — 23/24 under default settings, the 18–20 convergence under 1e-12 — hold. Both check out as genuine transfers under the corrected criterion, not frozen artifacts; I re-ran them specifically to make sure this bug hadn't been sitting under everything since the schedule test. eps=1e-6 is not a third data point on the same axis at all — it's your Adam-eps-freeze mechanism showing up a second time, this time on the perturbed parameter itself rather than on the row I originally found it on, and it produces a state that looks like escape in the one column I was checking and isn't one in the column that actually matters.

What this means for the sweep going forward

Every threshold claim I make from here needs both columns before I report a direction, not just the sender's own saturation — I'm adding that as a standing check, not a one-off fix, since this is exactly the class of error the notebook already has a rule for (a printed value can saturate while the state it's supposed to represent keeps moving underneath it) and I'd applied that rule to S_max two rounds ago without noticing my pass/fail label had the same blind spot one level up.

Audited everything else that used the same flawed criterion, not just the new test

Théo asked whether I'd actually searched further rather than stopping at the fix. I hadn't — I'd only checked the two numbers I was about to publish and left every earlier BASCULE label from the last three rounds unaudited, including the ones already sitting in the notebook. Reran every prior sweep that used S[0].max()>0.5, checking R[0,18] on each cell this time:

convergence table (adam_eps 1e-8 to 1e-16, eps_perturb 18/20/23): every prior BASCULE -> REAL TRANSFER, unchanged
schedule test arm A (K=50, 100, 200): every prior BASCULE -> REAL TRANSFER, unchanged
lr sweep (0.05 to 2.0): lr=2.0 at eps=18,20 -> was BASCULE, is actually FROZEN, NO VALUE

One more casualty, and it's the lr=2.0 "non-monotone exception" from two rounds ago. R[0,18] stays at 1.000000 in both cells I'd flagged as flipping — same frozen-commitment artifact, not a real transfer. Corrected, lr produces zero real transfers across its entire tested range, 0.05 to 2.0, matching beta2's complete inertness exactly rather than having an odd exception at the high end. That's a cleaner result than what I published two rounds ago, not a weaker one: the "specific to adam_eps" conclusion holds more sharply once the one contaminated cell is removed, and I no longer have a non-monotone loose end to wave away as "one seed, not over-read" — it wasn't a real signal at all.

Everything else — the 18–20 convergence, the schedule test's arm A — checks out clean. The bug only ever touched two cells across everything published this exchange, and both corrections point the same direction: toward adam_eps being the sole real lever, not away from it.

Notebook §7.53.

Straight answer to your question first: raw, uncorrected exp_avg_sq. I printed opt.state[...]['exp_avg_sq'][...].item()**0.5 directly, no 1-beta2^t correction. So it's your right-hand column that matches what I actually reported — 78, 66, 34, 9.5, 5.0, 5.5 — not the bias-corrected 11.0x one. I should have said that the first time instead of leaving the ratio unlabeled.

Your schedule test, run rather than reasoned about — and it settles latch versus race outright

A: eps=1e-12 for steps 1..K, then eps=1e-10 (predicted: flips once K passes v's escape, 10-50)
  K=5    retour     K=20   retour     K=50   BASCULE
  K=10   retour     K=30   retour     K=100  BASCULE
                                       K=200  BASCULE

B: eps=1e-10 for steps 1..K, then eps=1e-12 (predicted: keeps reverting once K passes S[0,0]'s decay, 100-200)
  K=50    retour    K=200   retour    K=500   retour
  K=100   retour    K=300   retour    K=1000  retour
  K=150   retour

Arm A flips exactly where you said it would — reverting through K=30, flipping at K=50, right at the edge of the 10–50 window your v-crossing estimate predicted. Arm B never flips, not even at K=1000 — twenty-five times past the window where you expected it to still be recoverable. That's not the "same finish line, order of magnitude apart" shape a race would produce. It's a door that closes once, permanently, inside the first fifty steps, and no amount of running with a smaller adam_eps afterward reopens it. You called it a latch and asked for the schedule test to tell them apart; the schedule test says latch, not race, and says it more sharply than either of us expected — I thought B would at least start reverting-then-recovering somewhere in the middle of that K range, and it doesn't move at all across three orders of magnitude of K.

What this does to "18–20" — and the other levers didn't do what either of us expected

You're right that this isn't a clean "artifact removed" story. I checked three other levers that should give the receiver more early gain the way a smaller adam_eps did, since you named that as the strongest available argument for publishing the sweep rather than a number. None of them behaved like adam_eps did.

lr up to 3x, nothing moves:

lr=0.05 to lr=0.15, eps_perturb in {18,20,23}: retour in all twelve cells

beta2 down, nothing moves, even far outside any range anyone would train with:

beta2=0.999 to beta2=0.5 (v tracking recent gradients 500x faster), all twelve cells: retour

lr at absurd values, and only then, sometimes:

lr=0.3, 0.5, 1.0: retour in all nine cells
lr=2.0 (40x the base rate): eps=18 BASCULE, eps=20 BASCULE, eps=23 retour (non-monotone — one seed, not over-read)

This is not the confirmation either of us expected, and I think it's the more interesting result. adam_eps moves the boundary by a factor of ~5 (23→18-20) across four orders of magnitude of its own value. beta2 does nothing at all across three orders of magnitude of its own natural range. lr does nothing until it's cranked to a value forty times the base rate — at which point the system is probably no longer doing anything you'd call the same optimization regime, and even then the effect isn't clean (23 reverting while 18 and 20 flip is not the monotone signature the other sweeps showed). If "anything that buys the receiver early gain moves the boundary the same way" were the right generalization, beta2 should have been the cleanest lever of all — it directly controls how fast v tracks a fresh gradient, which is exactly the mechanism your step-by-step trace identified. It did nothing. That argues the mechanism is more specific to adam_eps's particular role — an additive floor in the denominator, not a rate parameter — than a generic "early responsiveness" story would predict.

Where this leaves the number

I don't think "18–20" is publishable as a corrected constant, and I don't think 23/24 ever was. Both are readouts of a latch the receiver can catch or miss inside its first fifty steps, and — now more precisely than I could say before running the other three levers — that latch is disproportionately sensitive to one specific optimizer constant (adam_eps) and nearly inert to two others (beta2, and lr within any range you'd actually train at). What's real and worth keeping is the shape: a genuine basin boundary in logit space, sitting somewhere in the high teens to low twenties for this seed under ordinary settings, decided in a window so early and so specifically gated by one additive constant that reporting any single number from it would misstate what was measured. The sweep is the finding, and now there's a second finding riding with it: the sweep only moves along one axis, not the three I expected it to.

Notebook §7.52.