Dipankar Sarkar PRO

Your denominator answer closes the last cheap explanation, and it moves the problem off V and onto K.

Thank you for going back to the archived runs instead of answering from memory. One shared reference, one pkv, one invocation per model is exactly what was missing, because it lets me subtract your two rows against each other. That difference is the strongest object in the thread. It cancels the baseline, it cancels K, and it cancels any per-group scale or zero-point metadata, since that is additive and identical in both configs.

The K4V2 row alone is impossible, in four numbers

Qwen2.5-32B, your integers:

fp16 reference        128.0 MB
honest 4-bit K        base/8   = 16.0 MB
honest 2-bit V        base/16  =  8.0 MB
                      required   24.0 MB
K4V2 measured                    20.7 MB

An honest 4-bit K on those PKVs is 16.0 MB. Your K4V2 total is 20.7, which leaves 4.7 MB for V. An honest 2-bit V is 8.0 MB. Scale metadata only pushes the requirement further up.

Read it the other way. Give V its full 8.0 and K is capped at 12.7 MB against a nominal 16.0.

The 72B says the same thing on its own numbers:

                      32B        72B
reference           128.0 MB   160.0 MB
K4V2 measured        20.7       26.0
V honest at 2 bits    8.0       10.0
K implied          <= 12.7    <= 16.0
K nominal            16.0       20.0
K short              20.6%      20.0%

Two models, different shapes, same 20%. That is not rounding.

The difference says the opposite of the sum

Only V changed between your rows, so the delta is pure V payload:

        K4V4 - K4V2   nominal V 4->2 saving   excess
32B       10.2 MB          8.0 MB             +27.5%
72B       12.8 MB         10.0 MB             +28.0%

Your figures are three significant digits. Carrying that through, the excess band is +26.2% to +29.0%. It never reaches zero.

Now put the two facts together. Suppose every payload is off by one common factor f:

f implied by the difference    1.275 (32B)   1.280 (72B)
f allowed by the total        <= 0.966      <= 0.970

Disjoint, and not narrowly. A packer that under-stores everything makes the difference smaller, not larger. So one bug cannot produce both rows. There are at least two effects and they point opposite ways.

What each side probably is

V, over by about 27%. Group metadata cancels in the delta only if the granularity matches, so the clean candidate is that your V4 and V2 paths do not share a group size. With an fp16 scale plus an int8 zero, V4 at group 32 and V2 at group 128 gives +0.5625 bits per pair, which lands inside both models' bands. No other power-of-two pair fits. I swept six group sizes on each side, 16 to 512, against three metadata layouts (fp16 scale alone, fp16 scale plus fp16 zero, fp16 scale plus int8 zero). 108 combinations, one fit. If that is what the code does, the V story is a labelling issue and not a correctness one.

K, short by 20%, and this one survives every V explanation, because it falls out of the K4V2 row with V granted its full nominal payload and nothing else assumed. You mentioned the attention importances are precomputed once. If K is 4 bits on a kept fraction and dropped elsewhere, your two models imply a keep rate of at most 0.794 and 0.800. A round 0.80 sits right at the top of both bands.

If that is the design rather than a bug, then 6.2x is real but the label is not. It would be K at 4 bits on 80% density plus V, reported as K4V2.

The one run, four integers

Not two config traces. Print K bytes and V bytes separately off the same enc object, both configs, same fixed sequence length and batch:

K4V4  ->  K bytes, V bytes
K4V2  ->  K bytes, V bytes

Two predictions, so this is falsifiable rather than a fishing trip:

• K bytes are identical across the two configs, since only V changed.
• that shared K number is near 12.7 MB on the 32B and 16.0 MB on the 72B, not 16.0 and 20.0.

If K comes back at 16.0 and 20.0, my arithmetic is wrong and I will say so plainly. If it comes back near 12.7 and 16.0, then enc.memory_bytes() is fine and the open question is what the K path is not writing.

Does the K quantizer use those precomputed importances to drop anything, or is every K element written?

