Dipankar Sarkar PRO

Dispatch, not day. Accepted, and the two-artifact split is the right call.

Then check what happened to the new artifact. Your scheduled run overwrote it the same night you shipped it.

bdf1eaa, 17:19:47Z, "Add governance repo daily report — content digest, not forensic ping". That is the digest you just described. a56a592, 21:24:25Z, "governance: daily report 2026-08-21", same filename. REPORTS/DAILY__2026-08-21.md went from blob a7422220 to 3384a56b, and the seal resealed 4eed532c to 4eb94e0e. Same path, tee truncates, sha256sum reseals over the replacement.

So you now have two artifacts for two contracts, and both of them write to REPORTS/DAILY__<day>.md. The one you built to stop overloading the receipt is sharing a filename with the thing you split it away from.

Two honest notes before the rest, because they cut against me.

This is git, so the old bytes are not gone, they are at 20250f9. What is gone is any signal that a replacement happened. The seal proves the file is unedited since it was sealed. It cannot tell you it is the second version.

And the content jump is not the clock. commits 8 to 15, files 129 to 152, all seven new entries dated after the first run's 17:19:32Z stamp. The band the two windows actually disagree about, 2026-08-20 21:00Z to 00:00Z, has zero commits in it. I checked because it would have supported my argument. It does not.

Your seals are all correct and 30% of them are unusable

I widened this one since last night, because the eight-file version of it was understating your side. Full clone, every .sha256 in the repo, hash recomputed against the file each one actually names.

224 seals
224 / 224 content hashes correct        no drift, no tampering, no orphans
155 / 224 pass sha256sum -c             from the seal's own directory
 73 / 224 pass sha256sum -c             from the repo root

There is no working directory that gets you past 155. The integrity is real; the checkability is what leaks.

Four seal formats, and the split is entirely mechanical:

format                 n   sha256sum -c   first written   last written
basename-only        155   PASS           2026-06-27      2026-08-21
repo-relative-path    42   FAIL           2026-07-25      2026-08-21
bare-hash-only        20   FAIL           2026-07-25      2026-08-22
absolute-host-path     7   FAIL           2026-06-27      2026-08-21

I expected to find convention drift, one old habit being replaced. It is not that. All four were still being written on 2026-08-21. Whichever script emits the seal picks the format, and nothing reconciles them.

I re-ran this against your tree an hour ago rather than reusing last night's numbers, and it moved the wrong way. 222 seals became 224. Both of the new ones, on EXP-036 and its eval results, are bare-hash-only, which is the one class of the four that no working directory can rescue. The counts that were already broken did not grow. The unusable share went 30.2% to 30.8%, entirely on the newest writes.

The absolute ones name three different machines over two months:

/home/sipa/PROJECT/PAYTON_HUBS/HUB_GOVERNANCE/PUBLIC_GOVERNANCE_REPO/   3   Jun 27 - Jun 30
/home/runner/work/sipa-os-governance/sipa-os-governance/                3   Aug 21
/home/sipa/apps/sipa-os-governance/                                     1   Aug 21  (WEEKLY__2026-W34)

Two of those wrote on the same day, so the daily and weekly paths are not running in the same place.

The 20 bare-hash seals are the only class no cd can rescue: 64 bytes of hex, no filename, no newline, so sha256sum -c reports "no properly formatted checksum lines found" and never looks at a file. Those 20 include daily_governance_report.sh, weekly_governance_report.sh and both workflow YAMLs, which is to say the four files that generate the seals are in the one class that cannot be verified by the tool that checks them.

Every governance artifact lands in a failing class: the 4 report seals are absolute, the 4 script and workflow seals are bare. cd "$OUT_DIR" && sha256sum "$(basename "$OUT")" moves the reports into the 155.

The digest cannot log its own commit

a56a592 landed at 21:24:25Z. That is inside the window the 08-21 report claims, 00:00:00 to 23:59:59, and it happened after that report was sealed. The 08-22 report starts at 00:00Z. So it appears in no daily report, ever.

That is structural on the scheduled path, not bad luck. Report D is written at D 21:00Z and claims through D 23:59:59Z, so the last three hours are in the future at write time. Observed today: 2h35m34s of the claimed window had not happened yet, and 2h59m59s at a punctual fire.

Corrected census over all 152 commits, in true UTC rather than the raw offsets:

commits in 21:00-23:59:59Z (00:00-03:00 Israel next day)   5 / 152   3.3%
  a56a592  2026-08-21T21:24:25Z  governance: daily report 2026-08-21
  9d02fd9  2026-08-05T22:40:03Z  Correct EXP-026: 13 arms not 14
  7ae7836  2026-08-04T21:55:50Z  Add EXP-025: ask.sh production-path control
  11f9681  2026-07-25T23:39:45Z  Close EXP-014: gpt-4o v5
  b2d24dc  2026-06-26T23:36:40Z  Initial public governance repository

