ADR-0059: A document records its page count, and withdrawing a verification stays refused

Status: Superseded by ADR-0074 — do not follow this ruling; the page count is nullable, and ADR-0074 carries this ADR's amendment of ADR-0052 forward Date: 2026-09-20

Decisions

D-131 A document records how many pages it has, and the verification gate checks that every page from 1 to that count is verified

The count is read from pdf.js's numPages at admission. The gate stops asking whether verified pages run contiguously from 1 and starts asking whether a verified page exists for every page number the document claims. pageCountKnown stops being a pinned false.

D-132 Withdrawing a verification stays refused

@@unique([sdsId, pageNumber]) spans soft-deleted rows, so a soft-deleted verification keeps its page's key and that page can never be verified again. That is the ruling, not an oversight.

What this amendment touches

• ADR-0052 — D-119, D-120 and D-121 all stand; no ruling of ADR-0052 changes. What changes is its Consequences section, which named two holes as standing limitations under "Holes named, not closed": that nothing records how many pages a document has, so the whole-document check "cannot catch missing trailing pages", and that a soft-deleted verification blocks a document forever. Both sentences said "Both need a ruling on re-verification"; this ADR is that ruling. The page count makes the first false, and the withdrawal ruling settles the second as refused rather than open. A reader of ADR-0052's Consequences must read this ADR with it.

Context

The no-unverified-page rule (D-119) says no Source Span is created for a document with any page lacking a verification record. ADR-0052 named the hole in it in the same breath: the check could only see the pages it knew about, so a document whose trailing pages were never presented passed. A twelve-page SDS admitted as eight pages is verified, complete and wrong, and nothing in the product can tell.

The number was already in hand. The curator's browser renders every page with pdf.js (D-111), and pdf.js states numPages before the first page is drawn. Nothing new is parsed, fetched or trusted; a value that was being discarded is recorded.

The withdrawal question arrived from the same schema and is deliberately not answered here. A verification is a named person's judgement about a page. Withdrawing one is a decision about whether such a judgement can be taken back, which bears on ADR-0029 — and nobody has needed it. Narrowing the constraint now would answer that question in a migration rather than in a ruling.

Decision

A document records its page count at admission, read from pdf.js, and the verification gate requires a verified page for every page from 1 to that count. Withdrawing a verification remains refused, and the unique constraint keeps spanning soft-deleted rows.

Rejected options

• Keeping the contiguity check — rejected because it is the check that lets the trailing-page document through, which is the hole this ADR exists to close. A run from 1 with nothing after it is indistinguishable from a complete document to a gate that never learned how long the document is.
• Taking the page count from the server by parsing the PDF there — rejected because the curator's browser already has the number under D-111, and a second parser is a second answer to the same question, which can disagree with the one the curator actually verified against.
• Narrowing @@unique([sdsId, pageNumber]) to live rows now — rejected because it decides the named-judgement question by implementation rather than by ruling. If withdrawal is ever wanted, it is an ADR against ADR-0029 first and a migration second.

This ruling may not be re-decided

If a change contradicts this ADR: stop and raise it. Do not implement over it.

Specifically: do not restore a contiguity check, do not make the page count nullable or curator-editable, and do not narrow the unique constraint to live rows as a convenience while fixing something else.

Consequences

What becomes true. A document missing its trailing pages fails the gate, so D-119's promise — no span from a document that is not verified whole — is true of the whole document rather than of its beginning. pageCountKnown reports a fact.

What this costs. Admission now depends on pdf.js having stated numPages, so a file it cannot open is refused earlier and more visibly. A document already admitted under the old rule has no count and has to be re-admitted or backfilled before it can pass.

What is closed off. Withdrawing a verification, for now, and with it any correction of a mis-verified page other than re-admitting the document.

Coverage

Upstream	Landed in	Evidence	Note
D-119	D-131	the whole-document verification rule is what the page count makes enforceable; ADR-0052 named the trailing-page hole as uncatchable	ADR-0052; this ADR closes the hole it declared
D-111	D-131	the count is pdf.js's numPages, already rendered in the curator's browser, so no new parse is introduced	ADR-0048
D-120	D-132	identity and judgement are read from the Sds and its records rather than supplied by a caller, which is why withdrawal is a ruling and not a route	ADR-0052