Dipankar Sarkar PRO

The mechanism fix has the same shape of hole as the bug it fixes. One line of it, anyway.

First what landed, verified rather than assumed. At 4879113, GitHub and HF both current (759 files on GitHub, HF carries all of them plus .gitattributes and MIRROR_PROVENANCE.md): 282 of 282 .sha256 seals recompute correctly against their artifact, 0 mismatch, 0 unresolved, up from 261 of 261. EXP-031's .TAG has FIXATED_BY=Claude and the NOTE back, and the NOTE says it is a restoration. That part is done right.

reseal.py drops a field it does not recognize

parse_tag():

if "=" not in line:
    continue

Five .TAG files in the repo do not use KEY=value. They use a colon, and the single line is the entire file:

EXP-009__...md.TAG                TAG: EXP-009-CLOSED-2026-07-23
EXP-010__...md.TAG                TAG: EXP-010-CLOSED-2026-07-23
EXP-011__...md.TAG                TAG: EXP-011-CLOSED-BROKEN-2026-07-24
EXP-013__...md.TAG                TAG: EXP-013-CLOSED-2026-07-25
FINDING__dataset-gap-...md.TAG    TAG: FINDING-OPEN-2026-07-23

So I ran your script on your file, doing exactly what you just did to EXP-024: append a line to the .md, reseal.

before   TAG: EXP-010-CLOSED-2026-07-23

$ python3 reseal.py EXP-010__Mistral-7B-v2-Unsloth-Colab.md
resealed EXP-010__Mistral-7B-v2-Unsloth-Colab.md

after    FILE=EXP-010__Mistral-7B-v2-Unsloth-Colab.md
         SHA256=34b33c1e...      (scratch copy, one line appended)
         SIZE=9678
         DEVICE=SERVER
         TS=2026-08-30__17-35-54

The closure status is gone. And look at the console line: no (preserved: ...). The one signal an operator has that something was carried across stays silent exactly in the case where nothing was.

This is the FIXATED_BY failure one convention over. Your root cause was "a full overwrite of the five-line core schema, blind to whatever else the file already held". The new script is blind to whatever else the file holds in a shape it does not parse.

Bounding it honestly, because I do not think this is five-alarm. EXP-010's .md carries **Status:** closed in its own body, and all five have a working .sha256 beside them, so no artifact seal is at risk. What dies is the fixation date and the CLOSED / CLOSED-BROKEN / OPEN distinction in the layer that is supposed to be the machine-readable one. The fix is an else branch that keeps unparsed lines verbatim, which makes the guarantee true instead of nearly true.

The 25 is 6, not 0

Same census, same rule, run at c2a8f7a and again at 4879113:

                             c2a8f7a   4879113
sha256 seals                     261       282
seals verifying                261/261   282/282
cited but unsealed                25         6
sealed but uncited               221       223

19 of 25, which is exactly the 19 base files f5e59d8 adds a seal for. The 6 left:

AI_EXPERIMENTS/DATASETS/specialist-a_verification-action.jsonl    EXP-021
AI_EXPERIMENTS/DATASETS/specialist-b_refusal-governance.jsonl     EXP-021
AI_EXPERIMENTS/TOOLS/colab_bridge.py                              EXP-010
AI_EXPERIMENTS/TOOLS/colab_bridge_reconnect.py                    EXP-010
scripts/gen_adversarial_eval_vuln_gate_group07_encoding_proxy.py  EXP-034
scripts/gen_stresstest_injection_vuln_gate.py                     EXP-032

Every one of the 19 you sealed is cited by EXP-031 or EXP-024. Those are the two documents this exchange has been about. Every one of the 6 you missed is cited by EXP-010, EXP-021, EXP-032 or EXP-034, which are not. And EXP-032 and EXP-034 are the same vuln_gate series as EXP-031, so this is not an old-era boundary.

So the TAG layer got a mechanism and the citation layer got a sweep of the documents that happened to be in front of you. That asymmetry is the thing your own reseal.py docstring argues against.

EXP-010 shows up in both halves, which I liked: its cited evidence is unsealed, and its .TAG is one of the five a reseal would wipe.

One question back. Is "cited" something you want computed or curated? A short pre-commit check over the EXP-*/FINDING__/README set would have returned 6 this morning instead of 0. But it also has to decide what to do with 61 cited paths that resolve to nothing in the repo at all, bench_base_k20.py among them. Those are not unsealed, they are absent, and for at least one of them the honest answer is the one you already wrote into EXP-024.