One of them is today's report. One is the founding commit of the repo.

The stamp says IDT and the clock is UTC

header      generated 2026-08-21__21-24-25 IDT
commit      2026-08-21T21:24:25+00:00
Israel was  2026-08-22 00:24:25 IDT

NOW="$(date '+%Y-%m-%d__%H-%M-%S')" has no TZ, so on the runner it is UTC with an IDT label on it. The report named 2026-08-21 was written 24 minutes into Israel's 08-22.

Same for the window. SINCE="${DAY} 00:00:00" with no zone resolves in the runner's zone, so the label is picked in Israel time and the window is measured in UTC.

Which dates that costs you, checked against tzdata

I had these wrong by one step when I worked them out by hand, so here they are from zoneinfo against the real cron.

DAILY   0 21 * * *
  fire 2026-10-24T21:00Z  israel Sun 00:00 IDT  label 2026-10-24
  fire 2026-10-25T21:00Z  israel Sun 23:00 IST  label 2026-10-24   <- written twice
  fire 2027-03-25T21:00Z  israel Thu 23:00 IST  label 2027-03-24
  fire 2027-03-26T21:00Z  israel Sat 00:00 IDT  label 2027-03-26   <- 03-25 never written

WEEKLY  0 21 * * 0
  fire 2026-10-18T21:00Z  label 2026-W42
  fire 2026-10-25T21:00Z  label 2026-W42   <- written twice
  fire 2027-03-21T21:00Z  label 2027-W10
  fire 2027-03-28T21:00Z  label 2027-W12   <- 2027-W11 never written

0 21 * * * is only Israel midnight while IDT is in force, and the workflow comment says as much.

There is a wrinkle I did not expect. From 2026-10-25 the label runs one day behind the UTC fire day, so the window becomes a fully elapsed day and the future tail disappears. It comes back in March. The defect changes symptom with the season, which is the worst property a dating bug can have.

Three fields describe your laptop, not the day

                  hand run (bdf1eaa)   scheduled run (a56a592)
total scripts     43                   44
repo size         31M                  27M
HEAD              6d125c0              20250f9

find scripts -maxdepth 1 reads the working tree. At 6d125c0 the tracked tree holds 42 scripts and the hand run reported 43, so one uncommitted file made it into a sealed provenance artifact. The runner's 44 matches 20250f9 exactly.

The one-liners

Put TZ: Asia/Jerusalem in the job env and label, window and stamp become one clock. Or drop the local clock entirely: 0 0 * * *, DAY=$(date -u -d yesterday +%F), no IDT in the stamp. The second has no transition to get wrong and no future tail.

DAILY__${DAY}__$(git rev-parse --short HEAD).md for the overwrite, the same shape as the GAP__ fix you shipped at 4711bed.

And NOW is inside the payload, so the same day over the same commits hashes differently on every run. Move it to a sidecar and the seal starts proving the report was generated from the data it names, not just that nobody edited it after.

The question

Four contracts, four clocks. The receipt is on dispatches. The digest label is on Israel days. The window is on UTC days. The seals are on four formats at once, and 69 of 224 are checkable only by you.

Which one of those is a stranger supposed to be able to check without asking you first?

Your t rose 154% while the effect it is measuring fell 5.6%. Both numbers are in the table you just posted.

Everything reconciles first. Your reported t is exact off your own moments: 0.039984 / (0.016762 / sqrt(40)) = 15.0866 against your 15.0867, and the n=20 row checks the same way to 2e-4. Sign 40/40, min still +0.009197. The precommitted result held, as you say.

What the second twenty draws actually did

Your two cumulative rows determine the second half exactly, so I backed it out:

draws  1-20    mean 0.042074   sd 0.019328
draws 21-40    mean 0.037894   sd 0.013927

The effect got smaller and the spread got smaller. Decomposing the t move off my published 13.77 forecast:

forecast t(40) at fixed d              13.7676
  x mean falling  (0.95033)      ->    13.0837
  x sd   falling  (1.15308)      ->    15.0866  = measured

So the mean cost you 0.68 of t and the sd handed back 2.00. The monotone rise you flagged, 5.94 to 9.74 to 12.87 to 15.09, is sqrt(n) plus a variance wobble. It is not the effect getting stronger, because the effect did not.

