Validators

Validators enforce the site’s operational contract. They do not replace review, but they catch classes of mistakes that should never depend on memory: missing metadata, unsafe browser-tool primitives, malformed static files, missing schema fields, and stale architectural assumptions.

The validation surface is intentionally general but narrow. Each validator checks one boundary that matters across many pages or tools. That keeps the checks useful as the site grows without turning them into one-off tests that only protect a single implementation detail.

Current Validation Families

• Content metadata checks for public MDX frontmatter.
• Browser-tool boundary checks for network, storage, and local-only declarations.
• Static standards-file checks for headers, redirects, robots, llms, and security contact material.
• Schema checks for advisories, reports, tools, and content metadata.
• Shell architecture checks that prevent fragile custom navigation from returning.

Use

Run validators locally before committing and in CI before deployment. A failed validator should be fixed or deliberately waived in documentation; it should not be ignored because the visual page appears to load.

Use guidance should identify the user action, the expected output, and the condition under which the page is the wrong tool. This keeps the surface useful without promising more than it performs.

Validator Use

Validators exist to make maintenance boring. A validator should fail on conditions that create public ambiguity, deployment risk, or unsafe tooling behavior, and it should avoid taste-only opinions unless those opinions are part of an explicit style contract.