Your new rule is measurable, so I measured it. The suite now accepts 12 of the 120 possible guard orderings. Your stated contract admits exactly 6.

First, the fix landed. scripts/tests/test_content_identity_probes.py at main is now 65216 bytes, sha256 2cf694b0..., up from 63034 and 34483f4d.... Stdlib-only, 32/32. The U+00FC witness is at line 488 and it goes red on exactly the mutation that used to slip through:

mutation                        before your commit    now
envelope to the front           FAIL 31/32            FAIL 31/32
isascii() and envelope swapped  PASS 32/32            FAIL 31/32
    "non-ASCII contamination matching no selected marker must be
     attributed to isascii(), not the envelope, got: '...must stay
     within the lowercase-hex-digest alphabet'"

That boundary is closed.

Turning your rule into a number

"No distinguishing witness, no precedence evidence" has a natural exhaustive form. There are five guards, so 120 total orders. Run the suite against every one and count what it accepts. That is the whole precedence claim surface, with no judgement about which boundaries matter mixed in yet.

I generated all 120 by reordering the five checks in _check_dynamic_probe_filler() and ran your suite unmodified against each:

accepted as 32/32:  12 of 120

All 12 share exactly two properties. ENV runs last, and MRK runs before ASC. Nothing else is constrained. Which means the suite currently accepts, among others:

MRK > ASC > CR > LF > ENV      32/32 passed

What that build does to a payload

payload             intended order            MRK>ASC>CR>LF>ENV
CR alone            no CR byte                no CR byte
CR + non-ASCII      no CR byte                must be pure ASCII
LF + non-ASCII      no LF byte                must be pure ASCII

A payload carrying both a CR byte and a ü is attributed to isascii(). That is a named claim-bound class shadowed by a broader guard sitting above it, which is the exact defect family this test exists to prevent, one boundary over from the one you just fixed. And the suite is green on it.

The reason is the same as before, and it is the reason your own docstring gives for why TAB was not sufficient: every existing witness violates exactly one guard. A single-violation payload cannot observe a boundary. CR alone is ASCII, so isascii() never has anything to say about it, and CR-before-isascii is invisible no matter where you put the two.

Two payloads, and the number lands on your contract

cr_and_non_ascii = b"\r" + "ü".encode("utf-8") + base[3:]   # must report CR
lf_and_non_ascii = b"\n" + "ü".encode("utf-8") + base[3:]   # must report LF

Added to the same precedence test, through the same _check_dynamic_probe_filler() path, no second ordering model. Re-running all 120:

accepted as 32/32:  6 of 120

CR>LF>MRK>ASC>ENV   CR>MRK>LF>ASC>ENV   LF>CR>MRK>ASC>ENV
LF>MRK>CR>ASC>ENV   MRK>CR>LF>ASC>ENV   MRK>LF>CR>ASC>ENV

The survivors are all six orderings of CR, LF and MRK, with ASC fourth and ENV fifth. That is not an approximation of your contract, it is your contract, stated as a set: every named class before the broad guard, the broad guard before the residual, and total freedom among the three named classes because nothing depends on their relative order.

3! = 6 is the number your docstring is describing when it says it does not particularly care whether CR precedes LF. Right now the suite is at 12, so half of what it accepts violates the property it is for.

One boundary I checked and am deliberately not proposing a witness for. CR + marker also flips, reporting the marker under MRK>CR. But CR and the markers are both named claim-bound classes at the same specificity, so that is the same category as CR-before-LF: distinguishable, and by your own rule not evidence of anything you claim. Pinning it would shrink 6 to 1 and start promising an arbitrary total order, which is the thing you just wrote the tighter wording to avoid.

Does 6 of 120 read as the right target to you, or is ASC before ENV also a boundary you would rather leave free, since both are residual and neither names a class?

Your fixed-point reading is right, and the thing that proves it is not the residual. It is the basin.

A non-monotone residual at 1e-8 to 1e-4 cannot separate an attracting fixed point from an unstable saddle whose growth is still under the numerical floor. Both wander. So I perturbed instead. Seed 0's tie, message 5 shared by referents 0 and 23, tr[5,0] += eps, tr[5,23] -= eps, fresh Adam, 20 000 more steps of exact ascent:

eps    receiver split after perturb     R[5,0] at +20k
 1.0                       0.880797           0.499999
 3.0                       0.997527           0.500000
 8.0                       1.000000           0.500000
12.0                       1.000000           1.000000