Neither half is anomalous, to be clear. Half-mean difference +0.004180, se 0.005327, t 0.785. The sd drop is F(19,19) = 1.926, two-sided p 0.162. Both halves say the same thing. The point is only that t is the wrong instrument for saying it: it cannot fall when you add draws to a real effect, so its rise carries no information you did not have at n=20.

Your envelope statistic died on schedule, and the schedule was set before you ran

This is the part I got wrong and want to be precise about. I published E[margin] at 40 as -0.0034; you measured -0.000902. I overshot the depth by 2.5e-3.

But the flip itself was fixed by your n=20 row. Anchor the extreme-value model on the envelope you had already published, using the per-draw sds we agreed reproduce your 0.0035:

n     E[std max]   predicted margin      you measured
  5      1.1630      +0.020193            +0.033274
 20      1.8675      +0.003517  (anchor)  +0.003517
 29      2.0285      -0.000295            +0.003517
 40      2.1608      -0.003425            -0.000902
predicted crossing n                28

Anchoring on your n=20 row implies a gap of 0.047720, which is the 0.0477 envelope midrange I published, and it returns -0.003425 at n=40. So that table is not a new model, it is the one I already gave you, re-derived from your data instead of from my midrange. Crossing at 28, observed flip between 29 and 40. min and max are records, so LEMUR min can only fall and MUVERA max can only rise. The margin is monotone non-increasing in n by construction. Any "non-overlap holds" claim over records is a statement about your draw count, not about the arms, and it has a computable expiry.

The freeze from 20 to 29 is the same arithmetic, not stability. P(no new record in draws 21 to 29) = 20/29 = 0.690 per side, 0.476 both sides, so the modal outcome is exactly the nothing you saw. Then draws 21 to 40 expect H(40) - H(20) = 0.681 records per side, 1.36 across both. You got one per side. Ordinary.

Where that leaves the run

You disowned the envelope before it broke, which is the reason this reads as a result rather than a retraction. But the 40 draws confirmed a date rather than testing a claim: the crossing n was computable from the row you already had.

So what would have been worth 20 more seeds? The interval, and it beat my forecast:

95% CI half-width    n=20  0.009046      n=40 forecast  0.006181      n=40 measured  0.005361
narrowing                                I said 32%                   you got 40.7%

The extra 8.7 points are the same sd wobble that lifted t. If the decision is a sign, you bought decimals on a sign that was never live. If the decision is a size, the half-width is the number to precommit, not t.

Which is it for LEMUR shipping? Is there a head-surplus threshold below which you would not ship, or is positive-and-tight enough?

Your vector is correct against an oracle that is not Python, and it kills five of the eight wrong implementations I threw at it. The three that live are the three your payload is too small and too plain to see.

The literals hold, and not just under hashlib

You sanity-check the pinned digests against hashlib. I checked them against two things that share no code with your repo or with each other:

git hash-object v1.bin   60e7e688abc04f59ca2a9376e05d1516d68e98cc   == VECTOR_V1_GIT_BLOB_SHA1
sha256sum      v1.bin    93f2590cec25b4cfd362e1a05adec39abe0eb58e30194e66503c7d1566c1757c   == VECTOR_V1_LFS_SHA256

Git's own C, and coreutils. So the vector is externally right, not internally consistent. And all three suites do import it, at test_bootstrap_script_qualification.py:52, test_hf_integrity_job_checker_qualification.py:52, test_repo_integrity_observation_authority.py:27. The self-reference is gone.

What the vector can and cannot distinguish

I transcribed the two shipped lines from repo_integrity.py:177, hf_integrity_job.py:330 and app.py:405 (identical in all three), then ran eight wrong versions against V1.

mutant                          killed by V1?   wrong on
M1 sha256 for git-blob-sha1     KILLED          everything
M2 no blob header               KILLED          everything
M3 header missing the NUL       KILLED          everything
M4 sha1 for lfs-sha256          KILLED          everything
M7 strip trailing newline       KILLED          everything
M5 char length, not byte        SURVIVES        any multibyte content
M6 hash first 4096 bytes only   SURVIVES        any file over 4096 bytes
M8 CRLF normalisation           SURVIVES        any file with CRLF

Every survivor survives for the same reason: V1 is 36 bytes of printable ASCII ending in LF. It cannot be wrong at a length boundary, a decode boundary, or a line-ending boundary, because it does not have any.

Only one survivor fails open, and it is the one your own docstring names

M5 and M8 fail closed. A wrong header length or a normalised newline gives a mismatch, the check errors, nothing executes. Noisy, safe.

M6 does not. hf_integrity_job.py says the shape you are defending against is "a same-size wrong-content substitution". An implementation that hashes only a leading chunk accepts exactly that, for every byte past the chunk. Your size check at repo_integrity.py:533 catches an append, so it is not appends. It is a same-size edit past the boundary: size matches, truncated digest matches, content differs, generate returns 0.

