Claim and evidence method
This method keeps paper claims, qualifications, reproductions, interpretations, and audit-derived findings separate.
Every material statement is registered in claims.yaml under exactly one of those namespaces.
Paper claims, qualifications, and interpretations must cite PDF spans. Reproductions and derived findings must cite canonical evidence-ledger values. The verifier rejects crossing those source boundaries.
Paper anchors
Paper-attributed entries identify the exact PDF by its SHA-256 digest and byte length, then identify a one-based page, section label, unique start and end markers, normalized word count, and SHA-256 digest of the complete anchored span. The verifier extracts one page at a time with Poppler's pdftotext in raw mode, applies Unicode NFKC normalization, removes soft hyphens, rejoins line-wrapped hyphenated words, and collapses whitespace. A changed PDF, ambiguous marker, changed span, or changed word count stops the build.
The publication paraphrases source material instead of reproducing long passages. Page and section labels aid human review; the span digest is the machine-enforced identity.
Reproductions and derived findings
Entries based on the legacy audit bundle point to a JSON value in its canonical metric status ledger. Their source records the immutable evidence-bundle digest, ledger path, JSON Pointer, and SHA-256 digest of canonical compact JSON for the selected value.
Later publication evidence uses a distinct signed trace. It binds the claim to the exact canonical-lock receipt, private OCI subject digest, source commit, signed manifest, allowed JSON document and pointer, and canonical compact-JSON value digest. Release verification cryptographically checks the Sigstore bundle against the pinned GitHub Actions identity and OIDC issuer before accepting any signed trace. A copied result, self-asserted lock, alternate workflow, changed source commit, or modified value therefore fails closed.
The evidence-route inventory separately maps every generated metric and discrepancy surface to one of these signed claims. Statements about visible provenance, raw-input exclusion, and content-addressed cache admission identify their exact implementation contract tests. A newly rendered metric or discrepancy cannot enter the route without extending this inventory and returning the complete claim ledger to pending review.
Human approval and corrections
An automated system may draft or verify an entry, but it cannot approve one. New and edited entries remain pending with no actor metadata. Release verification accepts approved only when a named human records a timezone-aware timestamp, the method manual-source-comparison, and the SHA-256 digest of the complete approval-relevant ledger content. Any content edit invalidates the batch approval; any model or automated actor is rejected. The static build re-extracts every PDF span, rechecks every evidence trace, and fails while any material claim is pending.
A correction changes the paraphrase and/or source anchor, returns the entry to pending, repeats source comparison and independent review, and records a new human approval. Prior released states remain recoverable from version control.