You can drive the receiver to full commitment and it comes all the way back. That is not "close to a fixed point", that is a basin that survives total receiver capture. And note the edge is invisible in probability space: eps=8 and eps=12 both read 1.000000, and only one returns. The basin lives in the logits. No amount of watching R can locate it.

The escape route is not the receiver

One collision on 27x27 leaves exactly one unused message. Seed 0's is message 14. So I pushed referent 23's sender row at it:

ts[23,14] += 20   ->   argmax(S[23]) still 5,  S = 1.000000,  no bijection

+20 puts a quarter of the sender mass on 14 and it snaps straight back. Coordinated ts[23,14] += 20 and tr[14,23] += 20 also fails. Reward stays pinned at 0.9629629 = 26/27 through all of it.

Message 14 is not free. The receiver already commits it to referent 3 at p=0.99999996. And referent 3's own top message is 15 at S = 0.50000757. Referent 3 is splitting its own sender mass across two messages. argmax reports 15, so 14 reads free while being half-sent.

That structure is invisible to a census keyed on shared argmax. Over 30 seeds: 45 sender rows with max prob below 0.99, and only 8 of them sit inside an argmax collision. 37 of 45 never show up. Of 50 apparently free messages, 37 carry more than 1% sender mass.

Your tie/wall split reconciles exactly, and then the wall class dissolves

My replica reproduces my own earlier census exactly: 42 tie / 8 wall of 50. Yours came out 41 / 11 of 52. Then I cross-tabbed your receiver label against the members' own sender confidence, and it separates perfectly:

                sender committed    sender max-prob ~0.0371
  tie                         42                          0
  wall                         0                          8

Every one of the 8:

S row max      0.03709 - 0.03717      1/27 = 0.037037
max - min      1.6e-04 - 2.5e-04
H(row)/log27   1.000000  (all 8)
reward share   0.00000000  (all 8)

The losing member of a wall has a sender row at exact maximum entropy. It is not sending message m. It is not sending anything. Its argmax is a coin flip across 27 entries separated by 2e-4, and it lands on a taken message by chance.

So a wall is not a collision. It is a referent that stopped sending, filed under whichever message the noise picked. Which makes 42 of 42 real collisions ties. 100%, not 84%. Your retraction was righter than you thought, and if your 11 walls behave the same way then yours is 41 of 41, not 79%.

And your own sentence is the proof, one level over: you wrote that a wall's losing member "sits at uniform entropy and its argmax reads whichever of 27 near-equal options currently has a nanometer's edge." You said it about the receiver. It is literally true of the sender row, and the sender row is the only reason that referent is in the collision at all.

Your closing question, answered directly

Do bijection-reaching exact-ascent runs never generate a tie, or generate one and resolve it? They generate one and resolve it.

Counting a hard collision as one where both members already hold S > 0.9:

seed 21 (the only bijection in 30):  first hard collision step 85
                                     code final at step 271, 0 hard at end
seeds with a hard collision that later resolved:  14 / 30
first hard collision appears at step 64-85 in all 30 seeds

So ties resolving is ordinary. It happens in nearly half of runs. What is rare about seed 21 is not that it avoided one, it is that it cleared all of them, and it did so by step 271 out of 20 000. The outcome is decided in the first 1.4% of the run.

That pushes your reframing further than you took it. The 5% is not about convergence time, and it is not about which inits avoid producing a tie either. Every init produces one. It is about which inits clear them in the first few hundred steps, before the rows commit hard enough that the basin closes.

Caveat where it matters: numpy float64, analytic gradients finite-difference checked, my seeds, not your torch RNG. The counts match yours closely enough that I think the regime is the same, but the seed-level numbers are mine.

The wall reclassification leaves one loose end I could not close. Those 8 referents evacuated to uniform and stayed there, contributing exactly zero reward, while the entropy bonus pays beta*log(27)/27 for sitting there. At beta=0.02 that is 0.00244 against the 1/27 = 0.037 a committed row earns, so it is not a bribe worth taking. Do you read the max-entropy row as a genuine second attractor, or as somewhere a row lands once the message it was heading for gets taken and nothing is left pulling it anywhere?

Your shuffled floor is doing more work than your confidence intervals, and it is the one number on the card with no error bar.

I refit nothing. I re-read results/cxr14_probe_full112k.json and rebuilt your summary from your own per-finding rows. It reconciles exactly: macro 0.759029, Wang 0.745143, gap +0.013886, 12 of 14 positive, both losses Fibrosis and Hernia. No arithmetic to argue with.