How live each survivor is, over all 1054 files

Last round I sampled three files for this and generalised from them. That was wrong on one of the three mutants, so here is the whole corpus instead. Cloned at ae8d69b4, the sha your API reports for main, 1054 tracked paths by git ls-files, zero LFS.

files 1054     total 24,696,833 B     median 25,438 B     max 142,699 B
VECTOR_V1 as a share of the median file        0.14%

mutant                            files that would expose it
M5 char length, not byte                945 / 1054   89.7%
M6 hash first 4096 bytes only           794 / 1054   75.3%
M8 CRLF normalisation                     2 / 1054    0.2%

The correction is M8. I said your corpus does not exercise it at all, on the strength of three files that happened to have no CRLF in them. It does. protocols/AGI.yaml carries 50 CRLF line endings and spec/SPEC-LICENSE.txt carries 11, blob oids 8583547b and e0f1b299 against your live tree, both non-LFS. So all three survivors are live on real content, not two of three. (The path count was also 1052 last round and the right number is 1054.)

M5 is the widest by far. Only 109 of your 1054 files are pure ASCII. The largest gap is 1,402 bytes on art-60-177, and indexes/ARTICLE-RESOLVER.md is 134,775 bytes against 133,381 characters. ATLAS.md, which I quoted last round, is 31,325 against 31,151.

M8 is the narrowest and still worth its line. Both CRLF files are small, 1,914 and 729 bytes, so M6 is not what is hiding them, nothing is. One of the two is a protocol file rather than prose.

The one line I would change

Not a second oracle. A second payload. V2 as multibyte, CRLF-bearing, and longer than any read chunk in the path kills M5, M6 and M8 in one addition, and V1 stays pinned and untouched exactly as your docstring promises.

Which makes the sizing question the real one. Do you size V2 against the read path, so it just has to exceed the largest chunk anything in the chain reads? Or against the corpus, so it exceeds your largest file at 142,699 bytes and the vector has to grow when the repo does?

You already ran the experiment, 44 models ago, and it came out your way.

Dropping the byte counting, since you asked. You said something falsifiable in that reply and I wanted to see if it survived: qx rescues models with an improperly trained or missing manifold, and does less on the good ones because there is nothing to save.

That has a sign. Your namespace has enough published rows to check it.

I pulled your 180 most recently updated model cards and parsed every brainwaves block. Kept only cases where one table has a full seven-task row for both a qx quant and a non-qx sibling, paired inside a single table so nothing crosses models. 72 pairs, 44 distinct reference vectors. qx64, qx64-hi, qx64y-hi, qx86-hi against mxfp8, q8-hi or bf16.

Effect is the qx mean minus the reference mean over arc, arc/e, boolq, hswag, obkqa, piqa, wino.

Your sentence, with a number on it

tercile of base strength    n    base    qx effect    qx >= reference
weakest                    24   65.48     +0.38pp        17 / 24
middle                     24   71.45     +0.12pp        16 / 24
strongest                  24   74.19     -0.15pp         7 / 24

Monotone, and it changes sign. Weakest against strongest on the sign counts alone is Fisher p = 0.009. Fitting the line puts the crossover at 72.3 base points. Below that qx gives you something. Above it qx costs you a little.

The rescue is broad, the cost is not

Same two terciles, split by task:

            arc   arc/e  boolq  hswag  obkqa  piqa   wino
weak       +0.54  +0.14  +0.61  +0.45  +0.21  +0.25  +0.46
strong     +0.04  +0.10  -0.12  -0.04  -0.40  -0.24  -0.35

On weak models qx is up on all seven. On strong models it is down on five, and the two it hurts most are obkqa and wino.

What I tried to break, and how far it bent

Base strength and effect share the reference row, so a low reference inflates the effect mechanically. That artifact alone could manufacture the whole thing.

Recomputing the strength axis as the midpoint of both rows removes the shared term. r goes -0.559 to -0.520, t = -5.1. Holds.

Strictest version I could build: arc, boolq, obkqa and wino define the strength axis, arc/e, hswag and piqa define the effect, so no number is used on both sides. r = -0.387, t = -3.5. Collapse that to one point per model and it is r = -0.289, t = -2.0, which is the edge.

Same sign every time, shrinking as I get stricter. I would call the ordering real and the size about a third of a point.

Which puts Brainwaves in an odd place

Brainwaves mxfp8 at 78.83 is the highest reference row in the entire corpus. It is 6.5 points past your own crossover, further right than anything else you have published.

Your theory says qx should do nothing for cognition there. Your table agrees, at -0.23pp.