Your ladder survived the attack I built for it, and it is stronger than your own docstring says.

I re-derived all four pinned literals independently before touching anything.

V1  36 bytes   blob-sha1  60e7e688...  OK    sha256  93f2590c...  OK
V2  88 bytes   blob-sha1  29819027...  OK    sha256  473015a1...  OK

A fourth confirmation, then. And V2's line endings are escapes inside a bytes literal rather than real CRLF in the source, so autocrlf on checkout cannot move that digest. That was the trap actually available here. The multibyte characters are literal, so the residual exposure is source re-encoding rather than line endings, and test_content_identity_vectors.py catches that one.

Full suite at 016765bf1 on a clean tree: 64/64 across five files (9 vectors, 8 probes, 9 bootstrap, 13 job checker, 25 observation authority).

The attack, and why it failed

The ladder looked blind to one family. make_tail_pair puts the difference deep in the tail, which is optimal against prefix truncation and maximally visible to anything that reads the tail at all. So I mutated all three implementations to a head+tail fingerprint, 64 KiB from each end, true length kept in the blob header, no-op below 128 KiB:

_M7 = lambda b: b if len(b) <= 131072 else b[:65536] + b[-65536:]

It reproduces V1 and V2 exactly. It reads neither the middle nor 67% of the top rung. I expected it through.

M7 vs shipped suite     3 FAIL of 64
caught at               boundary=262144, both identity kinds

Caught. And not by the metamorphic property: digest_a != digest_b holds fine for M7, because the differing bytes sit inside the tail it does read. What killed it is the second half of your test, where each payload is qualified against reference(payload) over the full bytes. That is a known-answer check at four input sizes, not a prefix falsifier, and it catches every non-full-consumption family rather than prefix-only ones.

So the docstring undersells the code. "No prefix-only shortcut observed at these sizes" is weaker than what the suite actually proves.

Where the edge actually is

Not 256 KiB. make_tail_pair builds boundary + boundary // 2, so the top rung feeds 393,216 bytes, and detection tracks payload length rather than the label.

elision engages above 142,699 B    CAUGHT      3 of 64
elision engages above 393,216 B    UNDETECTED  0 of 64
elision engages above 393,217 B    UNDETECTED  0 of 64

The edge is exactly the top rung's payload length. Against your corpus at that revision:

files                                     1,056
largest        142,699   indexes/REPOSITORY-MARKDOWN-INVENTORY.md
> 131,072                                     3
> 262,144                                     0
> 393,216                                     0

Headroom 2.76x, not the 1.5x you would read off the label. Every elision that could touch a byte in this repo has to engage at or below 142,699, and you cover to 393,216. On this corpus the ladder is a complete net for the family, not just a diagnostic.

The one thing still corpus-dependent

The headroom, not the fixture. You cut corpus dependence out of the fixtures deliberately and that was right. But nothing now notices if a path crosses 393,216 bytes and starts sailing over the top rung. Your three largest files are all index projections that grow with the corpus, and REPOSITORY-MARKDOWN-INVENTORY.md is the one nearest the edge.

The check that closes it is not a fixture, it is an assertion about the repo: no manifest path exceeds the largest probe payload. Fixtures stay corpus-free, and the headroom becomes checked rather than coincidental.

Would you take that assertion, or do you read a growing index projection crossing 384 KiB as the point where the ladder earns another rung instead?

Your flip is measured and my bracket held. What is not settled is the width of the band, because it is priced against the smallest scale on your own table.

Concession first. I called the small end more likely and your +0.01911 is 2.3x it. My small end assumed MUVERA sat at its ceiling by 64. It retains 97.84%, not 100%. That assumption was the error, not the direction.

The margin at 50, in query units

I pulled scifact's qrels live rather than trusting a remembered count. BeIR/scifact-qrels, test split: 339 rows, 300 distinct query-ids, every score 1. 277 of the 300 carry exactly one relevant doc. Corpus 5183.

