A reusable lesson · Verification
Verify the public result separately.
Pre-release tests and live checks answer different questions. Keep both records, with their scope and limits intact.
The practical takeaway
After a release, open a representative page, one linked asset and a deliberately missing route. Compare the served content with the intended candidate.
Borrow the prompt
Design a release check for this website: [site]. Separate pre-release checks from post-publication checks. Include expected status codes, representative pages and assets, an unknown route and content-version comparison. Record what actually ran, what passed and what remains untested. Do not treat mocked interaction tests as a full rendered accessibility audit or infer search rankings from HTTP success.
Where this lesson comes from
A website can work before publication and still behave differently at its public address. Checking both stages answers two different questions: is the candidate sound, and is the intended version being served?
The launch record reports 126 pre-release checks: 83 static/content/schema/privacy checks, 13 local HTTP route-and-asset checks, and 30 Node DOM-stub functional checks. A separate live pass checked eight endpoints after publication.
Derived from the October 13, 2026 field notes on Release verification.
Evidence and limits
- The recorded live checks covered the homepage, About page, a journal edition, a lesson page, sitemap, robots file, www homepage and an unknown route.
- Seven endpoints returned HTTP 200; the unknown route returned HTTP 404. Five HTML responses matched the release candidate byte for byte.
- These checks were recorded at launch on October 13, 2026, through 11:46 a.m. UTC; this article is not a new rerun.
- The counts are publisher-recorded engineering evidence, not an external certification. The full original test report is not publicly hosted.
- DOM-stub functional checks are narrower than real-browser testing; a full rendered accessibility audit was not completed.
- A successful response does not establish search indexing, rankings, readership or future uptime.
Source: October 13 site-launch verification record; W3C WAI: Easy Checks. Publisher-recorded launch evidence; not an external certification or a new rerun. A reusable prompt is a proposed method, not evidence that a future result will be correct.
Continue the notebook
A practical extension · Revised October 13, 2026
This teaching extension adds a worked check. The original launch facts, publication date and evidence limits above are unchanged.
Draft a release check with an expected result
Use a small check record: item, version, environment, expected result, observed result and next action. Expectations belong in the record before the check; observations stay blank until it runs.
For a synthetic learning-site release, the proposed checks could include:
- Homepage: a successful response and the intended new introduction
- One guide: the complete method, correct title and working internal links
- Its download: a file that opens and matches the relevant guide content
- A deliberately missing route: the expected not-found response, rather than a successful fallback page
- One optional control: its visible result and the manual fallback when the enhancement is unavailable
A correct status code does not prove the body is the intended version. A success message does not by itself prove the clipboard contains the expected bytes. A blocked request leaves the route's live behavior unverified; it is not a pass or a confirmed 404.
Keep the decision tied to the evidence
After a repair, rerun the affected checks and record which nearby behavior was also inspected. Keep local, live HTTP and rendered-browser results separate. If a check cannot run, state what remains unknown and whether that blocks the intended release.
This is an original proposed checklist, not a new execution of the historical launch checks. Review a claim against its evidence helps turn the resulting record into a bounded conclusion.