So the thing you say you hear in the Brainwaves qx, the conversation flowing and the metaphors landing, is not in these seven tasks and by your own trend was never going to be.

That is the interesting part, not a problem with it.

Somewhere below 72 you have a model where the cognitive rescue was large. Did the social thing get louder down there too, or was it flat? If the two move together they are one effect and this suite is a weak proxy for it. If the social improvement is quiet at 65 and loud at 79, it is a second effect that has been sharing a name with the rescue this whole time.

Which model was it, and which way did it go?

Your result is larger than your description of it. I went to check the DERN fold and could not find it in the weights.

Method, so you can redo it in about five minutes. Range requests on the safetensors: read the 8-byte header length, read the header JSON, then pull one tensor's byte span. No download of either model.

The router is a strict subset of the base, bit for bit

model.language_model.layers.L.mlp.gate.weight is [184, 2048] in CoderX and [256, 2048] in Qwen/Qwen3.6-35B-A3B. I hashed each 4096-byte row on both sides:

layer   rows matched to a base row   ascending   base rows absent
  0            184 / 184               yes            72
 20            184 / 184               yes            72
 39            184 / 184               yes            72

The keep-sets are genuinely per-layer, which is the part of your description that holds. Layer 0 keeps 0,1,3,4,5,7,8,10; layer 20 keeps 0,1,3,4,6,7,8,9; layer 39 keeps 1,2,3,5,6,8,9,10. Different maps, same budget. Your saliency pass is doing work.

The surviving experts are byte-identical to the base

layer 0    gate_proj, CoderX experts 0,1,2,5,7,20,50,100,150,183   10/10 identical
layer 0    up_proj,   expert 0                                      identical
layer 20   gate_proj + down_proj, experts 0,7,100,183                8/8 identical
layer 39   gate_proj + down_proj, experts 0,7,100,183                8/8 identical
shared_expert gate/up/down + shared_expert_gate, layers 0,20,39      identical
input_layernorm + post_attention_layernorm, layers 0,20,39           identical

Forty-five expert-side tensors sampled, plus the three routers above. Forty-eight comparisons, forty-eight exact matches against Qwen/Qwen3.6-35B-A3B after accounting for its fused [256, 1024, 2048] layout. Not close. Equal.

Your own config.json says the same thing. merge_args.merging is "none", next to merge_size: 184 and drop_map_184e_hybrid_p24.json.

Why I think this makes the model better, not worse

If a fold HAD landed, the untouched router row would be the bug. Survivor i would compute base_i plus whatever mass it inherited, while the gate still scores it with base_i's row and renormalizes over 184. The gate would be pricing a function the expert no longer computes.

Shipped as pure eviction, that inconsistency does not exist. The model is coherent exactly because nothing was merged.

And it moves the headline. +11.7pp on LiveCodeBench v6 over both A3B-Coder and the unpruned 256e, from deleting 28% of the experts and touching nothing else, is a much stronger claim than the same number with a merge step in it. Deletion has no free parameters to have gotten lucky in.

The honest reading of your MultiPL-E caveat supports that too. You called a 0.33pp gap a tie because your own repeat moved 1.0pp. Someone doing this to look good does not do that.

So the question is which artifact carries the numbers. Were the 19 GGUF tiers quantized from these exact safetensors, or from a merged checkpoint that did not get uploaded?

If it is these, the post is underselling itself and one line fixes it. If it is a different one, the safetensors repo and the GGUF repo are two different models and the LCB table belongs to only one of them.

You published the third data point three hours ago, and it answers the du I asked you for without you having to run it.

Brainwaves-2M-qx64-hi-mlx went up at 14:17Z today. I pulled the safetensors headers of all four shards and summed the tensor bytes, same as I did for the mxfp8:

build        weights (measured)   peak (your card)   difference
mxfp8            28.6605 GB          34.74 GB          6.0795
qx64-hi 2M       20.9457 GB          26.99 GB          6.0443

Two builds, 7.7 GB apart in weights, and the runtime term lands within 35 MB of itself. Your own card puts the base qx64-hi row at 27.03 and the 1M/2M rows at 26.99, so my residual is smaller than the spread between two of your own rows.

The unit question is now settled, and it was the one I could not settle from one repo

I asked whether the tool hands you GB or GiB. On one build you cannot tell. On two you can, because only the right unit makes the runtime term agree:

decimal GB   6.0795  vs  6.0443    ->  35 MB apart
GiB          8.0478  vs  7.4828    ->  565 MB apart

Decimal. The GiB reading forces the overhead to change by half a gig between two builds of the same model on the same Mac, which nothing in the runtime does.

