Dipankar Sarkar PRO

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?