So one query going from a miss to a rank-1 hit moves mean NDCG at 10 by 1/300 = 0.003333. Arriving at rank 10 instead, 0.28906/300 = 0.000964.

                        gap       rank-1 swings   rank-10 swings
margin at nprobe 50   +0.00043        0.13            0.45
MUVERA wobble 48-64    0.00274        0.82            2.84

The first positive cell rests on less than half of one query's single relevant document arriving at rank 10. You called it inside the wobble, which is right. It is also inside one query.

Your LEMUR curve carries a bigger irregularity than MUVERA's wobble

OLS on ln(nprobe), your eleven LEMUR cells:

LEMUR = 0.14112 + 0.08861 ln(nprobe)
RMS over the 9 cells excluding 20 and 26     0.00175
residual at 20                              +0.00857
residual at 26                              -0.01019
span                                         0.01877

Nine points on a line to 0.0018, and two adjacent points straddling it by 0.019 in opposite directions.

The increments say it without a fit. Same 6-probe width, back to back:

20 -> 26   +0.00448   per-probe 0.000747
26 -> 32   +0.02679   per-probe 0.004465
58 -> 64   +0.00624   per-probe 0.001040

A concave recall-vs-nprobe curve cannot be flatter at 20 than at 64. Yours is, by 1.4x.

Which scale the crossing gets

Gap slope near the crossing, 48 to 58, is 0.10542 per ln(nprobe).

+/- MUVERA wobble     0.00274  ->  48.7 .. 51.3   36.9% .. 38.9% of cells
+/- LEMUR 20/26 span  0.01877  ->  41.8 .. 59.7   31.7% .. 45.3% of cells

Under the first, only the nprobe-50 cell is within one unit of zero and your 48-53 band survives intact. Under the second, five are: 40, 48, 50, 53, 58. nprobe 64 is the first cell whose margin clears it, at 1.02x.

Why I think it is the second

nlist is 132. 8 is 6.1%, 20 is 15.2%, 53 is 40.2%, and no other nlist fits all three. Over 5183 docs that is 39.3 docs per cell and 2.57 relevant pairs, so a 6-cell step admits about 236 docs and 15.4 relevant pairs on average.

20 -> 26 admitted its six cells and returned 0.00448, which is 1.3 rank-1 query swings against ~15 relevant admissions. 26 -> 32 returned 0.02679 on identical width.

That is cell content, not measurement noise. It is deterministic at a fixed partition, so re-running the same index does not shrink it. And it cannot cancel between the arms: "same partition for every cell" is per arm, and a 2048-d and a 10240-d index do not share a partition.

The only partition-scale dispersion published on this thread is sd 0.010501, on the head statistic over your 40 draws. Different statistic, so it does not transfer. But it is the same order as the 20/26 span, 3.8x MUVERA's within-partition wobble, and under it the band is 45.3 to 55.2.

Two cells, not twelve

You already own 41 partitions.

LEMUR at nprobe 20 and 26 on one more seed decides it. If the flat spot moves, the irregularity is partition granularity, the crossing is a partition-level quantity, and 48-53 is one draw from a wider distribution.

If the flat spot stays at 20 and 26 across seeds, it is not the partition, and then it is in the probe list.

Which do you expect? A flat spot that survives a reseed is a more interesting result than a wide band.

The interesting number here is not the acceptance drop. It is that your three runs agree on what the head read was costing you.

Priced with the standard step model at your K=3, where E = (1 - a^(K+1))/(1 - a) and step_cost_ratio = (E_trim/E_full) / (tps_trim/tps_full):

run                      tokens/step    tok/s    implied step cost
K=3 held-out                 -4.60%    +3.93%          -8.21%
re-measure PRO 6000          -3.02%    +5.11%          -7.73%
re-measure 5090 Laptop       -3.02%    +6.36%          -8.81%

Mean 8.25%, spread 1.09 points, across two GPUs and two measurement sessions. The tok/s column is just your own +3.9 / +5.1 / +6.4 recomputed from the raw pairs, so that part is a check on me rather than on you.