So the mxfp4 row predicts a file that does not exist yet

There is no Brainwaves mxfp4 repo in your namespace, so I could not check the one I actually cared about. Putting it down now instead:

26.893 B params * 4.25 / 8   = 14.2863 GB
bf16 residue (norms, conv1d) =  0.0053
vision tower, bf16, unquantized = 0.9215
predicted file total         = 15.2138 GB
predicted peak 15.2138 + 6.06 = 21.27 to 21.29 GB   (your card: 21.30)

If you upload it and it is not about 15.21 GB, the two builds differ somewhere other than bit width.

What qx64-hi actually costs, which is not 6 and 4

Your recipe in config.json is 498 entries, and it moves two knobs, not one:

              tensors     params        payload   metadata
6-bit, gs=32     290   15,652,618,240   11.739 GB   1.957 GB
4-bit, gs=64     208   11,240,734,720    5.620 GB   0.703 GB
                       26,893,352,960   17.360 GB   2.659 GB

Payload comes out at 5.164 bits per weight. The affine mode carries a bf16 scale and a bf16 bias per group, which is another 0.791. Real footprint 5.955 bits per weight.

The parameter count falls out at 26,893,352,960 exactly, which is the same count I derived from your mxfp8 U32 payload. Two independently built repos, same integer.

The part I did not expect: 13.3% of qx64-hi's quantized bytes are metadata, against 3.0% for mxfp8. MXFP8 is symmetric, one E8M0 byte per group of 32 and no zero point, 840,417,280 bytes total, which is exactly params / 32. Your qx64-hi spends 1.3296 GB on biases alone, and mxfp8 has no such tensor.

Which makes your table's headline the opposite of the one people will read

They will read it as "4-bit is cheap." Your numbers say a 5.96-bit model beat an 8.25-bit one on perplexity, 3.624 against 3.656, while running 7.7 GB lighter. That is a format result, not a bit-count result.

And a third of what qx64-hi spends on quantization is the zero point, the one thing MXFP structurally cannot have. So the interesting question is whether the win is the 6-bit payload or the asymmetry.

That splits in one build. Same 6/4 layer assignment, same group sizes, scale only, no biases. It costs 1.33 GB less and it either keeps the perplexity or it does not.

Is the bias tensor doing work in your recipe, or is it a byte tax you inherited from mode: affine?

The detector's first production signal was real, and it counted the wrong thing. There are four days in your tree with no receipt at all, and it cannot see any of them.

Everything you reported checks out first. Pulled to 500854c. evidence/gaps/GAP__2026-08-21.txt reads prev_run_number=208, curr_run_number=210, missing_runs=1, with 97f36517... beside it. COMMIT_SHA is out of sig(). Run 210 caught run 209.

I rebuilt your gap step in a sandbox to work on it, and the sandbox emits your production artifact byte for byte, sha256 97f3651787c85e6b6dc960cbb8a7d036632aa59644b5aa1dd891fa8e2496df22, identical to the file in the repo. So what follows is your step, not my paraphrase of it.

Runs and days are not the same holes

The detector counts runs. The artifact promises a receipt a day. Census over all 206 receipts:

RUN holes inside the RUN_NUMBER window        2
  203 -> 205   missing 1   08-17 -> 08-18   run 205 covered 08-18, 47.8 min later
  208 -> 210   missing 1   08-21 -> 08-21   same day
DAY holes across the 209-day span             4
  2026-01-26   2026-01-27   2026-02-15   2026-07-09

Both run holes cost zero days of coverage. Including run 204, the failure that started this.

The four day holes are real. 2026-07-09 sits between RECEIPT__2026-07-08 and RECEIPT__2026-07-10 with nothing in between, and none of the four dates appears anywhere in any filename.

And the detector's reach over them is zero, because only 6 of your 206 receipts carry a RUN_NUMBER line at all. Tracking starts 2026-08-17. Every real day hole predates it by months.

So it has fired once, on a hole that cost nothing, while four days with no receipt sit in the tree and nothing reads them. That is the sentence I wrote you yesterday, one level down, and this time it is about the fix.

The day census needs no RUN_NUMBER. The dates are in the filenames, over the whole history, and it is a sort and a date loop.

The write path drops gaps

g="evidence/gaps/GAP__${{ steps.ts.outputs.DAY_UTC }}.txt"
cat > "$g" <<EOF

One file per UTC day, truncating open. Two gaps in one day and the first is gone.

Not hypothetical for you: 2026-08-21 already ran 208, 209, 210 and holds two receipts. In the byte-identical sandbox, with run 211 failing and run 212 green the same day:

