Repairing 85 defective citation blocks, and the finding that the queue's own numbers were wrong in three directions at once

This is the part worth more than the fixes. 76 truncations are not 76 accidents, and the pattern in the data names the process.

They cluster by PMID, not by entry. The 76 defects come from only 48 distinct PMIDs. PMID 17590169 is truncated at the same 82-character point in four different entries; 25594862 at the same 70 characters in four; 40536420 at 121 characters in seven; 41533567 at 71 in four; 39121437 at 90 in six. A title cut at exactly the same character in seven entries was not typed seven times. It was fetched once, stored short, and copied. The cut points are not random either - they sit at 70, 80, 82, 86, 88, 90, 95, 100 and 121 characters, which is the shape of display truncation, not of typing.

The copy travels with the prose. The brief's rule is 'reuse the prose from a sibling entry if you like; re-fetch the ids.' The evidence here is that in practice the citation block travels with the prose as one unit, because it sits inside the block being copied. Every one of the multi-entry clusters is a case where a whole counter-evidence note was reused verbatim - the four WRAD entries (gene-ash2l, gene-dpy30, gene-rbbp5, gene-wdr5) carry a 1,100-character note that is byte-identical across all four. The rule as written asks an author to disassemble a block they are copying wholesale. That is the wrong unit of discipline.

Nothing could see it. verify-citations.py uses idf-weighted overlap between the stored and real title, and a correct first 80 characters clears the threshold easily - it reported 0 mismatches over all 76. check-counter-note-support.py could see only the subset where the same PMID appears twice in one evidence item. A checker that compares the stored title to the FETCHED title with an exact-prefix test finds all 76 in one pass over cached esummary output, costs nothing extra, and is the single change that would have prevented this beat.

n_suspect went UP by two and that is the instrument, not a regression. The four corrective notes written in this beat, and this entry's own counter-notes, quote PMC ids, percentages and gene symbols that are in the papers' bodies and not in their abstracts, so they score exactly like the defect they document. A note that names its source precisely is penalised by a scorer built on abstract overlap.

The 12 remaining uncited notes are the right answer, not a remainder. Ten are bounded absences - 'searched, found nothing, here are the queries and the date' - and two are falsifier lists resting on the UniProt record the parent item already cites. Each of the ten now closes with an explicit sentence saying no citation is attached because there is nothing to cite, because an uncited note and an unciteable note are indistinguishable on the page. Three of the original 15 did have a citable source and got one: fusion-nup98-kdm5a E3 and fusion-nup98-nsd1 E3 asserted that the field has challenged transcriptional-condensate claims as overexpression artefacts, which is exactly PMID 29930090 (LCD interactions at physiological expression, no detectable phase separation) and PMID 36526633 (1,6-hexanediol and classical FRAP cannot separate LLPS from clustered binding); localization-nuclear-speckles-kmt2a-r E1's note is a reading of its own parent paper and now says so with that paper attached.

The checker's own entry warned the yield would be low and that several flagged tokens would be recombinome percentages that do come from the cited paper's tables. That is what happened. 21 of 25 are sound. Fifteen are scope or logic arguments carrying no imported fact - base-rate arguments, ascertainment arguments, analogy-limit arguments - and six quote numbers verified in this session against the cited paper's full text. Two more (cell-type-fetal-liver-hsc E1, mechanism-kmt2a-subnuclear-localization E5) already carried sourcing corrections written by the Q40 sweep and needed nothing.

Four were real, and one of them was worse than a mis-citation:

1. target-fusion-junction-epitope E1 - a wrong gene symbol, not just a wrong citation. The note said the minor breakpoint cluster region is 'dominated by USP2, AFDN and SEPTIN6'. PMC10169636, read 2026-09-20: 'A total of 47 breakpoints were found in the minor BCR of KMT2A. The most frequent partner genes are USP2 (n = 29), AFDN (n = 9), and USP8 (n = 3).' The third partner is USP8. SEPTIN6 is a major-BCR partner (n = 19) and appears nowhere in the minor BCR. Corrected in place, and the recombinome added as a separate note because none of these facts is in Milne et al. 2010, the paper the note cited.
2. breakpoint-kmt2a-partner-exon-preference E1 - arithmetic. The note's per-base-pair depletion was given as 2.9-fold. From the paper's own figures (A = 1,761 bp / 37.2%; B = 679 bp / 19.8%; C = 5,026 bp / 39.5%, all quoted verbatim from PMC10169636) it is 2.7-fold against region A alone and 3.0-fold against A+B. Direction and argument unchanged; the number is now right and both comparators are stated.
3. epi-kmt2a-rearranged-acute-leukemia-all-ages E4 - the KMT2A::SEPTIN11 cytogenetic-collision fact is from the recombinome, not from the 2013 review whose PMID it wore. Recombinome partner table: SEPTIN11 at t(4;11)(q21.1;q23.3), AFF1 at t(4;11)(q21.3-q22.1;q23.3) - both read t(4;11)(q21;q23) at clinical banding resolution.
4. fusion-kmt2a-mllt3 E1 - a figure that cannot be sourced. 'KMT2A-rearranged disease accounts for about 10% of acute leukaemias of ambiguous lineage' is not in the recombinome, not in the iBFM-AMBI2012 report (PMID 29720486, abstract re-read this session), and a PubMed search did not resolve it. Marked SOURCING NOT FOUND rather than deleted, and the direction the paper DOES measure is added beside it: 61 of 3,401 KMT2A-rearranged patients were MPAL, 35 of them infants.

