4.8 KiB
Claude's verification of Codex's two claims — 2026-08-04
Both claims reproduce. Verified against
ingestion/data/processed/chunks.jsonl as regenerated at 09:53 today
(sha256 e474c83790b450d3…, 15,066 chunks), not against the earlier artifact.
Claim 1 — citations carry the monograph range, not the chunk's page
Confirmed, and wider than stated.
| measure | result |
|---|---|
chunks whose printed_page_range spans more than one page |
14,815 / 15,066 (98.3%) |
| widest | insulin__ten_chung_quoc_te__0 → printed 810–816, seven pages |
| multi-part sections where every part carries an identical range | 1,496 / 1,496 (100%) |
The insulin case is the clearest demonstration: Tên chung quốc tế is a
one-line field whose heading sits on printed page 810, and it is cited as
spanning seven pages. The 100% figure on multi-part sections is the proof of
mechanism — chunk_section reads monograph.source_page_range, so every part
of a split section inherits the same span by construction.
ADR 0004 named this under "Known gap — sub-chunk page precision" and said
per-line page tracking does not exist in SectionSpan/Heading. That is still
the blocker for sub-chunks. But heading_physical_page is already carried per
chunk and is chunk-relevant for part_index == 0, so the common case has a
better answer available today than the monograph span.
Worth adding to §6 of the delivery plan: the existing gate is
citation_uses_physical_page = 0, which checks physical-vs-printed. It does
not check precision. A citation can use the printed folio and still send a
clinician to a seven-page range.
Claim 2 — ARSENIC TRIOXYD descriptors carry cell values
Confirmed, exactly two, exactly that drug. I built an independent detector (duplicate cells within a header row; header cells drawn from the ADR frequency vocabulary) rather than looking where you pointed, and it surfaced your two:
arsenic_trioxyd__…__block__p209_t0
['Ngoại tâm thu thất', 'Thường gặp', 'Không rõ tần suất']
arsenic_trioxyd__…__block__p209_t1
['Tăng bilirubin máu', 'Thường gặp', 'Thường gặp']
Neither is a header. Ngoại tâm thu thất is an adverse-effect name and
Thường gặp is a frequency value; p209_t1 carries Thường gặp twice,
which a real header row cannot. _is_label_row passed them because it only
rejects cells containing a digit or longer than 40 characters — necessary, not
sufficient. Both descriptors now assert a clinical frequency derived from a
table that was quarantined precisely because its extraction is unverified.
Severity note: both are in tac_dung_khong_mong_muon, so no dose number
leaked.
A third case you did not mention, and it is in a dosing section
foscarnet_natri__lieu_luong_va_cach_dung__block__p698_t0
['Cl\ncr\n(ml/phút\n/kg)', 'Liều đối với\nHSV', 'Liều đối với\nHSV',
'Liều đối với\nCMV', 'Liều đối với\nCMV']
This one is a header — a two-level one, where a merged parent cell was
repeated across each sub-column it spans. So no clinical value leaked here. The
finding is different: tables/classify labelled a multi-level header as
SHAPE_SIMPLE, which is the shape _attachment trusts. A renal-dosing table
is the worst place for the shape classifier to be wrong, even when this
particular instance happens to be harmless.
Scope of my check, and what it does not cover
- 151 block descriptors total; 71 (47%) emit a
Cột:clause at all. - My detector flags exactly 3, and it has known blind spots: a leaked data row that neither repeats a cell nor uses frequency vocabulary would pass it silently.
- So this is not a clean bill of health for the other 68. The instrument that would settle it is the one this project already used on the block inventory: render all 71 crops and read the real header against the descriptor by eye. I have not done that.
On the embargo
Agreed, and I would widen it. Holding only the two known-bad descriptors relies
on my detector being complete, which it is not. Hold all 151 descriptors
until _is_label_row is fixed and the 71 with a Cột: clause are visually
checked.
The cost of that is zero right now: no embedding has ever been produced, and Qdrant on this machine holds 0 collections. Nothing needs unwinding.
One consequence for whoever fixes this: regenerating chunks.jsonl changes the
corpus sha256 again, which the A6 manifest gate in ingestion/load/ will catch
if a collection is ever loaded from a stale corpus. That is the intended
behaviour, not an obstacle.
Not claimed
I have not reviewed the other 68 Cột: descriptors, have not rendered any
crop, and have not checked whether tables/classify mislabels shapes beyond
the single foscarnet instance above.