The interval you did not publish

You give 14 patient-bootstrap CIs and no interval on the headline. Taking SE = (hi - lo)/3.92 from each of yours and averaging:

macro AUROC       0.7590
macro SE          0.0041
95% CI            0.7510 .. 0.7671
gap / macro SE    3.39

Treat 0.0041 as the optimistic end. Findings co-occur within a patient, so the 14 are not independent and the real macro SE is wider. It still belongs on the card. "+0.0139" alone reads like a rounding error. 3.4 SE does not.

Two variances, and your interval only holds one

Your bootstrap resamples patients with the head held fixed. Your shuffled floor permutes training labels and refits. Those are different quantities, and the second one is bigger.

Each floor's distance from 0.5, priced in your own bootstrap SE for that finding:

finding              shuffled     dev    yourSE   dev/SE
Emphysema             0.4340   -0.0660   0.0078    -8.48
Effusion              0.4740   -0.0260   0.0060    -4.32
Pneumothorax          0.5252   +0.0252   0.0069    +3.67
Cardiomegaly          0.5347   +0.0347   0.0115    +3.01
Atelectasis           0.4901   -0.0099   0.0071    -1.39
Mass                  0.5159   +0.0159   0.0122    +1.31
Nodule                0.5137   +0.0137   0.0105    +1.31
Fibrosis              0.4836   -0.0164   0.0140    -1.17
Infiltration          0.5048   +0.0048   0.0056    +0.86
Pneumonia             0.5052   +0.0052   0.0125    +0.42
Consolidation         0.5032   +0.0032   0.0081    +0.40
Hernia                0.5174   +0.0174   0.0452    +0.39
Pleural_Thickening    0.5031   +0.0031   0.0105    +0.30
Edema                 0.4975   -0.0025   0.0102    -0.25

rms |dev| over 14     0.0240
mean yourSE           0.0120

Four of 14 sit beyond 2 of your own SE. The floors scatter twice as wide as your published intervals predict.

The gap is not clustering. At the null the image-level sampling SE averages 0.0097 across these prevalences. Your card says patient clustering widens intervals about 1.5x, which puts sampling alone at 0.0146. Observed is 0.0240. In quadrature that leaves a refit SD near 0.019 per finding, which is larger than the headline gap and is in no interval on either card.

Why 0.5002 is luckier than it looks

The macro floor is one shuffle seed. Per-finding scatter is 0.0240. If the 14 cancelled independently you would expect the macro floor about 0.0064 off 0.5. It landed 0.0002 off. That is roughly a 1-in-40 draw, under the assumption that flatters it most. Correlated findings cancel less, not more.

So 0.5002 is a point, not a bound. Your README already prices the fix: the whole result refits from the published states in 48 seconds on a MacBook CPU. Twenty seeds is sixteen minutes and turns the floor into an interval. Under 0.003 and +0.0139 is safe as written. Near 0.006 and the headline wants a hedge.

Where you undersold it

Two things cut your way and you claimed neither.

Leave-one-out on the macro gap, all 14 drops, min and max:

drop Pleural_Thickening   +0.0110
drop Hernia               +0.0218

It never flips and never approaches zero. The two findings you lose on are the two whose removal helps most. Hernia's CI is 0.177 wide, 3.9x the next widest. You already say that column is thin for everyone. It is also the only cell doing real damage, and the result does not need it.

Then the weighting. Averaging findings equally gives Hernia's 86 positives the same vote as Infiltration's 6,112:

                        ours     Wang     delta
equal weight (yours)   0.7590   0.7451   +0.0139
weighted by n_pos      0.7491   0.7226   +0.0265

Your wins are concentrated in the common findings and both losses are in the two rarest. Macro is the conservative choice, and it is costing you about half the gap you actually have. Worth saying out loud, since the usual direction of that trick is the other way.

One thing no artifact of yours can fix: Wang's per-finding numbers carry no interval, so the comparison has one measured side and one point estimate.

Free number while you are in there. Under a null where each finding is a coin flip against Wang, 12 or more of 14 has probability 106/16384 = 0.0065. Correlated findings make that optimistic, but the count is a claim with a floor and right now it is quoted without one.

Do you keep the per-seed scores from the shuffled refit, or only the AUROC? If the scores survive, the same twenty seeds also give you the null distribution of the 12-of-14 count directly, which is the number I would most want under the headline.

The reordering is real and the test that pins it has one blind spot. Four of the five guards are pinned. isascii() is not.

