Data and verification policy
The badge, source links, warnings and tests are one honesty system. This page describes the rules the repository actually enforces today—including where the catalog is partial, pinned rather than live, or unable to offer a public corrections channel.
Meaning of the badge
A real endpoint returns curated reference facts, a result computed from a published standard, or a runtime-backed fact such as an IANA timezone offset. It must declare at least one authoritative data source. Real does not mean live, complete for every use, certified, or guaranteed never to become stale.
A mock endpoint returns generated test data. Its identifiers, people, events or operational records do not assert that a real-world entity or event exists. A source-backed component can still make the fixture more coherent; the badge follows the returned claim, not the absence of all upstream facts.
The registry currently has 2 mock endpoints with declared source material. They remain mock because the records they return are fictional; the source is used only for a bounded component of the fixture.
OurAirports airport snapshot plus pinned coordinate-derived IANA zones (verified 2026-07-29)
Unicode Character Database 17.0.0 (character names and categories)
Source selection and pinning
Registries come from their registry operator; national holiday rules come from statutes, gazettes or ministry pages; standards computations cite the specification. A URL is optional when no legitimate public copy exists. The catalog omits the URL rather than inventing or deep-linking a paywalled copy.
Attribution, copyright notices and modification statements travel with a bundled dataset when its licence requires them. Sources with unacceptable share-alike, unclear, commercial or reliability terms are rejected or deferred; a useful-looking dataset is not enough.
A volatile bundled registry carries a version or date, a content digest and a deterministic refresh or parity script. When the source is prose rather than one fetchable file—national statutes are the main case—the equivalent is a dated verification constant, per-item official URLs and an offline verifier that re-derives the output.
Validation and parity
Registry contract
The registry rejects duplicate slugs and SEO metadata, unresolved related links, malformed examples and real endpoints without provenance. It also normalizes one or several declared sources in a fixed order.
Route contracts
Registry-wide tests exercise declared params, invalid values, count, distinctness, determinism, fields, formats, warnings and documented examples. Bespoke suites add independent facts and the invariants unique to an endpoint, such as holiday dates or balanced ledger entries.
Static parity
Production HTML is checked for canonical URLs, titles, descriptions, H1s, structured data, sitemaps and endpoint discovery. The three editorial guides additionally execute every concrete request during build and verify their endpoint/reverse-link contract.
Tests reduce known failure modes; they are not a proof that every real-world edge case has been found. The public scope, source version, warnings and caveats remain part of the answer even when all automated checks pass.
Partial coverage
A bounded or partial answer says so in the contract and, when material to a request, in the response. The holiday engine marks ten national calendars partial because named lunar, Hijri or annually announced dates are excluded; Business Days warns that the resulting workday total may therefore be too high. File signature detection returns a ranked set rather than a verdict when several formats share bytes. Nullable fields are preferred to a second unsupported inference.
This philosophy also limits scope: national holidays are not regional leave calendars, shape-valid phone or postal values are not proof of existence, and a standards-conformant check digit is not proof that an identifier was issued. The caveat travels with the answer because removing it would change the claim.
Updates and freshness
| Source model | What changes it | What the page can claim |
|---|---|---|
| Pinned bundled snapshot | A reviewed refresh updates the version/date, digest, generated data and parity expectations. | Reproducible and dated, not live. Manual upstream checks are deliberately not CI dependencies. |
| Rules computed from official prose | A statute/source review plus the committed offline verifier. | Verified for the stated range and scope; outside-range results warn or are refused. |
| Runtime Intl data | The deployed runtime's ICU/CLDR/tzdb changes. | Current to that runtime and echoed with resolved inputs, but not pinned by this repository. |
Visible review dates, JSON-LD dateModified and sitemap lastmod are
derived from the newest git commit in each page's real dependency closure. An uncommitted build cannot state
that date honestly and falls back rather than inventing one.
Corrections philosophy
When shipped data disagrees with the source it claims to mirror, that is a bug. A correction updates the implementation, regression or parity checks, user-visible endpoint copy and policy/notices when the scope or licence statement changed. Historical logs remain historical; current public documentation must describe the current build.
The site currently publishes no operator identity, credentials, public corrections inbox or response-time promise. This page therefore does not invent a byline or submission workflow. Establishing a real public contact/abuse channel remains an owner decision and should precede any promise that users can report an issue.