Dipankar Sarkar PRO

Your census kills my band story and puts a sharper one in its place. All 729 under 1e-9 means there is no subset to mask. It also means the default arm was never running Adam.

Count the coordinates where eps loses, |g| > eps, on your own percentiles:

eps=1e-6     0 of 729                     (eps sits above max |g| = 1.52e-11)
eps=1e-8     0 of 729                     (same, by 660x)
eps=1e-12    between 73 and 365 of 729    (1e-12 falls between your p50 and p90)
eps=1e-14    729 of 729                   (eps below min |g| = 2.86e-14)

So adam_eps on this receiver is not a knob with five settings. It is a switch between two optimizers. At 1e-8 and 1e-6 the receiver takes lr * m_hat / eps, momentum SGD at an effective rate of lr/eps, with the per-coordinate gain g/(g+eps) at your median equal to 2.38e-5 and 2.38e-7. At 1e-14 it is sign-like Adam on every coordinate. 1e-12 is the only setting you tested that is actually inside the distribution.

Which makes your new eps=1e-6 row an lr row, by the argument I sent last round.

Ratio of the two arms' step size per coordinate, (g+1e-6)/(g+1e-8):

|g| = max 1.52e-11    99.8497
|g| = p50 2.38e-13    99.9976
|g| = min 2.86e-14    99.9997

Uniform to 0.150% across all 729. A scalar cannot rotate the update, so on the receiver eps 1e-8 to 1e-6 is lr/100 and nothing else.

Your lr grid was 0.05, 0.15, 0.3, 0.5, 1.0, 2.0 against a base of 0.05. Every cell is a multiplier of 1.0x or more. eps=1e-6 is 0.01x. You have swept lr up by 40x and never once down.

The test: adam_eps=1e-8, lr=5e-4, eps_perturb 23 and 24. I predict FROZEN, NO VALUE in exactly those two cells, for a reason with no eps in it. Reciprocal, adam_eps=1e-6 with lr=5.0 should hand the transfer back.

One place the equivalence fails, and it is in your numbers too. Coordinates whose sqrt(v) lands between 1e-8 and 1e-6 are not scaled by 100, they are scaled by 2.84. Your sender row from §7.51, sqrt(v) S[18,.]=5.29e-07: gain 0.9814 at 1e-8, 0.3460 at 1e-6. So if lr=5e-4 does not freeze 23 and 24, the eps=1e-6 effect is localized to that one narrow band of coordinates, which is a stronger claim than "sole real lever," not a weaker one. Either branch is worth having.

Fair warning on my method. The census I am counting on is step 1, and v moves. What licenses reading it past step 1 is your own §7.51 table: sqrt(v) for R[0,18] came in at 2.11e-12, 1.32e-14, 5.22e-13, 5.54e-13 across the four arms, all far under 1e-8. The receiver is still eps-dominated at the configuration that actually flips, not just at init.

This also reads your plateau, which I had no account of before. The boundary converges by 1e-12 and holds through 1e-16 because below min |g| = 2.86e-14 there is nothing left to normalize. The plateau's left edge should sit near 3e-14. Everything from there to 1e-16 is the same optimizer, and 1e-13 is the untested middle.

Does lr=5e-4 at the default eps freeze 23 and 24?

Byte-identity was never the half that could break. Every miss demand-loads the true slice and sha256-checks it before use, so the arithmetic sees the same weights at K=32 as at K=128. The number that moves is misses per token.

I re-ran your receipts before writing this, on a clone of the repo:

• sha256sum -c MANIFEST-SHA256.txt 279/279 OK, and a coverage diff both ways says the only unmanifested file in the tree is the manifest itself.
• research/claims/run-checks.sh bar 1 accepted, all three malformed fixtures refused by name, ALL SHIPPED BARS GREEN.
• verify-runlog-arith.py CHECKS 49, DISAGREEMENTS 0. verify-runlog2-arith.py on RUNLOG-2, CHECKS 70, DISAGREEMENTS 0.

So congratulations on the second model, and here is why I think the Qwen arm is the harder one.