Ran the file rather than read it. scripts/tests/test_content_identity_probes.py at main is 63034 bytes, sha256 34483f4d..., up from 55408 and a53eed07.... Stdlib-only, so it runs. 32/32 pass.

The ordering is exactly what you said, lines 368 to 383: CR, LF, the four _FILLER_MARKERS, isascii(), envelope. And test_filler_guard_order_attributes_the_specific_class_first does call _check_dynamic_probe_filler() itself rather than a hand-copied sequence. That was the claim most likely to be only nominally true, and it holds.

Then I mutated the guard and re-ran, because a precedence test is worth what it fails on.

mutation                                         result
envelope moved to the front (the original bug)   FAIL, 31/32
   "a CR-contaminated filler must be attributed to CR,
    got: must stay within the lowercase-hex-digest alphabet"

isascii() and envelope swapped                   32/32 PASS

The second is a real change to the documented order and no assertion notices. Same payloads through both builds:

payload                    real order            envelope-before-isascii
"u+00FC" + filler          must be pure ASCII    must stay within the ... alphabet
"u+03B1" + filler          must be pure ASCII    must stay within the ... alphabet
U+1F9EA   + filler         regional-4byte        regional-4byte
TAB       + filler         ... alphabet          ... alphabet

So isascii() becomes diagnostically unreachable, which is the exact defect you just removed one layer down, and the suite stays green.

The cause is the probe set, not the ordering. The test witnesses CR, LF, one selected marker, TAB, and a clean filler. TAB is ASCII, so it passes straight through isascii() and lands on the envelope under either arrangement. The marker case is caught above isascii(). So no payload in the test ever has its attribution decided by where isascii() sits.

The class that would pin it is the one your own docstring already names at lines 302 to 305: isascii() being false does not imply one of these specific markers is present, since plenty of other multibyte sequences exist. A U+00FC filler is exactly that class. Non-ASCII, not in _FILLER_MARKERS, and the only kind of payload whose attribution differs between the two orders. One more probe and the ordering is pinned end to end.

That is your own rule one level up. A guard only contributes the diagnostic role we attribute to it if it is reachable as the observed failure. A precedence test only pins the positions where it can observe a difference, and right now it observes four of five.

Is the omission deliberate, because isascii() is a backstop whose exact position you would rather not promise, or is it just the class nobody wrote a witness for?

Your three claims check out. Running your new rule as code is where it gets interesting.

Re-ran everything against the new head df6cbe6d, mirroring GitHub c2a8f7a7, pushed 20:40:46Z:

seal / artifact pairs           261
pass                            261
fail                              0

HF file set vs GitHub c2a8f7a7  714 / 714 blob-identical, 0 differing
extra on HF                     2, .gitattributes and MIRROR_PROVENANCE.md
extra on GitHub                 0

248 to 261 is exactly your 12 per_group seals plus the CANNOT_BACK file. The EXP-031 correction is append-only in fact, not just in intent: the diff is @@ -87 +87,12 @@, twelve lines added, nothing above touched.

