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 an assessor 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 a source pointer 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 its prior editions 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 amendment text is not public, so the record cannot see what it changes. The public preview of the base standard stops before the later clauses, so the record states the purpose of those clauses at the level the contents and the guidance support, and says when it is doing so. When the FDIS or the published amendment is available, the record is refreshed and the watch sends the diff.

Refresh and fail loudly

scripts/refresh downloads the public page, compares the stage, the dates and the amendment status with this record, 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.