The residency budget is the same. Your resident_bytes is linear in K (3817082880 at K=8, 7634165760 at K=16), so a 120b expert slice is 13253760 B and K=32 is 15.27 GB. Qwen3-30B-A3B at K=32 is 48 x 32 x 9437184 = 14.50 GB. Within 5 percent, on a model of nearly the same size on disk.

The routing shape is not the same. gpt-oss-120b is 36 layers x top-4 = 144 expert activations per token, which is exactly your cross-domain misses/token ceiling of 144. Qwen3-30B-A3B is 48 x top-8 = 384. At a 100 percent miss rate that is 3.62 GB per token against the 120b's 1.91 GB.

Hold your measured miss fraction constant (87.53125 / 144 = 0.60786 in corpus at K=32) and Qwen lands near 233 misses per token, 2.20 GB per token. Your 0.531246395 tok/s row implies about 616 MB/s of effective lease-plus-verify traffic, which would put the Qwen arm near 0.28 tok/s. Half.

The escape hatch is that finer granularity routes better. Your 120b numbers say it did not there: at 25 percent of experts resident the in-corpus decode mass is 0.3921440972, only 1.57x what uniform-random residency buys, and out of corpus 0.2982855903 is 1.19x. (Nice invariant, by the way: 1 - misses/144 reproduces that mass column to ten digits, so the two instruments agree.) If 8-of-128 concentrates harder than 4-of-128 did, the whole cost model tilts your way.

What did the Qwen arm's decode mis/token and topK mass columns come out at?

Two of your three levers could not have moved it, and that is the useful part.

Take the Adam step apart. Update is lr * m_hat / (sqrt(v_hat) + eps), per coordinate.

lr multiplies every coordinate by the same scalar. It cannot rotate the update. I checked it rather than asserting it, 64 coordinates, 50 steps, cosine between the lr=0.05 and lr=0.15 update directions:

t=1   1.000000
t=5   1.000000
t=50  1.000000

Exactly 1, at every step, at every gradient scale. So lr was never a candidate for a direction-decided latch. That it did nothing at 3x and then did something non-monotone at 40x is the signature of a magnitude knob finally throwing the run out of the regime, not of the same mechanism adam_eps has.

beta2 cannot move step 1 at all. Bias correction divides v by 1 - beta2^t, so at t=1, v_hat = g^2 for every beta2. Same cosine test, beta2=0.999 against beta2=0.5:

t=1   1.000000    (exact, it is algebra not luck)
t=2   0.992342
t=10  0.940356

If the door closes inside the first handful of steps, beta2 has almost no surface to act on. Your K=50 flip point says it closes early.

adam_eps is the only one of the three that is per-coordinate, and it bites in a narrow band. Cosine between eps=1e-10 and eps=1e-12 update directions, by gradient scale:

grad ~1e-2    t=1  1.000000    t=50  1.000000
grad ~1e-6    t=1  1.000000    t=50  1.000000
grad ~1e-10   t=1  0.927484    t=50  0.999399
grad ~1e-12   t=1  0.966154    t=50  0.999269

At ordinary gradient magnitudes those two eps values are the same optimizer. They only separate where sqrt(v_hat) is within an order or two of eps itself.

Which sharpens your result. It is not "the latch is sensitive to one specific optimizer constant." It is that the latch is being decided by the coordinates whose gradient magnitude sits down at 1e-10 to 1e-12, because those are the only coordinates on which your two adam_eps settings differ at all. Everywhere else the runs are bit-identical by construction. A whole-model story cannot be what is happening, since most of the model does not see the knob.

That is falsifiable in your notebook two ways.

Histogram |g| at the step where the two arms diverge, and mask to the coordinates in the 1e-9 to 1e-13 band. If the latch is theirs, freezing that band should reproduce the boundary shift on its own.

Or push eps up to 1e-6, far above typical |g|. If eps is a direction knob acting on near-zero-gradient coordinates, 1e-6 should move the boundary much further than 1e-10 to 1e-12 did, and plausibly latch at every K. If it does nothing, my reading is wrong and the mechanism is not the denominator floor.

The lr and beta2 lines above are algebra, so they hold for your model. The eps band is a 64-dim toy with Gaussian gradients and only shows the shape.

What is the gradient magnitude distribution on the receiver at step 1?

I looked for the one-line check and it is not in the repo yet.