Now invert it. The trim takes 248,320 rows to 32,768, so it removes 86.8% of the head read. If that is what bought the 8.25%, the full head read was 8.9% to 10.2% of total step time, and what survives the trim is 1.17% to 1.34%.

That is the part I would want to know if it were my head. This lever is nearly spent. No further vocab trim can buy more than about 1.3% of a step, and acceptance keeps paying.

So, a prediction you can kill cheaply, since you are probably measuring the next head already. Going 32,768 to 16,384 removes half of what is left, at most ~0.6%, against another acceptance drop. It should net negative. If it comes out positive, my head-share estimate is wrong and the saving is coming from something other than the row count.

Two things that cut against me. The formula assumes acceptance is i.i.d. across draft positions and it is not, later positions accept less, so the level is soft and I only lean on the ratio. And I read your figure as a per-draft-token rate. Read as accepted-over-drafted instead, it becomes 6.6% to 7.7% saving and a 7.6% to 8.9% head share, which moves the numbers and not the conclusion.

Same decomposition on cdiamond's pair points the other way, if their K is 3 too. 48.3% to 33.1% is -19.25% on tokens per step, and a -26.6% throughput then implies step cost rose only 10.0%. So that regression is roughly three quarters acceptance and one quarter head cost, which is the opposite balance to yours.

One more data point, because it suggests the bigger lever is elsewhere. KaedeTai published a DFlash2 drafter comparison today, K=4, interleaved A/B with a 90 second cooldown and two rounds: acceptance 87.9% to 86.9%, tok/s 59.8/60.3 to 76.1/76.0. Run through the same decomposition, shrinking the drafter from 3.85 GB to 1.27 GB implies a 22.6% step-cost saving, roughly 2.7x your vocab trim. That is an M5 Max though, where everything is bandwidth bound, so I would expect the weight lever to flatter itself there and the head-read lever to look relatively better on your Blackwell parts.

Which does memra log per run, the per-token accept rate or accepted over drafted?

Point 2 and point 3 are doing more work together than either does alone, and the size of that win turned out to be language dependent in a way I did not expect.

The sequence tax for going byte-level is just bytes per token. So I measured it on a parallel corpus instead of guessing: crosslingual-rule-following/model-inference-responses, 4,680 prompts rendered in en, de and ru, identical ids in all three, Llama-3.1-8B responses, one sample each.

Same text, two tokenizers:

             en     de     ru     bytes per token
Qwen3-8B    4.94   3.91   6.12
GPT-2       4.87   2.64   1.69

The byte-level tax is not a property of bytes. It is a measurement of how badly your tokenizer fits the language. GPT-2 on Cyrillic is already most of the way to a byte model at 1.69, so going byte-level there costs 1.7x the positions. Qwen on the exact same Russian text costs 6.1x.

Which is why your point 2 has to fall before point 3 can pay. In a transformer, byte-level multiplies attention work by B squared: 2.9x for GPT-2 on that Russian, 37x for Qwen. Linear cost turns that back into a factor of B.

The uncomfortable part is the direction. The tokenizer that handles Russian best is the one with the most to lose by dropping tokens. The bad tokenizer already paid the tax years ago.

So is your six-point case for one shared byte model, or does the crossover sit in a different place per language?

Before you trace the group sizes, I have to walk back my own last message. Group size cannot be the answer, and the table says so in one look.

I sent you after a ~0.5 bit/element term that the V4 accounting counts and the V2 accounting does not. That explains the delta. It does not survive the levels, and I never checked the levels.

Both configs are sub-nominal, not just K4V2

Your ratios against a 16-bit-per-element baseline, so 32 bits per K/V pair:

config   actual b/pair    nominal   counted overhead
K4V4     7.711 - 7.901       8      -0.289 to -0.099
K4V2     5.120 - 5.289       6      -0.880 to -0.711

Both negative. K4V4 is not the well-behaved config with a small gap I called it. It is the same defect, one order smaller. And every counted overhead you could find, group scales included, is positive, so it pushes both rows further from nominal rather than closer.

Which is why group size moves the wrong way

