A public document is defined as "the keyed current projection" — one row per key, carrying what is true now. No gate enforces the "one" part.
The instance that surfaced it
PR #1081 carries docs/BENCHMARKS.md with the key **NemotronH paged forward** (MODEL-NEMOTRON-H-ABI-A2P, #810) twice, and the two rows contradict:
line 14 …A3 host gate PASSES 96/96. GB10 read 4/24; cause and fix #1157,
sm_121a re-run pending a lease… <- byte-identical to main's row
line 16 …A3 gate PASSES on GB10: 96/96 STRICT PASS, mode=decode… <- the addition
Counted directly: on origin/main the key appears 1 time; on the PR head, 2.
The author appended where the rule requires updating the existing keyed row. That is an easy mistake, because .agents/issue-index.md correctly requires appending — but that file is an append-only log and docs/BENCHMARKS.md is a projection. Opposite disciplines, and nothing tells an author which one they are editing.
Why nothing caught it
scripts/check-public-doc-tables.py gates size and shape — max_h2_sections, max_prose_paragraphs, MAX_CELL_CHARS, the shrink-only oversized_cells ratchet — and returns rc=0 on this file. It never compares row keys. So a duplicate lands silently and the document then asserts two different things about one subject, with nothing indicating which is current.
Two review passes and one operator verification missed it, for a reason worth recording: each checked that both sides' hunks survived the merge, which proves the merge was faithful and says nothing about whether the result is key-unique. A duplicate-key check written for issue-index.md does not transfer, because that file legitimately grows.
What a fix looks like
Add a key-uniqueness assertion for the projection documents (docs/STATUS.md, docs/BENCHMARKS.md, docs/FEATURES.md), keyed on the first table cell and scoped per table, since two tables may legitimately share a key.
Two cautions:
Scope
This is a checker-semantics change, so it needs its own row and spec rather than an in-flow fix. #1081 is being repaired separately by collapsing its two rows into one; that repair does not close this issue, because the next append will do the same thing.
A public document is defined as "the keyed current projection" — one row per key, carrying what is true now. No gate enforces the "one" part.
The instance that surfaced it
PR #1081 carries
docs/BENCHMARKS.mdwith the key**NemotronH paged forward** (MODEL-NEMOTRON-H-ABI-A2P, #810)twice, and the two rows contradict:Counted directly: on
origin/mainthe key appears 1 time; on the PR head, 2.The author appended where the rule requires updating the existing keyed row. That is an easy mistake, because
.agents/issue-index.mdcorrectly requires appending — but that file is an append-only log anddocs/BENCHMARKS.mdis a projection. Opposite disciplines, and nothing tells an author which one they are editing.Why nothing caught it
scripts/check-public-doc-tables.pygates size and shape —max_h2_sections,max_prose_paragraphs,MAX_CELL_CHARS, the shrink-onlyoversized_cellsratchet — and returnsrc=0on this file. It never compares row keys. So a duplicate lands silently and the document then asserts two different things about one subject, with nothing indicating which is current.Two review passes and one operator verification missed it, for a reason worth recording: each checked that both sides' hunks survived the merge, which proves the merge was faithful and says nothing about whether the result is key-unique. A duplicate-key check written for
issue-index.mddoes not transfer, because that file legitimately grows.What a fix looks like
Add a key-uniqueness assertion for the projection documents (
docs/STATUS.md,docs/BENCHMARKS.md,docs/FEATURES.md), keyed on the first table cell and scoped per table, since two tables may legitimately share a key.Two cautions:
audit-live-rows --checkalready reports "3 IDs live in two matrices: BACKEND-CPU, BACKEND-CUDA-SM121, BACKEND-VULKAN", so a naive global check reds on existing content. Establish the current count first and gate per table, or the new check redsmainon day one — which this repository is already suffering twice over (main is RED on five CPU test suites, and a SPEC-ONLY PR is the control that proves it #1464, main fails its own audit-live-rows --check gate: KERNEL-DFLASH2-GROUPED-CONV is an ABANDONED ACTIVE row #1468).Scope
This is a checker-semantics change, so it needs its own row and spec rather than an in-flow fix. #1081 is being repaired separately by collapsing its two rows into one; that repair does not close this issue, because the next append will do the same thing.