One record, written from the clause, checked before release

The method is deliberately boring. Read the source, write the requirement in our own words, cite the clause, write the evidence a board or an auditor would ask for, and test the wording against the source before it ships. Then re-read the public record on a schedule and fail the build if it changed.

The record first

Every page, the free check, the kit and the watch are rendered from one JSON record. A change to a clause is a change to the record, and every output follows. There is no second copy of the text to drift. The record carries the retrieval date and the source URL on every field group.

Paraphrase, never reproduce

Only clause titles, defined terms and data element names stay verbatim. Every requirement, evidence line and failure line is our own statement. The strict seven-word overlap test runs against the source and the prior edition before release. A page that fails is rewritten, not shipped.

Dates with a status

A recorded date is on the official page. A derived date is computed from a recorded date and a stated rule. An estimated date is a planning choice. The site labels each one and never presents an estimate as an ISO commitment. The planning date of 15 February 2027 is an estimate.

What the record cannot see

The edition 3 text is not public, so the record cannot see a clause change. It follows the published edition in force. When the FDIS or the published standard is ready, the record is refreshed and the watch sends the diff. Until then, the site says what it does not know.

Refresh and fail loudly

scripts/refresh downloads the public pages, checks the stage, the dates, the edition relationship and the hash of the baseline text on file, and exits non-zero on an unexpected change. The same comparison is what the watch sends. The build cannot silently pass a changed official page.