No original note was deleted in any of the four.

The standing rule is to take the title from the fetched record. The graph-wide sweep produced one case where following it would have introduced a defect.

PMID 32285100's ArticleTitle from efetch ends ...preimplantation lethality in mice\u2020. - a U+2020 DAGGER footnote marker sitting inside the title, before the full stop. Three citations in gene-rbbp4 and gene-rbbp7 store the title without it, which is the correct human title. The repair was applied, inspected, and reverted. Byte-identity with PubMed is the goal for identifiers; for titles it is the goal only up to publisher footnote junk, and a repair script that does not look at what it is about to write will happily propagate a dagger into three entries.

Recorded because a repair beat is exactly where this must not happen, and it did.

While drafting the counter-example above, this entry's citation block for PMID 32285100 was assembled from the surrounding prose rather than from the record that had just been fetched, and the author list came out as Rodriguez D, Braden C, Luo SW, Lakshmipathy U. The real authors are Miao X, Sun T, Barletta H, Mager J, Cui W (Biol Reprod 2020, 10.1093/biolre/ioaa046). Title, journal, year, DOI and PMID were all correct; only the author list was invented, which is the shape that passes every check except the author comparison.

It was caught by re-fetching before hand-back, and verify-citations.py --strict would have caught it on the post-write run. Both defences held. The reason it is written down rather than quietly fixed is that the motion that produced it is identical to the one the brief names: the record had been fetched minutes earlier and one field was typed from memory instead of copied out of it. The previous incident of this exact kind was also committed by a beat whose subject was citation hygiene. Twice is a pattern, and the pattern is that writing about the rule does not substitute for applying it.

• The --limit 260 in the standing invocation samples 40% of the population. check-counter-note-support.py reports same-PMID counter-notes to score: 650 and then scores the first 260 in file-path order. Every number in the report - including n_suspect and the ranked queue - describes an alphabetically biased 40% sample, and the report does not say so. Entries under data/graph/nodes/t* and later are never reached. A future run should use --limit 700 or none.
• find-contradictions.py A-class, 1 hit, pre-existing: breakpoint-kmt2a-partner-exon-preference still asserts 'deviates from the mean' in its body while its own counter-note argues that comparator is circular. This beat does not change claims, so it is reported rather than edited. It is a methodological dispute and arguably legitimate, but the body should name the comparator explicitly.
• Six titles in the graph carried words PubMed does not have, which is the mirror of truncation and equally invisible: PMID 25305204 stored as ...MLL leukemia and HIV-1 in four entries (the publisher-deposited XML, via efetch db=pmc on PMC4263982, gives ...and HIV), and PMID 37740239 stored as ...acute lymphoblastic leukemia cells in two (PMC10517487 body XML gives ...leukemia). Both were corrected. Note the route: EPMC fullTextXML returned HTTP 500 on PMC4263982 and efetch db=pmc recovered it with no <body> but a usable <article-title> - route 3 of the five-route test doing exactly what it exists for.
• ir.kuraoncology.com returns HTTP 403 to every automated fetch tried (urllib, curl with a browser UA, WebFetch timeout at 60 s). The press release cited in reg-orphan-drug-designation E8 could not be verified this session. FDA's own orphan-designation search (OOPD_Results.cfm) was re-tried by HTTP POST and again returned a redirect with no rows, confirming the note already in that entry.
• A repository URL in the graph does not resolve. Eight entries cite https://github.com/xX-its-amit-Xx/oncofusion-knowledge-graph/... for this project's own scripts and reports. The configured git remote is git@github.com:xX-its-amit-Xx/oncofusion-knowledge-graph.git, and other entries use that form. Both spellings are in the graph; one of them is wrong and it is not the one that matches the remote. Not edited here - those entries belong to other beats - but it is the same defect class as a wrong DOI beside a right PMID: internally plausible, never dereferenced.

1. Add an exact-prefix title test to verify-citations.py. It already fetches every real title. stored != real and real.startswith(stored) is one line and finds all 76 of these; idf overlap finds none of them. Report it separately from a mismatch, because it is a different defect with a different cause.
2. Fix check-counter-note-support.py's truncation detector to compare against PubMed, not against the sibling title. As written it cannot distinguish a truncation from a full stop, it mislabels the correct string as the defect whenever an annotation was written into the title, and it misses every truncation that does not happen to appear twice in one evidence item. Three failure modes, one cause.
3. Give the citation schema a locator field and stop writing (Discussion) into title. Five blocks did it here; the information is worth keeping and the title field is the wrong place for it.
4. Widen CAPS_NOISE. Q40, Q42, PMID, PMC, ZERO, WHERE, ALREADY, FOUND, RETAIN and DEPLETED are this project's own emphasis and beat-naming conventions and they account for a large share of the unsupported_specifics tokens in the suspect queue. Every one of them makes a correctly-sourced note look like an imported fact.