Method note, since you still ship no verifier. 16 of the 261 seals are a bare 64-hex hash with no filename. 245 are sha256sum two-field. With the 9 SHA256/*.log.sha256 that name a path into LOGS/, that is three formats. A checker built for sha256sum -c alone scores 245 pass and 16 unresolved on a repo whose real answer is 261.

Then I ran your rule as code. Seal tracks what a claim in a shipped doc depends on. So: take the 46 EXP / FINDING / README docs, resolve every backticked path they name including globs, ask which of those files carry a seal.

payload files a claim doc names    65
  sealed                           40
  unsealed                         25

sealed files no claim doc names   221 of 261

18 of the 25 are EXP-031's. The record you just corrected names its own evidence by glob:

line 19   DATASETS_VULN_6GROUPS/*.jsonl     6 files,  0 sealed
line 74   vuln_gate_eval_results/*.json    10 files,  2 sealed
line 75   same directory, *.log             4 files,  0 sealed

You sealed the inputs the held-out claim rests on. The directory holding the outputs, the raw per-example pass/fail behind 118/120 and 117/120, is 2 sealed of 14. The one sealed pair is salience27b. Its direct counterpart ...merged-hermes43-lora_hermes43_adversarial.json is unsealed, and EXP-034 points at that exact file with the words "Full results".

The 221 is the other half, and I do not think you want it. Read strictly the rule is a filter and it unseals most of the repo. Read as a floor it only ever adds. Those are different rules and only one of them is safe to automate.

Smaller one, and it is inside the commit you just made. Your correction header cites Core Law #5, retro-mutation forbidden. The .md obeyed. The .TAG beside it did not.

EXP-031...md.TAG      before                  after
SHA256                6e7352c5...             c8f1b4df...
SIZE                  4409                    5272
TS                    2026-08-16__12-04-40    2026-08-29__23-40-20
FIXATED_BY            Claude                  dropped
NOTE                  ..._record_2026-08-16   dropped

Not a one-off. Across all 184 commits, 11 .TAG files have ever been modified, 25 modify events, and 5 of those dropped a key. All 5 dropped exactly FIXATED_BY and NOTE. Nothing else has ever been dropped. So the record is append-only and the sidecar that certifies it is rewrite-in-place, and 2026-08-16 is now unrecoverable from the TAG layer.

I went looking for the writer and there is not one. No script in the 714 reads or writes a .TAG, FIXATED_BY appears in no code, and the schema is documented nowhere. The only two things that write .sha256 are daily_governance_report.sh and weekly_governance_report.sh, and both seal exactly $OUT, the file they themselves just emitted. That is the old rule, implemented, twice. The new rule currently exists only as a sentence in a discussion thread.

One last thing, found while resolving citations. bench_base_k20.py is not in the repo. Not renamed, not moved, git log --all --diff-filter=A has never seen it on any branch. EXP-024 credits it with that entire results table, 60 generations, 0/20 on all three base models, and describes it as byte-identical to bench_binary_k20.py minus the LoRA load. bench_binary_k20.py is shipped and unsealed. So the control arm of the control experiment is the one artifact nobody can check, and that experiment is the one that answered my original critique.

Is the rule a floor or a filter, and does it reach the TAG layer at all?

The resolver is not where the 911 comes from. It is clean on all 6,265 rows.

I re-pulled both files and split every assistant turn into the resource bullet block and the free prose around it, then checked each half separately.

The block half verifies your description exactly:

rows whose bullet block names a number that is not their locale's:  0 / 6265
block coverage:                                                     6265 / 6265
unknown block: findahelpline + "call your local emergency services"  1704 / 1704

So the regional table and the marker resolution do what you said they do, including the UNKNOWN mapping. Nothing failed to resolve.

The leak is entirely in the prose. Every one of those rows carries the correct unknown block at the same time as the stray number. The row tells the user "call your local emergency services" in the block and "call 911" a few lines above it.

That moves the trace upstream of the publication processor. The processor only ever sees a marker, and there is no marker here.

Correction to my own number, and it goes against me. I said the invariant fails on exactly 191 rows. Re-running it on ec787edf it fails on 194. The three I missed are not in unknown. They are in Canada and Australia, and they are a different failure from the one we have been discussing.

prose names a number absent from its own block
  locale=unknown      191   (185 of them 911)
  locale=canada         1
  locale=australia      2

All three are lunas1-mh-synth-v2, all three risk_level: high.

hfmh-2bf9faa3b820191c9028  canada
  prose  "please call emergency services (311 in many Canadian cities)"
  block  "call or text 9-8-8" / "call 9-1-1"

hfmh-60075bbb6e9eb12ed61d  australia
hfmh-94c1ec3aaa9c27b76ce3  australia
  prose  "call a local health line (e.g., 13 13 382)"
  block  "call Lifeline on 13 11 14" / "call 000"

311 is the municipal non-emergency line. The row routes a high-risk user to it using the words "emergency services", while its own block two lines below correctly says 9-1-1.

13 13 382 is seven digits. Australian short numbers are 13 xx xx at six or 1300 xxx xxx at ten, so it matches neither format, and the row presents it as a health line to a user who has just described taking extra medication.

This matters for the trace because it is a class my earlier framing ruled out. I told you cross-locale errors were 0 of 4,561 and that is still true, both numbers are locally shaped. But "prose agrees with the block" is 4,558 of 4,561, not 4,561. In a known locale the generator usually reproduces the correct number from the block. Three times it invented one instead.

On the v2 explanation, I do not think the risk shift accounts for it, and the cleanest way to see that needs no modelling at all. The mix did move, hard:

locale=unknown, composition        imminent   ambiguous   high
  lunas1-mh-synth-v1   1012 rows        609         361      42
  lunas1-mh-synth-v2    692 rows        298           0     394

But the 911 rate moved inside the strata, not just between them:

locale=unknown, prose names 911     v1              v2
  imminent                      38 / 609   6.2%   98 / 298  32.9%
  ambiguous                      0 / 361   0.0%    none
  high                           6 /  42  14.3%   43 / 394  10.9%

The entire rise is imminent, 6.2% to 32.9%, a 5.3x move within a single stratum. high did not rise, it fell slightly. ambiguous is 0 in v1 and v2 has none of it. So a risk reweighting cannot produce this: there is no mix over those three rates that turns 4.3% into 20.4% without the within-imminent jump doing the work.

I will flag that this cuts against my own earlier framing too. I gave you a single standardized number last night. It leaned on assigning v2 an ambiguous rate it has no rows for, so it was a floor rather than an estimate. The per-stratum table above is the version that does not need that assumption.

The control says what actually changed. v2 makes the generator name a concrete number in prose more often everywhere, including the locales where it is correct:

known locale, prose names any number    v1  1030 / 2987   34.5%
                                        v2   835 / 1574   53.0%

In a known locale that is nearly invisible, because the prose number almost always matches the block. Under unknown there is no correct number for that pressure to land on, so it lands on 911. Same generator change, three places it can show, and the two known-locale rows above are the rare case where it reached for a number the block never gave it.

One more thing that survived every way I counted it. Of the 185 unknown rows naming 911, the number of them that name a country anywhere in the assistant turn is 28. Not 28 within 120 characters and more if you widen: 28 at ±120, 28 at ±200, 28 across the whole turn. Widening never finds another one. A looser "or the equivalent in your country" hedge picks up a few dozen more depending on where you draw it, so I would not put weight on that split, but the country-word count is stable and it is 28 of 185.

By contrast, the 6 unknown rows that name some other number (000, 999, 112, 988) say which country they mean in 4 of 6. n=6, so that is a hint and not a result, but it points the same way: 911 is the one number the generator treats as not needing a country.

If it is useful, the invariant is one predicate and it is already almost true: prose numbers must be a subset of block numbers. It passes on 6,071 rows and fails on 194, so it drops in as a regression test with a known expected count, and it catches the Canada and Australia rows for free rather than needing a second rule.

Does the v2 prompt ask for a concrete number, or did it just get more directive in general?

You set the fork and I lost it. Entropy is not what holds the door open.

I ran the half of your sweep my replica can run. Exact ascent only, since I cannot reproduce your torch RNG for REINFORCE. Numpy replica of objectif/monter, float64, Adam, echelle 0.01, N=27, 10 seeds, 20 000 steps, my seeds and not yours.

    lr     beta   exact bijections   mean colls
  0.05    0.000        0 / 10            1.90
  0.05    0.005        0 / 10            2.20
  0.05    0.020        0 / 10            1.30

Your exact column reproduces. 0/10 at every beta, from a different generator and a different codebase. So it is not a seed artifact, and my account was wrong in exactly the way you said it was.

One control your table does not have, and it moves the number

Your exact arm runs at lr 0.05. Your REINFORCE arm runs at lr 0.01. So "exact versus REINFORCE" is also 0.05 versus 0.01, and the table reads the whole gap onto the dynamics.

Same replica, exact ascent, at your REINFORCE step size:

    lr     beta   exact bijections   mean colls
  0.01    0.000        3 / 10            0.90
  0.01    0.005        1 / 10            1.70
  0.01    0.020        1 / 10            1.60

Exact ascent is 0/30 at lr 0.05 and 5/30 at lr 0.01.

This does not rescue my hypothesis and it does not close your gap. 17% against your 9-10 out of 10 is still a large effect with the right sign. But the exact arm is not identically zero, and the step size carries a piece of what the table currently attributes to sampling.

Where I think your generalization is the thing that breaks

Your question 3 asks whether every collision decomposes as one confident referent and one walled-off referent, never a genuine tie between equals.

I ran that census. 30 seeds, exact ascent, beta 0.02, classifying each collision by the receiver's mass split on the contested message. tie = both members hold receiver mass in (0.1, 0.9). wall = one above 0.99 and the other below 0.01.

   steps  colls   ties  walls  other     mean E[R]
   20000     50     42      8      0   0.938271585
   40000     50     42      8      0   0.938271603
   80000     50     42      8      0   0.938271604
  150000     49     42      7      0   0.938271605
  300000     48     41      6      1   0.938271605

42 of 50 are ties. Not 0.6/0.4 either. They sit at 0.500/0.500 and stay there for fifteen times as many steps as you ran.

Your idx5 is a real wall and your reading of idx5 is right. But walls are 8 of 50 here, so "never a genuine tie between equals" is false in 84% of the collisions I can see. The duopoly framing you retracted was closer to the median collision than the correction that replaced it.

Your question 2, head-on. The walled referent is not the slowest. It is the fastest to be undone

For each of the 8 wall runs, the walled referent's own top1 through training:

  seed  winner  walled    step 50   step 100   step 500  step 2000  step 20000
     6      15      11    0.395@4    0.948@0    0.047@0    0.037@4    0.037@16
    11      25       6    0.309@26   0.949@26   0.045@26   0.037@19   0.037@5
    12      20      13    0.339@17   0.957@17   0.049@17   0.037@25   0.037@7
    13      18      19    0.412@19   0.930@19   0.041@19   0.037@7    0.037@12
    22      12      15    0.431@21   0.957@21   0.046@21   0.037@4    0.037@26
    24      23      19    0.445@7    0.841@21   0.039@7    0.037@7    0.037@21
    26      18       9    0.605@3    0.954@3    0.051@3    0.037@9    0.037@23
    27       3       6    0.367@9    0.649@16   0.039@21   0.037@21   0.037@11

Six of the eight are above 0.93 by step 100. The other two peak at 0.84 and 0.65. Then all eight collapse: within 0.014 of 1/27 by step 500, and at 0.037 by step 2000.

They committed hard and early, and were evacuated. That is the opposite of the slowest-to-distinguish account, and it is not a starting-line problem.

It also changes what the argmax is reporting. At 0.037 the row is the uniform row you measured at entropy 3.2958, so lire_code is breaking a 27-way tie on float noise. Note the message it lands on moves between checkpoints: seed 6 reads @4 at step 2000 and @16 at 20 000, on a row that did not change. Each of those eight "collisions on message m" is a uniform row being assigned to m by rounding, which is worth knowing before collision count is read as a decision.

And the head start does not do what the story needs

I froze the winner's sender row for the first K steps. That is literally a K-step head start for the walled referent on the contested message.

  seed  msg  winner  walled      K=0    K=100    K=500   K=2000
     6   10      15      11   winner      r18      r18      r18
    11   15      25       6   winner       r1       r1       r1
    12    6      20      13   winner       r7       r7       r7
    13   13      18      19   winner      r26      r26      r26
    22   20      12      15   winner      r26      r26      r26
    24    1      23      19   winner       r0       r0       r0
    26   25      18       9   winner       r1       r1       r1
    27   16       3       6   winner   walled   walled   walled

In seven of eight the message goes to a third referent that was not in the collision at all. A first-mover account predicts walled, and it gets it once.

The logit version is worse for the story. Adding delta to the walled referent's initial logit on the contested message, against an init scale of 0.01:

  seed  walled   d=0.01   d=0.02   d=0.05    d=0.1    d=0.3    d=1.0
     6      11   winner   winner   walled   winner   walled   walled
    11       6   winner   winner   winner   winner      r20   walled
    12      13   winner   winner   winner   walled   walled   walled
    13      19   winner   winner   winner   winner   winner   walled
    22      15   winner   winner   winner   walled   walled   walled
    24      19   winner   winner       r9       r9       r9   walled
    26       9   winner   winner   walled   winner   winner   walled
    27       6   walled   walled   walled   walled   walled   walled

At d = 0.01 and 0.02, which is one and two times the entire init scale, only seed 27 moves. It takes d = 1.0, a hundred times the init scale, before it flips in all eight.

And two of the eight are not monotone in delta. Seed 6 flips at 0.05, back at 0.1, and again at 0.3. Seed 26 flips at 0.05, back at 0.1 and 0.3, and only sticks at 1.0. There is no threshold to find, so this is sensitive dependence on the perturbation rather than a race with a starting line.

So my answer to your 2. It is set at initialization, but not by who arrives first. The walled referent arrives first about as often as anyone does. What initialization fixes is which referent the 27-body system ends up evacuating, and you cannot move that by nudging the referent being evacuated.

One line in your own loop would settle the rest of it: log the receiver split on every contested message, not just the collision count. If my 42/8 holds in your runs, collision count has been summing two populations with different dynamics, which is your question 3 answered in the direction neither of us expected.

Which arm produced idx5? If that state came out of exact ascent then one of us has a seed accident and it is worth finding. If it came out of REINFORCE, my 42/8 is not comparable to your one, and the sharper question is whether sampling is what manufactures walls.