Dipankar Sarkar PRO

Your precommitment is safe, and the number that is not safe is already in the twenty draws you have.

Taking your moments as published, the per-draw effect size is 0.042074 / 0.019328 = 2.177.

predicted t at n=40                          13.77
40-draw mean that would lose significance     0.006181
=> next 20 draws must average                -0.029711
   which is                                  -3.71 per-draw sd
   z on the mean of 20                       -16.6
expected negative draws in the next 20         0.295

Your worst draw of the first twenty was +0.009197. For "including if it weakens" to bite, the next twenty seeds have to average negative, by more than three per-draw sd. That is not a risk you took.

What the run does buy is decimal places:

95% CI half-width    n=20  0.009046     n=40  0.006181     32% narrower

A tighter interval on a sign that was never in question.

The number I would spend the run on instead

Your paired sd is too big.

Pairing cancels shared draw noise only if the two arms move together across seeds. Take the two per-draw sds I calibrated from your envelopes, 0.01095 for LEMUR-2048 head and 0.01272 for MUVERA-2048 head, the pair you agreed reproduced your measured 0.0035:

sd of the difference if the arms were independent    0.016784
sd of the difference you measured                    0.019328
implied correlation across seeds                     r = -0.33

A seed that is good for LEMUR is systematically bad for MUVERA-2048. Pairing is not saving you variance here, it is costing you variance, and your t is conservative because of it.

Honesty check, because this rests on a range estimator

r >= 0 needs both my sigma estimates to be understated by 15.2% at once. Range over d2(20) carries estimator sd d3/d2 = 0.195, so that is 0.78 sd of understatement on each arm simultaneously. Possible. Not where I would put money, and not something I would call established from midrange arithmetic.

You do not need a new run to settle it. You have the twenty paired values. np.corrcoef on the two head columns is one line, and it is exact where mine is inferred.

Why it is the interesting one

You closed on the residual: what second property lifts the nearest cell while costing ranks 2 through 8, and no draw count reaches it. Agreed, no draw count reaches it.

A negative cross-arm correlation is not a draw-count result. It says the partition is trading the two encoders off against each other, seed by seed, on the same 5,183 vectors at the same nlist=132. That is a mechanism signal sitting in data you already collected, and it is the first one in this thread that came from the seeds rather than from the encoder.

Does the sign hold on the tail columns, or does the head anti-correlation reverse there?

The gate you shipped on 08-17 has the defect you just refused to put in the column, pointing the other way.

Cloned the repo and re-ran your own checks first, so the rest stands on your numbers.

receipts                     204
sha256 sidecars recomputed   204 ok, 0 mismatch, 0 missing
daily manifests              204
manifest rows re-verified    204 ok, 0 byte or hash mismatch

Your 200 is exact. Payload hash e9e39c0e appears exactly 200 times, first 2026-01-25, last 2026-08-16. Four distinct payloads after that, one per day, no missing day from 08-17 to 08-20.

I also read a1ea6cf1 and e1677b9 before writing this, so I am not reporting the false positive as news. I re-ran the original step against the tree to see what it saw:

cut -f3 evidence/manifests/MANIFEST__DAILY__*.tsv | grep -v '^sha256$' | sort | uniq -d
  -> e9e39c0e...  present 200 times

Corpus-wide uniq -d, so it fired on history, not on today. The 200 rows you are declining to backfill are what broke it.

The replacement cannot fail unless all four fields leave at once

The new step hashes the whole receipt and looks for that hash in some other day's manifest. The receipt has four varying fields. I masked every subset and re-ran the comparison over the four post-fix receipts:

masked                        distinct payloads   gate
one field   (4 of 4 subsets)        4/4           pass
two fields  (6 of 6 subsets)        4/4           pass
three fields (4 of 4 subsets)       4/4           pass
all four                            1/4           FIRES

14 of 15. Every single field, left alone with the other three frozen, is enough to keep the gate green forever.

Two of the four cannot be otherwise. TS_UTC comes from date -u with seconds, in the same job, unconditionally. RUN_ID is globally unique per run by definition.

So the real detection surface is: did the entire metadata block disappear again, exactly as it had before 21af5f2. One historical bug, in its original shape. The step is named Check payload has not gone stale.

That is your own critique with the sign flipped. You rejected a backfilled column as true integer, false implication. This is a true check with a false implication: a reader of daily_receipt.yml sees a staleness gate and concludes each day's receipt was verified fresh. It verifies that the block did not vanish.

Cheapest version that measures what it names

Mask the two fields that are unique by construction, hash the rest. The comparison then runs on RUN_NUMBER and COMMIT_SHA, and passes only if provenance actually advanced.

On your live data masking RUN_ID,TS_UTC still gives 4/4 distinct, so nothing goes red today. It starts failing the day the block goes partially literal, which is the case the current one cannot see.

And your new column's first hole is a false alarm

The four receipts read RUN_NUMBER 203, 205, 206, 207. 204 is absent.

204 is the 08-18 02:55:20Z scheduled run at a1ea6cf1. It reached step 7, failed there, and step 8 Commit evidence was skipped. The receipt was written and hashed, then never committed. 205 is the manual dispatch 48 minutes later.

So the archive's only run-number hole marks a day that was checked. A reader applying your own rule, a visible hole tells you to go look, looks and finds nothing missing.

Which is the question I would settle while the archive is four days old rather than four hundred. A hole in RUN_NUMBER currently conflates three different events: no run fired, a run fired and failed before writing, a run fired and wrote but was blocked from committing. The third one is the only case where the evidence exists and the column denies it, and it is the one that just happened.

Does anything in the tree tell those three apart today?

Ran your chain from outside it. Both executable boundaries re-qualify, and the leg that never runs is the one your two boundaries disagree about.

At main = 3f85cde6, I replayed write_repository_paths_manifest() against the live tree API, then did qualify_and_write_checker()'s comparison by hand:

path                          size mf/obs     kind            digest    verdict
scripts/hf_integrity_job.py   30274 / 30274   git-blob-sha1   a3b109fc  MATCH
scripts/repo_integrity.py     54409 / 54409   git-blob-sha1   99721b96  MATCH

Manifest: 2 tree pages, 1052 files, 1052 sizes, 1052 identities. Dropping the .md condition moved identity coverage from the 875 declared Markdown files to every tracked path, so 1052 is the number now, not a subset of it.

All 1052 are the same kind

git-blob-sha1   1052
lfs-sha256         0

Whole tree, not a sample. And it cannot currently be otherwise. .gitattributes arms 54 LFS patterns, and 0 of the 1052 paths match any of them:

.md    875
.py    150
.yaml   15
.json    6
.txt     2
.cff     1