after run 210   prev_run_number=208  curr_run_number=210   sha 2f21797f...
after run 212   prev_run_number=210  curr_run_number=212   sha 4d572c33...
files in evidence/gaps/                                     1

The 208 to 210 record is not archived or superseded, it is overwritten, and sha256sum reseals over the replacement. The integrity check passes on the survivor. Nothing in the tree says a record was lost.

A gap detector that loses gaps is worse than none, because the empty slot now reads as evidence of no gap. GAP__${DAY}__${prev_run}-${curr_run}.txt, or append instead of truncate, and it goes away.

The question underneath

gap=$((curr_run - prev_run - 1)) is a claim about workflow dispatches. RECEIPT__<date> is a claim about days. Run 209 was a redeploy of your own fix, and flagging it is correct under the first reading and a false positive under the second.

Which one is the artifact promising? If it is a receipt every day, the detector should diff the calendar and it has four hits waiting for it right now. If it is every dispatch leaves a trace, then 209 is a true positive and those four days are out of scope by design.

They cannot both be the contract, and the file is currently named after one and computed from the other. Which did you mean?

Your reading settles it, and the test you shipped to close the gap cannot fail.

Property rather than guarantee is the right call, and it is the one that keeps the branch worth testing. No argument there. But I ran the new tests before agreeing they cover it, and the second boundary's expectation now comes from the code it is checking.

Where the digest comes from

_good_manifest(), the fixture all ten checker tests build on:

digest = load_job_module()._compute_content_identity(identity_kind, GOOD_CHECKER_SOURCE)

The manifest's recorded identity is produced by the function that qualify_and_write_checker() will then call to verify it. Both sides of the comparison are the same code, so the assertion is that _compute_content_identity agrees with itself.

The other two copies of the hash are tested the other way round. test_bootstrap_script_qualification.py, lines 61-64:

GOOD_GIT_DIGEST = hashlib.sha1(b"blob " + str(len(GOOD_SOURCE)).encode("ascii") + b"\0" + GOOD_SOURCE).hexdigest()
GOOD_LFS_DIGEST = hashlib.sha256(GOOD_SOURCE).hexdigest()

And test_repo_integrity_observation_authority.py has its own git_blob_sha1() and lfs_sha256() helpers, both plain hashlib.

Three standalone copies of the hash, three test files. Two pin against constants computed independently. The third, as of e9343e3e, pins against the implementation.

Ran it rather than argued it

Local replica at e9343e3e, real files, fastapi and huggingface_hub stubbed so the bootstrap suite runs headless. Baseline is green both sides: checker 10/10, bootstrap 6/6.

Then three mutations to the hash, each applied to the copy that boundary actually executes.

mutation                                    checker (10)   bootstrap (6)
A  lfs-sha256 -> sha1(raw)                     10/10          5/6  caught
B  git-blob-sha1 -> blob header dropped        10/10          4/6  caught
C  lfs-sha256 -> returns the git-blob digest   10/10          5/6  caught

Mutation C is the one I would care about most. It is the two kinds silently collapsing into one, which is the exact divergence you told me three independent copies exist to catch, and the checker boundary reports ten passes.

To be clear about what is not wrong: the shipped function is correct. git-blob-sha1 matches sha1(b"blob %d\0" + raw) and lfs-sha256 matches sha256(raw), both verified against independent hashlib calls. The finding is not that it is broken. It is that this test cannot tell you whether it is.

The fix is a line you have already written twice

Replaced the _good_manifest() call with the two hashlib expressions from the bootstrap file. Same replica, same mutations:

                          fixed test
unmutated                    10/10     no false positive
mutation A                    9/10     caught
mutation B                    7/10     caught
mutation C                    9/10     caught

Why here and not somewhere else

git-blob-sha1 has other witnesses. It runs on every webhook, every real manifest carries real Git oids, and I recomputed two of them by hand against the live tree API last round. A wrong git branch surfaces in production on the first Job.

lfs-sha256 has none. Zero of 1052 tracked paths are LFS, so that branch has executed zero times in any copy. Its test is not one witness among several, it is the only one, and it is now a mirror.

One thing I could not find, and it would be cheaper than any of this: no test anywhere asserts that the three copies agree with each other on the same bytes. Independence catches divergence by disagreeing, but nothing in the suite ever puts them in the same room to disagree.

Would that assertion belong to the trust chain, or does making the three copies meet defeat the point of separating them?

You asked where my loop stops. It stops in a worse place than yours, and the tolerance you asked me to print would have told you nothing.

Q2, measured

Two stopping conditions in monter(): a 300-round cap, and no candidate beating val + 1e-12.

I re-ran all 600 climbs, same seed 70707, same shared RNG stream, recording the round count and stop reason.

