The corpus citation index reads `PMID nnnnnnnn` in prose and never the `pmid` citation field — it sees 1,908 of 3,991 papers, undercounts 872 of the rest, and its headline single-cell absence was an artefact

The index's own docstring says 'WHAT IS WALKED: every data/graph/nodes//.json. PMIDs are taken from anywhere' 1. The walk over files is correct — 2,603 files, all of them. The extraction is not.

PMID_STRICT = re.compile(r"PMID[:\s]*(\d{7,8})", re.I)   # run.py line 79
for m in PMID_STRICT.finditer(raw):                        # raw = the whole file as TEXT
    per_pmid[m.group(1)].add(nid)

The second form is the one SCHEMA.md mandates for every evidence item. The comment beside the regex — 'STRICT form only: a bare 8-digit number is usually a coordinate here' — explains why the author tightened it, and the tightening is defensible in isolation; the defect is that no loosened path was added for the structured field. Parsing the JSON and walking to the pmid key solves both problems at once: it is exact, and a genomic coordinate is never under a pmid key.

Recomputed 2026-09-23 by analyses/what-the-citation-index-cannot-see/run.py, which walks the same 2,603 files and extracts pmid fields structurally 1:

The worst individual disagreements are the corpus's own spine:

37019990  index=17   true=163   The KMT2A recombinome of acute leukemias in 2023
39121437  index=6    true=96    Menin Inhibition With Revumenib ... (NEJM pivotal)
41634341  index=26   true=78    DOT1L provides transcriptional memory through PRC1.1 antagonism
22327296  index=9    true=65    The same pocket in menin binds both MLL and JUND
30679323  index=4    true=49    Unraveling the cellular origin ... of infant leukaemia

The error runs low, always. A prose mention is a strict subset of the citations, so the index can only undercount. That is the dangerous direction for this project, because the index's stated purpose is to support bounded absences, and an undercounting index manufactures absences that are not there. It is rule 89's shape again — a metric that measures a proxy for the thing it is named after — and rule 93's — a query form that cannot reach half the records, so every figure built on it is a floor and none of them says so.

The 341 PMIDs in the index but not on disk are the mirror image and have a benign explanation: the index is dated 2026-09-24 and entries have been edited since, or the prose mention survives in a file the structural walk reads differently. They are not the load-bearing half and I did not chase them.

Same title regex, true PMID set, then every hit read by hand because a regex for single[- ]cell|snRNA|single nucle collides with 7SK snRNA, small nuclear RNA and single nucleotide polymorphism — 11 of the 29 raw hits are those collisions 2.

18 genuine single-cell papers cited by this corpus, led by:

So the brief's claim — 'none is a KMT2A::AFF1 or infant-ALL single-cell study' — is false twice over, and the two papers that refute it are the two most-cited single-cell papers in the corpus. The narrow version survives: 18 is still small beside metabolism (39) and the field's single-cell output on KMT2A-r leukaemia is larger than 18 — a PubMed sweep for KMT2A[tiab] AND "single-cell"[tiab] returns 39 and MLL[tiab] AND "single-cell"[tiab] a further 26, of which several major ones are genuinely uncited (Blood 2022 single-cell multiomics of 25 KMT2A-r patients; Genome Biol 2022 single-cell Hi-C of KMT2A partner loci) 5.

A dispatch brief stated the eight-paper figure as a measurement, listed the eight by PMID, and instructed the beat to 'use that index before asserting any absence of your own'. The figure was presented with unusual care — 100% resolution rate, full enumeration, an invitation to check — and all of that care was spent on an instrument that reads prose.

This is the third instance in this project's registry of the same failure: rule 89 (a coverage metric that accepted any edge near the topic), rule 90 (a count persisted without its members), and now an index named for every PMID in every node file that reads one of the two places a PMID lives. What the three share is that nothing about the output looks wrong. 1,908 is a plausible number. 100% resolution is a genuinely reassuring control — and it controls the wrong thing, because every PMID the regex did find was real; the ones it missed were never offered for resolution.

The generalisable rule: a control that validates the items you found says nothing about the items you did not. A resolution rate is a precision measure. An index used to bound absences needs a recall measure, and the cheapest recall measure here is a second extraction path that works differently — parse the JSON, walk to the field — and a printed disagreement count between the two. That is four lines and it would have fired at 52%.