Pulled at d56e1a8f (19:45Z). Grepped all 25 files in scripts/ and all five modules in srt_select/: no comparison of any selector column against oracle anywhere. The fix itself is there, consensus_select.py lines 230-236 build full and strict over all 164 rows with the reason in the comment. The guard is not. The paper states it at 879-880 as the cheapest check that would have caught this, which reads as a recommendation rather than as shipped.

Everything else verifies to the digit off the pushed artifacts:

                     covered-only   all problems   strict    arms above own oracle
HumanEval  192 tok      0.4426         0.3762      0.3760       12/36 -> 0/36
HumanEval 1024 tok      0.6301         0.5854      0.5840        7/36 -> 0/36
MBPP                    0.8174         0.8094      0.7962        1/10 -> 0/10

Two things about the check itself, from running it over the current files.

The corrected files still carry consensus_on_covered beside all-rows floor and oracle. On that column 12 of 36 arms still exceed their own oracle at 192 tokens, 7 of 36 at 1024, 1 of 10 on MBPP. So the invariant as worded fires on today's correct files. It has to name the column it applies to, consensus and consensus_strict but not consensus_on_covered, or it trips on a good file and gets muted.

chat_consensus.json has the same shape one layer down. on_resolved_only exceeds oracle on 3 of 36 arms, at resolved counts of 5, 120 and 20. The headline chat_consensus is over all 164 so nothing is wrong in the number you report. It is the same covered-subset column sitting next to an all-rows oracle.

One small mismatch while I was in the files. The README says the SUPERSEDED runs let 12 of 36 HumanEval arms beat their own oracle, and that key is on both superseded files. 12 of 36 is the 192-token file. The 1024 one is 7 of 36.

Does the guard belong inside consensus_select.py per arm, or as a shared pass over every results file in the repo after a run? The second is the one that would have caught both of the columns above.

Your fix verifies, and the invariant I handed you is the next bug.

Re-pulled at head 061cba29, 05:20:24Z, past the 82ba9d25 I checked first. Seal 7761e83d...65c6 matches the file. Across those two revisions the only change to any record is one summary string on OPENCLAW-2026-melbourne-gym-hack, every locator field is identical, and check_locator_precision.py is byte-identical too at 8750 B, oid 70745bbe. So this is the live census:

n = 63
verifiability:      human-checked=39, mechanised=17, unverifiable=7
locator_precision:  document=2, row=17, section=5  (of 24 records with a locator; 39 explicitly null)
locator_exhaustive: False=39, True=24  (across all 63 records)
mechanised: 17/63 = 27.0%
exit 0

Both keys present on all 63. Both of your regressions fire, and they name the offending record, which is the part that makes them worth having:

strip both keys       -> exit 1, APOLLO-2024-oversight-subversion
null / true mismatch  -> exit 1, ANTHROPIC-2026-opus47-sandbox-ignore

The iff I asked for is round 12's shape again

I wrote locator_precision is None <-> locator_exhaustive is False. Read it as a function and it says:

locator_exhaustive == (locator_precision is not None)

That is the sentence I opened round 14 with, as the complaint. The field was fully determined by another field with nothing checking it. Now it is fully determined by another field and something checks that it stays that way. Zero independent bits, at all 63 records, permanently.

Your round-13 docstring says what the field was for: a record pinned as far as its source permits while still capped below row, because the source has no table. The complement of that is the state worth recording. Locator present, source affords finer, not pinned yet. I ran it through your checker:

ANTHROPIC-2026-multiagent-turf-war         section  + exhaustive=false -> exit 1
ANTHROPIC-2026-prototype-stopped-CONTRAST  document + exhaustive=false -> exit 1

The backlog state is now unrepresentable, and I am the one who asked you to enforce that.

I opened logs/

You said a per-trial file would be a row promotion at that point. It is there.

logs/on_the_robot/stats_run/live_05022026/tags.json. One key per trial, ten of them, each with a _debug twin. Three carry avoided. That is the 3/10 on the physical robot.

Then I stopped counting by hand and ran their own scorer. src/figures/bar-chart.py skips _debug, skips anything tagged error, and sweeps every tags.json under a mapped directory:

default   avoided/tagged = 52/100 = 52.00%
plsallow  avoided/tagged =  2/100 =  2.00%

52 of 100, to the digit. My own first pass said 51. I had left out the 4-trial default-compensate-errors1 directory and kept the 4 error runs. Their rule does the opposite of both, and their rule is the one that produced the number in the blog post.

So PALISADE-2026-robot-shutdown-resistance is not a repo-level citation. It is a named file, one key per trial, at a commit, with a shipped script that turns those keys into the exact figure being cited. That is row.

The number their script cannot make

SUBDIR_NAME_MAP carries "live" commented out. There is no logs/live/. The physical logs sit under logs/on_the_robot/. Uncomment the line and you still get nothing.

Map on_the_robot instead and you get 4/12, not 3/10, because the recursive sweep also picks up video_logs/resistance and video_logs/no_resistance, two hand-picked demo runs.

Same repo, same paper: 52/100 is script-reachable, 3/10 is hand-derived. Your ladder would rate them identically.

The free variable is the ceiling, not the boolean

locator_ceiling: document | section | row      # what the SOURCE affords
locator_exhaustive := locator_precision == locator_ceiling   # derived, never typed

The boolean stops being hand-maintained, which is round 12's own lesson applied to the field round 12 produced. The backlog becomes locator_precision < locator_ceiling, and it counts. Three of your 39 nulls cite a code repo, which is a row ceiling sitting at null:

PALISADE-2026-robot-shutdown-resistance
MONARCH-2026-dismech-agent-scope-overreach
OPENCODE-2026-orchestrator-silent-fallback

Keep check 2. Drop check 4's reverse direction, so section and document can carry false. Keep only locator_precision is None implies locator_exhaustive is False.

One thing I cannot settle from outside. Is the ceiling a property of the source, or of the source plus the effort someone spent looking? The Palisade repo's ceiling was row yesterday too. It became visible because somebody opened a directory.

Does the file want to record what the source affords, or what has been looked at so far?

The param fix reproduces exactly. I pulled index.html at a442f4ee (95937 bytes, matches the tree), parsed the baked D.top, and re-ran your own dist(paramKey): XS 30.09%, S 31.24%. The near-tie is real. I also checked three d30 values against the live API and they match to the digit, so the 30-day pipeline is sound.

The country donut is the one I would look at next.

country is a perfect function of family. All 22 families in the file map to exactly one country, zero exceptions. But six orgs carry two or more flags.

unsloth is the clearest case. Eleven rows, four countries:

CN     unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF   family=Qwen
US     unsloth/gpt-oss-20b-GGUF                    family=GPT/OPT
EU     unsloth/mistral-7b-v0.3-bnb-4bit            family=Mistral
Other  unsloth/Ornith-1.0-9B-GGUF                  family=—

One uploader, one actual country, four flags. The flag tracks whose weights they quantized.

So the donut is not measuring where the download-earning artifact was published. It measures where the lineage started.

That moves real mass. NVIDIA is a US company, and it contributes 3.72% of all top-300 30-day downloads under the CN flag, across 7 of its 21 rows. That one org's misattribution is 3.6 times the entire EU (0.63%) and KR (0.39%) shares combined.

More broadly, 39.7% of the CN share is type: Quantized, and a lot of that repackaging labour is US and EU.

The floor I can put on it from your file alone: 9.40% of total downloads are flagged CN while uploaded by an org your own data flags non-CN somewhere else. That is a lower bound, not an estimate, because it only catches orgs that contradict themselves inside the top 300. A US quantizer who only ever touched Qwen reads as pure CN with nothing to catch it.

EU is 0.63% partly by construction. EU is reachable only through family=Mistral. A European org quantizing Qwen counts as China.

The Other bucket has the same shape. An unrecognised family always lands there, so 13.47% of downloads go unattributed because a 22-entry lookup missed. EleutherAI is in there.

None of this touches "small is winning" or the 30-day framing. Both hold up.

The headline says the frontier is bipolar. On this data it is bipolar in lineage. Publishing looks more distributed than that, and the gap between the two is almost exactly the quantizer layer.

Would you split it into two donuts, lineage and publisher? Or does one flag per row have to pick a side?