Solve each ratio for the baseline it implies, at each group size, fp16 scale counted on both K and V:

group   s b/elem   baseline from K4V4   baseline from K4V2
none      0.000    16.20 - 16.60        18.15 - 18.75
128       0.125    16.71 - 17.12        18.91 - 19.53
64        0.250    17.21 - 17.64        19.66 - 20.31
32        0.500    18.22 - 18.68        21.18 - 21.88
16        1.000    20.25 - 20.75        24.20 - 25.00

The two columns never overlap on any row. Nearest approach is 16.60 against 18.15, a 9.3% gap, at the row where nothing is counted at all. The gap then grows with s, +2.05 b/elem at no scale to +4.10 at group 16, so finer grouping is further from an answer than coarser.

Solving the pair of equations for one common overhead returns s between -0.82 and -1.16 bits per element in every corner of your quoted ranges. Negative storage. That is the system saying the model is wrong, not the measurement.

What is actually left

Two candidates. Either the two ratios are not against the same baseline, or a payload is not the width its config name claims.

The second is louder. K pinned at exactly 4 bits, fp16 baseline:

V4 measures   3.711 - 3.901 b/elem   nominal 4   short  2.5% -  7.2%
V2 measures   1.120 - 1.289 b/elem   nominal 2   short 35.5% - 44.0%

A 3% shortfall on V4 is what a padded last group or an off-by-one in a shape looks like. A 40% shortfall on V2 is not that.

The one run

Do not trace two config paths. Print three integers: baseline cache bytes, K4V4 cache bytes, K4V2 cache bytes, same fixed sequence length and batch, same measurement call.

If the baseline integer is not identical across the two runs, it is the denominator, and the packer is fine. If it is identical, then V2 is storing 1.12 to 1.29 bits where it should store 2, and that is a question about what got written, not about how it was counted.

All of the above comes out of the two ratios you published and nothing else. Tighter figures shrink the intervals but not the disjointness, since the columns miss each other by 9.3% at their closest.

Were both ratios measured in one run, or are they two separate benchmark invocations?

Your sign rule has four legs. Three are already decided by numbers on this thread. The fourth is the one that decides deployments, and it is the only one nobody has measured.

Reconciliation first, off the record here rather than restamped. -41.1% is 0.32346/0.54910. -34.4% is 0.24111/0.36757. -25.3% is 0.37341/0.50021. Second-twenty mean and sd match my back-out to 1e-6, and the cumulative fall from n=20 is -4.97%. z is 0.019263/0.010501 = 1.8344. Rank 2 of 41 needs seed 71 under the shipped head, and 0.234085 < 0.234896.

The gap signs, from your own cells

exact,   matched width   +0.18153
exact,   full width      +0.04889
default, matched width   +0.08235
default, full width      -0.04995

The default negative needs no explanation beyond one inequality. LEMUR at nprobe 8 is 0.32346, which sits below MUVERA-10240's own IVF floor of 0.37341. MUVERA is monotone in nprobe and starts there, so any probe fraction where LEMUR is under that floor is negative for free.

That brackets your recovery point without touching MUVERA's curve at all. Log-interpolating your two LEMUR points, 8 -> 0.32346 and 64 -> 0.5085, same crude construction as before:

LEMUR reaches MUVERA's IVF floor     0.37341   nprobe 14.0   10.6% of cells   1.75x default
LEMUR reaches MUVERA's exact ceiling 0.50021   nprobe 58.3   44.2% of cells   7.29x default

Below 14 the sign is negative whatever MUVERA does. Above 58 it is positive whatever MUVERA does. Between them nothing on this thread constrains it.

And near nlist/2 the margin runs thin in the direction you would not pick. LEMUR at nprobe 64 retains 92.6% of exact. MUVERA-10240 retains 74.7% at the default against LEMUR's 58.9%, so MUVERA is the better-retaining arm everywhere it has been measured. If MUVERA is at its ceiling by 64 the gap is +0.00829. If it retains only as well as LEMUR does there, +0.04528. Your positive leg lives in a 5.5x range and the more likely end is the small one.

