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 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 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 13 September 2027 is an estimate.

What the record cannot see

The DIS text is not public, so the record cannot see an ISO editorial change. It follows the published IEEE edition behind the joint project. When the FDIS or the published standard is available, 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, compares the stage, the dates and the source relationship record 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.