Publication assurance
Validation is a scoped claim, not a large number
FPRD Lab scales checks to the surface changed. A passing software gate says that named structural or rendering defects were not found; it does not certify the mathematics, novelty, exposition, or research judgment.
Four gates with different jobs
- Build
- Compile and package the production worker. This catches broken imports, type failures, and unusable deployment artifacts.
- Structural
- Check stable IDs, claim dependencies, publication references, evidence URL syntax, theorem anchors, research-document custody, representative shell routes, and legacy redirects.
- Changed surface
- Render the pages touched by a batch and inspect landmarks, HTTP success, raw TeX, KaTeX failures, and links whose targets are in that same batch.
- Whole site
- Crawl the complete public route graph after changes to shared rendering, navigation, routing, or large generated datasets. It is deliberately not the default for an isolated content edit.
The checks are tested with deliberate defects
A validation rule is useful only if a representative violation makes it fail. The contract suite injects corruptions such as a duplicate claim ID, a dangling claim dependency, an unknown publication ID, a malformed evidence URL, a missing theorem anchor, missing research content, an absent page landmark, visible TeX, and a KaTeX error node.
This audit found a real gap: the first structural suite verified that dependency and publication-reference fields were arrays but did not verify their targets. The gate now checks both relations against the governed claim and publication sets.
What remains outside these gates
- A proof can be wrong while its page renders perfectly.
- A valid URL can point to weak, irrelevant, or later-changed evidence.
- Representative routes do not prove that every route is healthy.
- Fault-injection examples show sensitivity to named defects, not a global defect rate.
- Visual nuance and narrow-screen usability still require focused inspection when layout changes.
Mathematical maturity is therefore advanced only from proof, reproducible evidence, and audit of the mathematical dependencies—not from a software test count. Return to the maturity matrix for claim-specific evidence and limitations.