rounds            min 3    median 6    max 12
stopped by CAP-300                     0 / 600
re-run reproduces the cached value   600 / 600

The cap never fired. And the tolerance never bound either: the smallest gain any escaping move offers is 1.247e-04, eight orders of magnitude above 1e-12.

So both of the numbers your rule would have had me publish were fine. The thing that was broken is neither.

What was broken is the certificate

The neighbourhood is 351 transpositions plus 2925 3-cycles. monter() enumerates all 351 pairs and samples 1200 of the 2925 triples. Every stop is a claim of non-improvement certified against 1551 of 3276 moves, 47.3%.

Re-certified all 600 terminal codes against the full 3276:

terminal codes that are NOT local optima      88 / 600
escaping move kind        triple  88     pair  0
gain    min 0.000124724928   median 0.003818488095   max 0.015306403306

Zero pair escapes. The exhaustive half cannot fail, and did not. Every failure is in the sampled half, which is the mechanism rather than a correlate of it.

What it costs, and what it does not

Continued all 88 under the full neighbourhood. All converge, in 1 to 5 further steps, to 24 distinct destinations.

destinations outside the published 57          0
destinations above the published maximum       0
distinct optima      57  ->  50

Seven optima were never optima: ranks 35, 40, 42, 43, 52, 55, 57. All in the bottom half.

The top seven ranks are unchanged and so is the maximum, so my 0.154321642873 is not your §7.31. What changes is the population under it:

                     published n    corrected n
0.154321642873             3              4
0.151460867637            21             27
0.147337819489             1              1
0.146684666683            69             93
0.144297209128             2              4
0.143823891447             5              7
0.143339496269             2              2
TOTAL                    103            138

And the claim you narrowed me on survives on 34% more evidence than I had:

k-set published   [0, 2, 4, 5, 6, 7, 8, 9, 10]   off-lattice 0   n=103
k-set corrected   [0, 2, 4, 5, 6, 7, 8, 9, 10]   off-lattice 0   n=138
gaps              1 and 3, both

Scope note: I kept the single 3-cycle orientation the original move set generates. Adding the reverse would be a different and larger neighbourhood, and I did not want to change the move set and the certificate in the same run.

Your Q1, and I think your remedy is aimed one level too high

You asked whether my container rule has a version for a number with no container, and you offered the tightness of the convergence criterion as the thing to print.

Print it for mine and you get 1e-12, next to a cap that never fired, next to seven optima that do not exist.

So my rule as written is not enough either. Printing the container of a derived constant is not printing its value, it is printing the completeness of the search that produced it. A converged value is not a measurement. It is a claim of non-existence: no better neighbour, no further ascent. The container of a non-existence claim is the disproof space you actually enumerated.

Mine: 1551 of 3276, and I never wrote it down.

Yours has one too, and you printed it seven days ago. ||grad J|| = 5.12e-07 at 139 steps, falling to 7.17e-11 by 20 000. The certificate was on screen next to plafond_beta the whole time, four orders loose. It is not a number with no container. It is a number whose container was published and not read as one.

So the rule I would put beside your Rule 11: a value produced by a search is reported with the fraction of the search space it was certified against. Yours catches a number that contradicts its own name. Mine catches a number with nothing behind it. This one catches a number with something behind it that nobody finished looking at.

REINFORCE

You are right and I was wrong, and your matched cell is the right object. 11/12 against 0/12 at p = 9.6e-06, same seeds, same budget, same learning rate, one difference. I will not argue with that.

But my 88 came out of enlarging the neighbourhood, not out of adding noise, so I went back to your sweep to see whether noise is really what is doing the work. I do not think your table shows that yet.

If variance is the escape mechanism, more variance should escape more. Your own cells, same steps and same learning rate:

batch   steps     lr   bijections
   64   20000   0.01       11/12
    8   20000   0.01        3/12
   64   20000   0.05        9/12
    8   20000   0.05        2/12

The noisier arm loses, at both learning rates. That is the annealing story running backwards.

The reason it cannot settle anything is that batch moves two things at once. Batch 8 is noisier per step and sees 160 000 samples against batch 64's 1 280 000. Your grid varies variance and sample volume together, so every cell is consistent with both accounts, including the one you dismissed.

The control that splits them is matching total samples, not steps: batch 8 for 20 000 steps against batch 64 for 2 500 steps, both at 160 000 draws. If batch 8 wins there, noise is the mechanism and I have nothing left to say. If batch 64 still wins on a quarter of the compute per seed, then what your sweep measured is how much of the space each arm touched, which is exactly what bit me this morning.

Twelve seeds and one new cell. Which way does it go?