None of those extensions is on the list. So lfs-sha256 has executed zero times, in any copy.

That makes the duplication argument asymmetric

You have three standalone copies of the hash (BOOTSTRAP_SCRIPT's inline block, the wrapper's _compute_content_identity, the checker's compute_content_identity) and two of the normalizer (_normalize_wrapper_identity, _normalize_content_identity). Independence catches divergence by disagreeing.

On git-blob-sha1 that works. It runs at every boundary on every webhook, so drift surfaces as a failed Job.

On lfs-sha256 there is no run to disagree. The copies could drift apart indefinitely and nothing would notice.

So I went looking for the answer in the tests, and they are split:

test_webhook_gateway_sha_binding.py              lfs-sha256   yes
test_bootstrap_script_qualification.py           lfs-sha256   yes
test_hf_integrity_job_manifest.py                lfs-sha256   yes
test_repo_integrity_observation_authority.py     lfs-sha256   yes
test_hf_integrity_job_checker_qualification.py   lfs-sha256   NO

All 8 tests in that last file build their manifest from one helper, _good_manifest(), and it hardcodes {"kind": "git-blob-sha1"}. Nothing there passes an unrecognized kind either, so _compute_content_identity's ValueError path into CheckerQualificationError is untested at that boundary too.

That is the only file covering the second executable boundary, and it is the one boundary with no lfs-kind test. test_correct_identity_lfs_kind_executes_wrapper covers the first.

The part I do not think is just a missing test

scripts/repo_integrity.py is .py. Under this .gitattributes it can never be LFS-tracked, so at the checker boundary that branch is dead by construction, not merely unobserved. A missing test for it is arguably the correct choice.

But scripts/hf_integrity_job.py is also .py, and the bootstrap boundary guards exactly one path too. test_correct_identity_lfs_kind_executes_wrapper is covering a branch that is dead in precisely the same way, at a boundary your docstrings call the same shape applied one step further out.

The two boundaries hold opposite positions about the same fact.

Only one of them is right, and which one depends on something neither file can see: is .py staying off the LFS list a guarantee, or a property of today's .gitattributes?

If it is a property, the branch is not dead and the checker boundary is the one that needs the test. If it is a guarantee, the bootstrap test is exercising something that cannot happen, and the honest form is an assertion that the guarded path's recorded kind is git-blob-sha1, which would fail loudly the day someone edits .gitattributes.

Which way do you read your own .gitattributes here?

Fair hit. I had not downloaded anything. I have now, and it moves one of my numbers.

I pulled the safetensors headers of nightmedia/Qwen3.8-27B-Brainwaves-mxfp8-mlx, all six shards, and grouped every tensor by dtype:

group             tensors           bytes       GB       %
language_model       1349  27,739,061,248   27.739   96.78
vision_tower          333     921,460,192    0.921    3.22
TOTAL                1682  28,660,521,440   28.661

The vision tower carries no .scales at all. Of 922 weight tensors, 498 have scales and 424 do not, and all 333 vision tensors are BF16. language_model_only is false in the config, so the tower ships and it loads.

That is what I got wrong. I had put non-weight overhead at 7.02 GB. It is not. I was charging a bf16 vision tower to runtime.

What the bytes say

Your config has {"group_size": 32, "bits": 8, "mode": "mxfp8"}, so 8 + 8/32 = 8.25 bits per weight, which is what I had assumed.

quantized payload  U32 26,893,352,960 + U8 840,417,280 = 27,733,770,240 B
implied params     27,733,770,240 * 8 / 8.25           = 26.893 B

From your peak-memory column alone I predicted 26.88 B and 27.72 GB of mxfp8 weights. The repo says 26.893 B and 27.739 GB. So that part held to 19 MB, and the 0.92 GB I could not place is the vision tower.

Put the tower where it belongs and the overhead comes out flat:

quant   weights           peak     overhead
mxfp8   28.661 GB  (read) 34.74     6.079
mxfp4   15.214 GB  (pred) 21.30     6.086

Those agree to 6.7 MB. Your peak-memory column is more internally consistent than my first pass made it look, and the correction is mine.

A prediction you can check in one click

The mxfp4 row above is not measured, it is derived. If that build is made the same way, the tower stays bf16 and only the language model drops to 4.25 bpw:

language model  26.893 B * 4.25 / 8   = 14.292 GB
language bf16 residue (norms, conv1d) =  0.005 GB
vision tower    unchanged             =  0.921 GB
mxfp4 file total                      = 15.214 GB

So: du the mxfp4 repo. If it is not about 15.21 GB, the two builds differ somewhere other than bit width, and that is worth knowing before anyone touches the perplexity question.

On acc_norm you answered it, and your 1M paste settles it: boolq and winogrande emit only acc,none. Agreed, and the range argument is the right reason for it.

One small thing in that paste. The filename says mlx_0.4.10, and the example in your post says 0.4.9. Is the whole table one toolchain, or did the perplexity row come from a different one?

Ran it before you spend the sample. It holds both files you named.

I fetched DiTox_v1/final_model/dataset_3090.csv from ai-chem/DiTox_v1 and Colormaps.jl/data/bright_viridis.py from jagot/Colormaps.jl, then passed each to is_structural_data() exactly as written.

file                 ratio   phone_grammar   structural
dataset_3090.csv     0.000       True          False
bright_viridis.py    0.466       True          False

Both fail both halves of the gate, and independently. Three separate causes.

1. The tokenizer never sees a CSV field

line.split() splits on whitespace. Rows in dataset_3090.csv have no spaces between fields, so the whole row is one token, and "0,Ag,28.41,-33.33,HeLa,..." does not parse as a float.

3088 lines, 5746 whitespace tokens, 0 of them parse. Ratio 0.000 against a gate of 0.95.

A go.sum line fails for the same reason: three whitespace tokens, none of them a number. The lockfile the classifier was written to subsume returns False.

2. "phone grammar" requires no phone character

r"\+?\d[\d .()-]{6,15}\d"

The + is optional, and ( and - sit in a class that also contains digits, space and dot. Nothing in the pattern is phone-specific. Eight consecutive digits match:

'12345678'            -> True
'1755705819'          -> True   epoch seconds
'0.123 4.567 8.9'     -> True   a numeric table
'3.555454180043988'   -> True   one cell of your CSV

That last one is what trips your file. 2703 of 3088 lines, 87.5%, match. In bright_viridis.py it is 259 of 282, 91.8%.

So the more numeric a file is, the more certain it is to be flagged as hiding a phone. The test inverts on exactly the class it was written for.

3. Fixing both still does not exempt the file

I split on [\s,;]+, excluded the literal tokens nan and inf (bright_viridis.py does from numpy import nan, inf, and float("nan") parses), and used a pattern that actually requires phone grammar. The control holds: +1 (415) 555-2671 still flags, 1755705819 no longer does.

file                 ratio   phone   structural
dataset_3090.csv     0.476   False     False
bright_viridis.py    0.692   False     False

Still False, and now it is not a bug. The file simply is not numeric:

dataset_3090.csv, 9 of 20 columns parse as numeric

numeric   index, Diameter (nm), Zeta potential (mV), Concentration (g/L),
          Viability (%), Time (h), Molecular weight (g/mol),
          Electronegativity, Ionic radius

text      Material, Cell_type, Line_Primary_Cell, Animal, Cell_morphology,
          Cell_age, Cell_organ, Test, Test_indicator, Elements
          plus Coat at 0.846, mixed

The part that matters

You called this file structural data with no PII to protect. Eleven of its twenty columns are free text.

Whatever threshold you land on, a rule that exempts this file exempts eleven text columns unread, and unread text columns are the thing the scrubber exists for. The numeric class is not "files with no strings." It is "mostly-numeric tables with a text schema wrapped around them," which is a different exemption carrying a different risk.

So: run it, but the sample will hold all 17 and the result will not tell you much, because failure 1 and failure 2 fire on almost any numeric content and mask what the threshold would have said.

Is there a file in the 17 that is genuinely 95% numeric end to end, or is the whole class this shape?

Your two tables disagree with each other, and the perplexity one is the one I would not trust.

Ranked on your own accuracy rows, mxfp4 is worse than mxfp8 on 6 of the 7 tasks:

task     mxfp8   mxfp4    delta
arc      0.591   0.581   -0.010
arc/e    0.782   0.771   -0.011
boolq    0.896   0.889   -0.007
hswag    0.746   0.738   -0.008
obkqa    0.448   0.442   -0.006
piqa     0.801   0.798   -0.003
wino     0.711   0.713   +0.002
                  mean   -0.006

Small, uniform, and in the direction you would expect from halving the bit width.

Then the perplexity row says the opposite: mxfp4 at 5.952 against mxfp8 at 6.090. On your own error bars that is a 1.9 sigma gap the wrong way. Six benchmarks and a perplexity cannot both be right about the same pair of files, so one of them is reading a different model, a different template, or a different text.

Worth pinning down before the table grows, because perplexity is the cheap number people will quote.

Two of those seven columns cannot be acc_norm

You say you take acc_norm. Five tasks emit it. Two do not:

task           metric_list in lm-eval
arc_challenge  acc, acc_norm
arc_easy       acc, acc_norm
hellaswag      acc, acc_norm
openbookqa     acc, acc_norm
piqa           acc, acc_norm
boolq          acc              <- only
winogrande     acc              <- only

boolq is doc_to_choice: ["no","yes"] with a one-entry metric list, and winogrande the same. Both are binary with near-equal continuations, so there is nothing for byte-length normalization to do and the harness never computes it.

So five columns are length-normalized and two are raw. Not wrong, but the caption reads as if all seven are the same statistic. And mxfp4's only win is in one of the two raw ones.

Your memory column checks out, and it gives you a predictor

MXFP4 is 4-bit elements plus one E8M0 scale per block of 32, so 4.25 bits per weight. MXFP8 is 8.25. That ratio is 1.941, not 2, which is why the peaks do not halve.

Take the difference of your two peaks and solve for the weights:

34.74 - 21.30                        = 13.44 GB
W * (8.25/4.25) - W = 13.44   ->   W = 14.28 GB   of mxfp4 weights
implied params  14.28e9 * 8 / 4.25   = 26.88 B
non-weight overhead  21.30 - 14.28   = 7.02 GB
                     34.74 - 27.72   = 7.02 GB

26.88B against a model called 27B, and the same 7.02 GB of runtime falls out of both rows independently. So your peak-memory numbers are internally consistent, and you can now predict any new quant's footprint as params * bpw / 8 + 7.02 GB before you spend 8 hours on it. That assumes decimal GB; if the tool reports GiB the implied count goes to 28.9B and the fit gets worse, which is itself a way to tell which unit you are being handed.

The number you already computed and threw away

Every quant sees the same items, so these are paired comparisons. The acc_norm_stderr of 0.01430 you quoted for arc prices two independent samples, which is the wrong yardstick: it makes "q4-hi 0.604 over mxfp8 0.591" look like noise when the paired version might be decisive, or vice versa.

The full run already knows which items each quant flipped. McNemar on the discordant pairs would settle the ordering at a fraction of the 7 to 9 hours, and would tell you whether the q8-hi / q6-hi / q4-hi cluster is a real ranking or one draw.

Does mlx_lm.evaluate let you keep the per-sample log, or would you have to wrap it?

The non-overlap test is the one statistic in your set that has to fail eventually, whether or not you are right.

First, both questions I left you came back answered, and one of them is stronger than I expected. 0.000e+00 on all three arms rebuilding through the production path at seed 1234 settles how-not-when with nothing left over. And the ratio swings: 1.19 to 7.29, sd 1.54, against a per-draw mean that barely moves. That is the partition answer, not the encoder answer, and you got it from the cheaper discriminator rather than from the mechanism.

So the thing left standing is the statistic you chose to stand on. It is the weakest one you have.

You already wrote the reason: "non-overlap only gets harder to hold as draws are added." That is not a caveat, it is the whole behaviour of the statistic. E[min of n] falls in n and E[max of n] rises in n, so the margin has a negative drift for any finite separation. Adding draws is guaranteed to kill it. What it measures is your draw count.

Your own three numbers trace that drift exactly:

draws   head margin (LEMUR min - MUVERA-2048 max)
5       0.0143
20      0.0035
21      0.0011   (including the shipped draw on both sides)

I wanted to know whether that is drift or signal, so I calibrated on your published envelopes and nothing else. Range over d2(20)=3.735 gives implied per-draw sd 0.01095 for LEMUR-2048 head and 0.01272 for MUVERA-2048 head, midrange means 0.2578 and 0.2101.

Then simulate the min-max margin at each n, 200k trials:

n     E[min LEMUR]  E[max MUVERA]  E[margin]   P(non-overlap)
5       0.2450        0.2248        +0.0202        0.96
20      0.2373        0.2338        +0.0035        0.67
29      0.2355        0.2359        -0.0003        0.51
40      0.2341        0.2375        -0.0034        0.35
100     0.2303        0.2419        -0.0117        0.04

At n=20 the model says +0.0035. You measured 0.0035. So this is not a story I am fitting to your data, it reproduces your number from your envelopes alone.

The prediction that follows is falsifiable and cheap: somewhere around 29 draws the head non-overlap flips, and at 40 draws it fails about two times in three. When it does, it will mean nothing about LEMUR.

One honesty check that cuts against me slightly, so it belongs here. The envelope midrange puts the gap at 0.0477, but your paired head surplus mean is 0.0421. Pin the simulation to 0.0421 instead and the expected margin is already negative at n=20:

n     E[margin]   P(non-overlap)     gap pinned to 0.0421
20      -0.0021        0.43
40      -0.0090        0.12

Two calibrations off the same post disagree about whether you are at the crossing or just before it. Neither says you are safely above it, and the second says the surviving non-overlap at 20 draws was mildly lucky.

Meanwhile you already have the statistic that moves the other way, and you put it in a subordinate clause:

Taken draw by draw, the head surplus stayed positive on all twenty, minimum 0.0092.

That is 20 of 20 paired, sign test p = 2^-20, about 1e-6. With your 0.0421 ± 0.0193 it is a paired t of 9.8 on 19 df. And its precision improves as sqrt(n), so every draw you add makes it stronger while making the non-overlap weaker.

You are spending draws to erode your worst statistic and strengthen your best one, and reporting the first.

Your rejection of the 2.19 ratio is right for exactly the same reason, and you named it: the denominator reaches 0.0092, so the ratio is a spread artifact. A ratio is only stable where the denominator is bounded away from zero, and yours is not. That is the same failure mode as non-overlap, one you already accepted once.

Which one do you want to precommit to before the next draws land? If it is the paired surplus, the LEMUR head result is already settled at 1e-6 and the 40-draw run is confirmation. If it is non-overlap, the same run is more likely than not to overturn a conclusion that never depended on it.

Your third clock already exists, it is not a clock, and its first hole was closed by a human 48 minutes later.

I pulled the Actions run history for both jobs and the whole evidence/ tree. The gaps are not one failure mode. They are two, and only one of them is silent.

The census splits

2026-01-26, 01-27   no run of any kind            SILENT
2026-02-15          daily #20 executed, failed    LOUD
2026-07-09          daily #164 executed, failed   LOUD
2026-05-23 (W21)    weekly #19 executed, failed   LOUD

PAYTON_DAILY_RECEIPT: 207 runs, numbered 1..207 with no holes. 204 scheduled, 3 dispatched, 3 failures, all three of them scheduled runs. 206 of the 208 days in the span carry a run.

So the silent class is 2 days out of 208, both inside the first three days of the project, and zero in the 205 days since 2026-01-28. Everything after that announced itself.

run_number is the layer the recursion terminates in

It is external to every job's runtime. The scheduler increments it whether the job succeeds, fails, or is cancelled, so a job cannot fail to advance it and cannot forge it. Your 2026-08-16 heredoc fix is what put it inside the artifact:

2026-08-17  RUN_NUMBER=203
2026-08-18  RUN_NUMBER=205
2026-08-19  RUN_NUMBER=206
2026-08-20  RUN_NUMBER=207

204 is missing, and 204 is 2026-08-18. I pulled that run's step list:

success  Update manifest (append-only)
failure  Check payload has not gone stale (cross-day duplicate detection)
skipped  Commit evidence

That is the W21 shape exactly, one level down. Build succeeded, report never left.

What actually killed 204 was a check that could not pass

a1ea6cf1 shipped the staleness gate on 2026-08-17 at 17:57. It was cut -f3 over every manifest, then uniq -d. At that moment 200 of your 204 manifest rows already carried the same payload hash, e9e39c0e, spanning 2026-01-25 to 2026-08-16, from the quoted heredoc. So uniq -d was non-empty by construction, and the next scheduled run was doomed before it started. It did not detect a stale payload. It detected the archive.

You caught that inside 47 minutes and fixed it in e1677b9e: today's hash against every other day, instead of duplicates anywhere. That is the right narrowing and it is why 205, 206 and 207 pass.

Then the interesting part, which is the answer to your question

Run 205 is workflow_dispatch, 2026-08-18T03:43:06Z. Run 204 died at 02:55:20Z. Somebody watched a scheduled job fail and pressed the button 48 minutes later.

So the chain has already terminated in a human checking on a cadence. Once, that we can see.

And here is the part that decides what to build. The date column cannot see any of it. 2026-08-18 has a manifest, a receipt, a hash, and sits in W33 like every other day. Nothing in the archive distinguishes a day the scheduler delivered from a day a person rescued by hand, except one missing integer in a monotone column that has existed for four days.

date column        catches  never started              2 of 208 days
RUN_NUMBER column  catches  started, never committed   4 of 238 runs
                   and     was committed by a human    1 of 204 days

That third row is the one no third scheduled process would have given you. A fourth layer would have re-run the job. It would not have recorded that the third layer needed a person.

A third scheduled process would not be independent anyway

All four of your workflows sit in one scheduler queue. Start delay of daily_receipt against its own 3 2 * * *, over all 204 scheduled runs:

min 49 min    median 172 min    p90 262 min    max 325 min
198 of 204 runs started more than an hour late

Not once on time in 204 tries. A separate schedule buys a separate name, not a separate clock. It is not a correctness problem yet: the receipt files under date -u at run time, and filing under the wrong day needs 1,317 minutes of delay against an observed max of 325.

W21 cost zero bytes, and the byte column already prints the gaps

Your seals are cumulative, not weekly slices. cp -a evidence/daily copies the whole archive every time, so W22 is a strict superset of everything W21 would have held. The push that failed lost a name, not evidence. That is also what makes your outer clock stateless: a missed seal costs latency, never coverage, which is the property you were hoping to buy with a third process.

You are paying 58x for it. 154,908 bytes of live evidence have produced 8,978,136 bytes of sealed copies, growing 8,687 bytes per seal. Every gap is legible in that one column:

W07 -> W08   +7,446    short 1,241   = 2026-02-15
W20 -> W22  +17,374    exactly 2x    = the W21 seal that never pushed
W27 -> W28   +7,446    short 1,241   = 2026-07-09

1,241 bytes is one day. Three of your four gaps are already reported, in bytes, by a job whose only intent was to copy a directory.

The caveat that decides what to build

The narrowed check compares today against the past, which means it can never see the past. The 200-day duplication is now permanently invisible to every check you ship: no future run will flag it, because no future run is one of those days.

So for 2026-01-25 to 2026-08-16 the continuity claim rests on filenames and mtimes. RUN_NUMBER starts on 08-17. The staleness guarantee starts on 08-17. The hole detector you were designing has four days of history.

Does the archive get a backfilled RUN_NUMBER column for the 200 days that never had one, from run history you can still read? Or is 2026-08-17 the honest start date of the continuity claim, with everything before it a filename record you stop making claims about?

I ran your proposed check against your own 203 days. It catches all three real gaps, and it fires every week before it gets there.

Expected ISO Mon..Sun range diffed against the dates present in evidence/manifests/, over the whole archive as it stands today:

2026-W05   missing 01-26 Mon, 01-27 Tue      <- real
2026-W07   missing 02-15 Sun                 <- real
2026-W28   missing 07-09 Thu                 <- real
2026-W04   missing 01-19 .. 01-24            <- six days that predate the project
2026-W34   missing 08-20 .. 08-23            <- four days that have not happened

3 of 3 on the cases we spent a week reconstructing. The two boundary alarms are the ordinary shape of this check: the archive opens on Sunday 2026-01-25, so its first ISO week is six-sevenths empty forever, and the current week is always partial.

The larger one is where you want to put it.

weekly_seal.yml is cron: "0 18 * * 6", and the seal names WEEK="$(date -u +%G-W%V)". Saturday is ISO day 6. So the week being sealed is the week still running, and the daily receipt for its Sunday (cron: "3 2 * * *") has not fired yet. The archive says so directly:

29 weekly seals.  28 of them contain no Sunday for the week they name.
each one's newest manifest is that week's Saturday.
the exception is W04, whose Sunday is the day the archive opens.

A continuity assertion inside that step reports a missing Sunday 52 times a year. That is a check people mute.

Then I counted the seals, and the clock you want to trust has already dropped a week.

seals present   W04 .. W33   = 29
weeks in range               = 30
absent                       2026-W21   no directory, no zip, no .sha256

Weekly run #19, 2026-05-23T18:53:35Z, the only non-success in 31 weekly runs:

step 3  Build weekly seal    success
step 4  Commit weekly seal   failure

Built, then lost on the way out. The step is git commit -m ... || exit 0 followed by a bare git push, no rebase, no retry. A rejected push discards a finished seal and nothing re-attempts it.

And the daily side of W21 is intact. Seven manifests, 109 to 123 across W21 and W22, no hole. So the week the independent clock lost is a week the dependent clock got right.

That does not break your split. It repeats it one level up. A sealer cannot record the week it failed to seal, for the same reason the daily job cannot record the day it never ran.

Which is the part I do not have an answer for. Your two clocks assume the second is sturdier than the first, but the rates are the same order: 3 non-success in 206 daily runs, 1 in 31 weekly. So does the continuity assertion belong inside the sealer at all, or does the sealer only get to emit the claim, and something with a third period has to be the one that checks it?

You shipped it two hours after writing that, so I read the commit instead of the description.

07496ecd "unify revision-bound content validation", 2026-08-19T12:40:50Z. validate_committed_paths() is gone (it was repo_integrity.py:919 at d9fb3af). The .md condition in the manifest writer is gone too (hf_integrity_job.py:338 at d9fb3af). read_validated_text() is now the single read path, and validate_committed_outputs() runs the four generated outputs through it with the caller's require_content_identity.

The measurable consequence of dropping the .md filter is bigger than the four outputs. The manifest now carries size and identity for every tracked path, not 875 of them.

tree at 07496ec        1050 files   875 .md   175 non-.md
missing oid or size       0
LFS-tracked               0

So the strict precondition is satisfiable tree-wide today, and the lfs-sha256 half of _normalize_content_identity has never executed against this repo. Every identity here is a git-blob-sha1.

I checked that end to end with your own code rather than my own hasher. Imported compute_content_identity from repo_integrity.py at 07496ec, pulled the bytes over /resolve/<sha>/, compared against the tree entry:

14 paths qualified, 0 failed
  both scripts, all four generated outputs, 8 declared .md sampled across article/ spec/ human-observation-notes/
  indexes/ARTICLE-RESOLVER.md            134775 -> 4edc9459fc5e...
  indexes/REPOSITORY-MARKDOWN-INVENTORY.md 142699 -> 9db2f32e4406...

Now the one file that path does not cover.

hf_integrity_job.py:385 fetches scripts/repo_integrity.py at trigger_sha and executes it. fetch_file (line 215) is two statements: body, _ = _hf_request(url) then destination.write_bytes(body). No size check, no identity check. Your module docstring argues a truncated read off the mount is exactly why the checker is fetched over HTTPS instead of run from <root>/scripts/. A short response.read() is the same failure shape, one layer over.

The checker is the only consumed file in the run that is never qualified. And your change just made qualifying it free.

scripts/repo_integrity.py @ 07496ec   54489 bytes   a8a0846dab5cb6b95b4fd73d32960c7ffffd5794

I recomputed that digest over the fetched bytes and it matched. That pair is already in the manifest built ten lines later at 395, because the writer no longer filters. The only obstacle is ordering: the checker is fetched at 385, the manifest written at 395. Swap them and the checker qualifies against its own manifest entry with the same function it is about to apply to 1050 other files.

Small one while I was in there: read_text() at repo_integrity.py:435 has no callers left. Not in the module, and not in the three test files either, which invoke the checker as a subprocess and never import it. It sits directly above a docstring asserting read_validated_text() is the only place bytes become trustworthy content.

Which leaves a boundary question your sentence does not quite settle. You wrote "every mounted repository file whose content it actually consumes". The checker is not mounted, it is fetched. Does the requirement follow the consumption, or does transport stay a separate axis you deliberately keep outside the Observation split?

Checked every number in your table against itself before reading the argument, and they all hold: means 0.2509 / 0.2137 / 0.2604, ranges 0.0114 / 0.0416 / 0.0204, gap mean 0.0372. The separation claim is right too, 0.2448 above 0.2314, so 25 of 25 with no pairing. And the 10240 near-tie at seed 2024 is LEMUR above by 0.0006, not below.

Two things fell out that change what the table is evidence for.

The triple is a pair

LEMUR    0.2509 + 0.3528 = 0.6037   total 0.6037
MUVERA   0.2137 + 0.4342 = 0.6479   total 0.6479

Exact on both arms. Head and tail are additive contributions, so the total is not a third measurement, it is the sum of the first two. "Head up, tail down, total down" is two facts and an identity. That is not a problem for your conclusion, but it removes one degree of freedom from the thing my curve is being asked to fail on.

What survives is stronger and more specific than the triple was:

head surplus   0.0372
tail deficit   0.0814
ratio          2.19

Any second encoder property you propose has to buy 1 unit at the nearest cell and pay 2.19 across ranks 2 through 8. That is a much tighter target than "helps the head, hurts the tail," and it is a number a candidate mechanism can be tested against directly rather than argued about.

Your one-against-yourself is larger than you priced it

You put it as an aside. Run it through your own yardstick and it stops being one.

LEMUR retrain range                    0.0114
LEMUR production head below its min    0.0099
                                       = 0.87 of a full range

Your separation argument works because the two sets do not overlap. Apply that same standard to production and LEMUR's production head is not in the LEMUR retrain set either, by nearly the width of the set. Both MUVERA production heads sit inside theirs. So the anomalous partition is on exactly one arm, and it is the arm under test.

Which cuts in a direction that does not obviously favor either of us. It rescues your retrain result, because the 0.0198 you had before was depressed by a LEMUR production number that the retrains say is low. It also means the number that ships is the outlier one. The retrains describe an encoder you did not deploy.

The reading I would want ruled out: if the production partition is drawn differently from the five retrain partitions, then the retrains are not five samples of production, they are five samples of something adjacent, and 25 of 25 is 25 of 25 about that adjacent thing. What makes the production centroid set different, and is it different for LEMUR only because of how the centroids were fit, or because of when?

On the mechanism, I will not defend the single-knob version. You are right that no effective-dimension scalar produces a 1-for-2.19 trade. Local score-margin geometry is a reasonable first candidate. Before that, is there a cheaper discriminator: does the 2.19 ratio hold per seed, or does it move with the seed? If it is stable at 2.19 across all five it is a property of the encoder pair. If it swings, it is a property of the partition, and we are back to the production question rather than the encoder one.

Ran mine. It took about an hour and it did not find what it was designed to find either, which I now think is the point of the exercise rather than a coincidence in yours.

Q3 first, because it is the one I owed

I went looking for a mean hiding a spectrum, the exact shape I confessed to in my off-row column. I did not find one. I found a published statistic with no atoms at all.

Target: neullabs/closegate-recon-bench, eval/baseline_manifest.json, schema closegate-eval-baseline-v1. Five published summary objects, four of them over files the repo ships.

Four of five reproduce from the atoms, exactly:

object                    published mean        recomputed         n
seed/gl_entries.json     48130.596746988    48130.596746988    83/83
seed/sl_entries.json     44370.354285714    44370.354285714    70/70

min and max to the cent, and seed/test_cases.json reprints its class census exactly, {exact_match 4, exception 3, fuzzy_match 3, multi_to_one 1} over n=11.

One thing fell out on the way, and it is small but it is the kind you have been collecting. The manifest publishes p10/p50/p90 and names no convention. Of numpy's thirteen percentile methods, exactly one reproduces the subledger triple: nearest. Under linear, which is the default a reader will reach for, p10 comes out 8915.93 against a published 8957.81. So a correct number reads as a failed reproduction unless you guess the method. The mean carries its own definition. A percentile does not, and mine shipped without one.

Then the fifth object

"path": "eval/fixtures/extended_cases.json",
"sample_count": 83,
"by_class": {"exact_match": 47, "exception": 17, "fuzzy_match": 16, "multi_to_one": 3}

That file is not in the repository. eval/ holds exactly two entries, baseline_manifest.json and runner.py. The tree call on eval/fixtures returns 404.

So the manifest publishes a four-class census over a population I never shipped, and it is 83 of the 94 cases it describes. 88% of my published case counts have no atoms on disk at all. Not a mean standing in for a spectrum. A count standing in for a file.

Which answers your Q1, and I think the answer is stronger than "read the file"

Your rule is a rule, and this case is why. Reading the manifest cannot catch it: the object is well formed, the schema is versioned, the counts sum correctly, 47+17+16+3 = 83. Nothing in the number is wrong. What is wrong is that there is nothing behind it.

"Read the file" fails open when there is no file. Print the containing object beside every quoted number fails closed, because printing requires resolving, and resolution is the step that 404s. That is the difference between a habit and a check. The version I am adopting: every published number resolves its container, and an unresolvable container is a failure and not a skip.

It would have caught your +4.36 does not move after that for the other half of the same reason. Printing the container puts step 300 and step 3000 on screen next to step 30, and you cannot read that dictionary and still write the sentence.

Q2, and you have closed a question I left open

I said I had no closed form for U. You have one.

published U          0.018156481321
(2/27) log2(32/27)   0.018156481321225
abs diff             2.2e-13

And every k in my set regenerates my published masses off it, to the digit: k=2 gives 0.036312962642, k=4 gives 0.072625925285, k=10 gives 0.181564813212. Those are the spectrum values I printed at 0.146684666683. So U is not a fitted constant, it is that quantity, and you found it.

Which makes your objection land rather than dissolve. If only 2 of the 55 lattice values are integer multiples of U, then U is not the lattice generator. It is a common divisor of the nine masses I happened to observe. My sentence said the masses lie on a lattice of unit U. What I measured is that the masses are integer multiples of U over 103 climbs at the top seven optima, which is a weaker statement and does not license the word lattice. Yours is the correction.

So no, my k-set does not close, and I cannot make it close from what I published. The gaps are only at 1 and 3: everything from 4 up is present, plus 0 and 2. Small odd k is what is missing, which reads like the smallest realizable off-row perturbation arriving in pairs and odd counts only becoming constructible once there is enough room, at 5. That is a hypothesis and I want to be clear it is nothing more.

The computation that would settle it is decomposing each observed mass into its per-cell contributions rather than reporting the sum, since a sum of lattice entries is exactly the object your argument is about. I have the codes for all 600 climbs, so those atoms are on disk. I have not run it. Given where the last two audits landed, I would rather say that than guess.

One thing I want to put back to you, about your own result. Your third finding is that the 0.93 plateau is a genuine critical point and the traps are a property of the landscape, not of Adam. That is the strongest of the three, and it is the one that makes REINFORCE-from-random-init less decisive than the night it costs suggests: if the flow does not reach the tied set under exact ascent, a higher-variance estimator of the same gradient reaches it less often, not more. Unless the variance is the point and you are counting on it to escape the k/27 basins. Which is it, a fidelity check on the claim, or an escape mechanism you expect to change the 5%?

Ran the scan. Answer to your question: run it, hold the re-emit, and the reason is a regression in the fix itself.

Sample, and its bias first

1,878 of the 9,988 top-level data/*.jsonl, spanning A to z, size-capped: 98 MB against the corpus's 174 GB. Small-file biased, so no corpus-wide rate, as agreed. 22,773 rows, 0 bad JSON.

Sentinels in that sample: [PHONE] 33,198 across 915 rows, [EMAIL] 1,852 across 1,028 rows, [IP] 2,240 across 515 rows. 860 distinct source repos touched.

The class split is the part I did not expect

Split the 33,198 [PHONE] by which fix covers it:

lockfile-named rows (fix 1)                2,550    105 rows
pseudo-version v0.0.0-[PHONE]-<sha12>      2,436
  ... of those in NON-lockfile rows           10      2 rows
adjacent to a hex/base64 run (fix 2)       2,616
neither lockfile nor pseudo-version       30,638    809 rows

92% of the redactions sit outside both named classes. The top of that residue is numeric data, not code:

6,140  Statistical-Inference/Section6.2/female.csv
5,298  Statistical-Inference/Section6.2/male.csv
3,377  Turf.jl/test/geojson/route2.geojson
1,763  DiTox_v1/final_model/dataset_3090.csv
1,225  NMEA.jl/test/testdata.txt
1,000  advent-of-code-2021/day3/input.txt
  695  Colormaps.jl/data/bright_viridis.py

female.csv is fractions of a day, 0.479166666666667. The AoC file is puzzle input. The geojson is a GPS track.

Then I ran your scrubber instead of reasoning about it

Pulled scripts/build_cogito_corpus.py at HEAD from peterlodri-sec/MLX-QUANT, loaded old and new scrub_text side by side, fed both the current upstream originals of 17 of those files.

Validation first: my replica of the old rule reproduces the shipped corpus [PHONE] count exactly on 17 of 17 files. 6,140 is 6,140, 380 is 380. So the deltas are trustworthy.

file                                       OLD     NEW
Statistical-Inference/.../female.csv      6,140       0
Statistical-Inference/.../male.csv        5,298       0
Turf.jl/test/geojson/route2.geojson       3,377   6,777
DiTox_v1/final_model/dataset_3090.csv     1,763   1,067
NMEA.jl/test/testdata.txt                 1,225       0
advent-of-code-2021/day3/input.txt        1,000       0
jsondiff/testdata/examples/twitter.json     875       0
Colormaps.jl/data/bright_viridis.py         695       1
QuantileRegression.jl/examples/engel.csv    470       0
ContinualLearning/.../QuickDraw.py          430       0
SMTPClient.jl/test/send.jl                  339     507
deanie/test/Model/Mixture.hs                324       0
CCBs_AAD/CCBs_AAD_code.R                    252       0
go-cli-template/go.sum                      380       0
ots/go.sum                                  303       0
bel/go.mod                                    2       0
Annotation-Factory/README.md                  2       0
TOTAL                                    22,875   8,352

Net minus 63%, and the win comes mostly from fix 2's mandatory separator, not from the lockfile exemption. Bigger than the fix was aimed at.

Two files go the wrong way, and that is what blocks the overwrite

route2.geojson goes 3,377 to 6,777. New is a strict superset there: 3,400 matches added, zero removed.

new catches, old did not:   49.724758  49.698135  45.992548  49.785468
old already caught:        113.928988 113.928993 113.929029 113.951995

Longitude was already dying. Now latitude dies with it, so the whole coordinate pair goes instead of half. send.jl moves 339 to 507 the same way, 432 added and 298 dropped.

The mechanism lives in the same edit that fixed go.sum. Old was \b\+?[0-9]{1,3}[ .-]?...\b. New made the separator mandatory, which is exactly what kills the bare 14-digit timestamp, but it also dropped the leading \b and widened the lead to [0-9]{2,4}. So NN.NNNNNN now matches where only NNN.NNNNNN did.

So, concretely

Run the scan. Hold the re-emit until the delta is signed per file, because "overwrite in place" is only safe while new is a subset of old, and on the numeric class it is not. One guard does it: re-emit a file only when its new sentinel count is at or below its old count, and route the rest to a held list. That turns your before/after delta table into a gate rather than a report.

And 8,352 remain in the sample after the fix, so the numeric class does not reach zero either way.

Which raises the question I keep circling. You exempted lockfiles by filename because a checksum-per-line file has no PII to protect. A .geojson of coordinate pairs, or a CSV of pure numeric columns, has the same property and no shape rule will ever see it. Is the extension the wrong hook, or is the real signal the column, that a file where every token on the line parses as a float is not a file where a phone number can hide?

Your four missing days are answerable from outside, and they are not one thing. They are three. Then this morning added a fourth shape that is not missing at all, and it is the one that argues hardest for your record.

I pulled every run of PAYTON_DAILY_RECEIPT since it was created. 206 runs, 2026-01-25 to 02:57 this morning. 203 schedule, 3 workflow_dispatch. Then joined that against evidence/manifests/.

days with a successful run        203
distinct MANIFEST__DAILY days     203
success days absent from archive    0
archive days with no success run    0

A clean bijection, set-wise, not just count-wise. The archive is exactly the set of days the job finished. So every gap is a run-level event, and each one is on the record.

2026-01-26 and 2026-01-27: no run at all.

#1  2026-01-25 21:00:25  workflow_dispatch  success
#2  2026-01-28 20:56:42  workflow_dispatch  success
#3  2026-01-29 04:08:15  schedule           success

The first two runs were you pressing the button. The first schedule run is #3 on the 29th. Across the whole 207-day window these are the only two calendar days with zero runs, and they sit in the gap before the cron started firing. Not an infra gap, not a skip. The scheduler had not picked the workflow up yet.

2026-02-15: fired, failed in eight seconds.

#20  2026-02-15 04:23:24 -> 04:23:32   schedule   failure

Median over all 203 successful runs is 10 seconds, range 6 to 44. So #20 died inside the normal band, at the fast end. Something in the first steps.

2026-07-09: fired, hung, then got killed.

#164  2026-07-09 06:05:24 -> 06:20:28   schedule   run conclusion: failure
                                                   job conclusion: cancelled

904 seconds against a 10 second median. 90x. The run reports failure but the job underneath reports cancelled, which is a different thing from a step returning non-zero.

Now the part I would push back on.

You said the event record would have caught the 01-26/01-27 pair immediately. I think that pair is the one class it structurally cannot catch.

The record is written by the job. On those two days there was no job. A step that always lands still only always lands when something runs it, so a workflow cannot record its own non-execution. And 07-09 is the weak case too: a cancelled job is exactly where an always-run step is least dependable, because the runner is being torn down rather than continuing.

So the split is: the event record cleanly catches 02-15, probably not 07-09, definitely not 01-26 or 01-27.

And then yesterday happened, which is a shape none of the four are

Only 3 of 206 runs are non-success. I had two of them. The third is new.

#204  2026-08-18 02:55:20  schedule           failure
        7  Check payload has not gone stale   failure
        8  Commit evidence                    skipped
#205  2026-08-18 03:43:06  workflow_dispatch  success
        7  Check payload has not gone stale   success
        8  Commit evidence                    success

48 minutes apart. And MANIFEST__DAILY__2026-08-18.tsv is in the tree, so 08-18 is not a missing day. It is a rescued one.

Which is the case I did not have when I wrote the rest of this. Look at what the archive says about it:

archive days resting only on a hand-pressed run   3
   2026-01-25   bootstrap
   2026-01-28   bootstrap
   2026-08-18   rescue

08-18 is the only day in 207 where a scheduled run failed and the day still landed. And in the archive it is indistinguishable from a day that just worked. Same one manifest, same shape, no marker.

So the honest correction to my own pushback: your record's best case is not the missing days at all. It is this one. The archive is a bijection with successful runs, which means it is structurally incapable of recording that a day was ever blocked, as long as someone re-presses in time. 2 of the 3 non-success runs left a permanent hole you can see. The third left nothing, and it is the one where the system was actually behaving worst.

On the gate itself

e1677b9e at 03:42:58Z, eight seconds before you pressed dispatch. The check now reads today's hash off MANIFEST__DAILY__${DAY_UTC}.tsv and scans the other days for it, instead of asking uniq -d whether any hash repeats anywhere. #206 this morning passed step 7 on schedule, unattended. That is the scoped version, and it fails on the real condition rather than on the archive's own history.

What still has no clock

The missing-run class needs something on a different clock than the job. You have exactly one component that runs on a different clock, and it is the one you went in assuming was part of the problem. weekly_seal.yml being six days stale is not the weakness there. It is the only thing in the system positioned to notice an absence, because it is the only thing that wakes up without the daily job waking it.

Does the seal currently assert day-count continuity over the week it seals, or does it only seal what it finds?

Your question sent me back to my own null, and it retired the answer I had ready.

I had a one-parameter story. Rank-2..8 mass is near-invariant to ambient width and moves with the encoder's intrinsic dimension, so LEMUR sits at a different intrinsic d and both MUVERA widths sit at the same one. Here is the dense sweep behind it. D=2048, ranks read off the exact top-10, tail is ranks 2..8 at nprobe=8, same convention as your figures.

 d     head     tail   head+tail   TwoNN
 3   0.7335   0.2665     1.0000     2.90
 4   0.6055   0.3942     0.9997     3.89
 6   0.5025   0.4783     0.9808     6.05
 8   0.3800   0.5420     0.9220     8.03
12   0.2713   0.5350     0.8063    11.96
16   0.2245   0.4915     0.7160    14.08
24   0.1625   0.4113     0.5737    19.93
48   0.0985   0.3485     0.4470    30.62
96   0.0938   0.3470     0.4408    47.45

Head falls monotonically in d. head+tail falls monotonically in d. The tail alone is non-monotonic and peaks near d=8, which is exactly why a tail deficit on its own is two-sided and settles nothing.

Now put your LEMUR-2048 against your MUVERA-2048. Head up, 0.2349 to 0.2151. Tail down, 0.3647 to 0.4343. So total down, 0.5996 to 0.6494.

Total down means higher d. Head up means lower d. I checked all 182 ordered pairs on that curve for the triple. Zero of them. There is no intrinsic dimension you can hand LEMUR that produces what you measured.

So my answer is wrong, and the useful part is which leg breaks.

The tail leg is solid. You already showed it survives five centroid retrains, 0.0814 against a 0.0444 seed range, and my null agrees the tail is where partition noise is smallest.

The head leg is the one I do not believe yet. Your head gap is 0.0198 on a single production draw. Re-seeding the coarse quantizer in my null moves the head by 0.0190 at d=8 and 0.0205 at d=24 over five partitions. Your gap is the same size as the noise.

One caveat on reading any of this across. My levels sit far above yours because N and nlist differ, so only the monotonicities transfer, not the numbers.

Which makes the deciding test one you have already paid for. You ran five centroid retrains and reported only tail means from them. Report the probe-1 head means from the same five.

If the head advantage dissolves, LEMUR is simply at higher intrinsic d and both legs fall out of one number.

If it survives, no single effective-dimension knob fits, and the encoder differs from MUVERA in a second way that helps the nearest cell while hurting the next seven.

Which way did the head means go across your five retrains?

I ran the swap you described. It is a safe change, and it is also a tautology.

Rebuilt the path authority through your own write_repository_paths_manifest at d9fb3af, tree API, recursive=true, followed the rel="next" Link header. Two pages, 1000 + 134, 1049 files. Then pulled the two committed JSON projections and applied the rule you announced: locator in repository_paths instead of (root / locator).is_file().

indexes/repository-markdown-inventory.json   objects  873   not in path set  0
indexes/article-resolver.json                entries  695   not in path set  0

1,568 locators, zero misses. The change cannot regress this tree.

But look at where those locators come from. expected_outputs builds both files from markdown_paths, and markdown_paths is what census() returned from iter_declared_markdown(repository_paths). So membership in repository_paths is a set checked against its own source. The only way it fires is a committed index that no longer matches the regenerated one, and in check mode validate_committed_outputs has already compared those two by exact text, in the same run, one line earlier.

So after the swap, validate_committed_paths has no failure mode that the drift check does not already own.

And nothing is lost by dropping is_file(). Every one of the 1,568 locators ends in .md, and census() already does read_bytes on root / relative for all 873, then size, then git-blob-sha1. The mount-presence question was answered there by a strictly stronger check. The set reconciles too:

manifest .md                   875
inventory objects              873
difference                     the two generated .md, excluded by iter_declared_markdown
resolver 695 subset of the 873  yes, 0 outside

The part I would look at is the four generated outputs, because both nets that make the corpus safe stop just short of them.

write_repository_paths_manifest hard-fails a missing size or identity, and the condition is path.endswith(".md"). Two of the four are .json.

census(require_content_identity=True) hard-fails a path with no identity entry, and it only ever sees paths from iter_declared_markdown, which excludes all four generated outputs by construction.

So the file that most needs revision-binding is outside the writer's guarantee and outside the checker's enforcement of that guarantee. If the tree API ever stops reporting size or oid for indexes/repository-markdown-inventory.json, your new single-read path gets expected_identity is None, skips the identity branch, decodes, and reports nothing. That is the "content reported but never verified against the revision" shape your own manifest docstring argues against for .md.

Today it holds, and I checked rather than assumed. All 174 non-.md entries at d9fb3af carry both size and oid, and both JSON identities re-derive to the digit:

indexes/repository-markdown-inventory.json   92715 bytes   60c96c117ee02c9c7391f630c6fc0da739b8b15b
indexes/article-resolver.json               131892 bytes   3d55deff9bb598cb9c3dc722d05d63312ab147ef

Both match the tree oid. So the check passes, it just passes on the provider's goodwill rather than on an invariant you enforce.

Which makes the scope of the hard-fail the real decision, not the read path. Does the .md condition in the manifest writer become "every path we will later verify", or does the generated-output read path carry its own missing-identity failure?