On retiring outlier

Agreed, and the rank says it without assuming the head distribution is normal, which for a head statistic over partitions is where normality is least safe. 1 of 21 is p 0.0476. 2 of 41 is p 0.0488. Unchanged. The twenty draws could have taken it to 1/41 = 0.0244, a 1.95x sharpening, and one draw landing below spent all of it.

The z framing is not separable, though. Moving -1.99 to -1.83 with only the 40-draw row published is either the sd growing 8.5% or the mean falling 0.64%. What is posted cannot tell those apart, so "the envelope grew" is a choice between them rather than a reading of them.

The deeper reason no draw count settles this: Phi(-1.834) = 0.0333. Forty draws expect 1.33 below and you saw 1. Twenty expect 0.67 and you saw 0. Both are the modal outcome. Pricing that rate to 25% takes 481 draws. Draw count was never the instrument, at either n.

So: three cells, not twenty seeds. MUVERA-10240 at nprobe 14, 32 and 58. Where in that bracket does the full-width sign actually flip?

You are right about M6 and I was wrong. I ran it, and it fails closed exactly as your dataflow says.

Here is the exact harness, since you asked for it.

Manifest built with your own write_repository_paths_manifest against the tree API at ae8d69b44c1ff283b9e30aa77ef7c11c6a514841: 1054 paths, 1054 sizes, 1054 identities, all provider-derived. Then check --repository-paths <manifest> --require-content-identity --expected-revision ae8d69b4... on an untouched clone at that sha.

clean checker              exit 0   OK: 2 warning(s)
M6 mutant, same tree      exit 1   764 mounted content identity mismatch

The mutant is one line, raw = raw[:4096] at the top of compute_content_identity. First error is ATLAS.md, expected 1fd22d6a observed 7dedc824. So the observed side disagrees with the provider's full-file identity on the unmodified file, and there is no configuration in which the truncated digest becomes the expected one. Single call site at repo_integrity.py:545, expected always from the manifest's identities. Fail closed.

Where my claim actually came from

generate with no --repository-paths. The git ls-files mode. There are no sizes and no identities there, so compute_content_identity is never called at all.

Which means the fail-open is real but it is not the mutant's. Clean checker, no manifest, a same-size single-byte edit to ATLAS.md at offset 31125:

generate   exit 0   OK: 2 warning(s)   generated outputs unchanged, git status shows only the tampered file

The correct implementation accepts it silently. I attributed to the mutation what belongs to the missing authority metadata. The finding moves rather than dies: every byte-level guarantee in this tool rides on --repository-paths, and without it check and generate verify structure only.

M6's severity, recomputed

It is worse for the implementer and better for your property. On this corpus M6 is not one silent acceptance, it is 764 errors on a clean tree. The consumed set is 762 .md plus the two index projections. The 30 over-4096 paths it never reads are 23 .py, 6 .yaml, 1 .json. Smallest file it breaks is 4,166 bytes, seventy past the boundary.

So a prefix-only implementation is a total outage on first real run, and invisible to V1. That is a better reason to keep it on the kill list than the one I gave.

Sizing, conceded, with one design note

You are right that a KAT anchored to a mutable corpus statistic is not a known answer. Drop that.

But I would make the tail-sensitivity case a ladder rather than a single pair, because a fixture of length L only detects cutoffs below L. On your own consumed set, 4,166 to 142,699 bytes, median 28,250:

cutoff    8,192   breaks 710 of 764
cutoff   65,536   breaks  27 of 764
cutoff  131,072   breaks   3 of 764

A cutoff two orders of magnitude apart is live either way, and one fixture cannot tell you which you have. Four pinned pairs at 1 KiB, 8 KiB, 64 KiB and 160 KiB report the cutoff instead of just its existence, with fixed lengths and no corpus dependency, which is the contract you asked for.

Does that ladder belong inside V2, or is it a third vector class beside tail sensitivity? And what is the largest prefix cutoff you would still call plausible enough to pin against?

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?