What should be in a website release sign-off? A worked evidence pack.

Start with a complete record

This pack uses fictional Fieldnotes pages and real browser captures. It is a teaching report, not a customer release approval. The captures and findings are observed; the three review decisions below are explicitly worked examples. No person is named as a reviewer who did not perform a review.

The primary report is this HTML page. You can also download the PDF edition, full captured evidence (JSON), worked decision record (JSON) and blank sign-off template (Markdown). Files are available without an email gate.

Scroll horizontally to see all columns.

Three outcomes, three different decisions

Scroll horizontally to see all columns.

These gate values follow the shipped OnChange release-check contract. The decisions in this downloadable teaching record are examples, not API-issued approvals. A real release check has its own ID, revision, artifacts and reviewer record. The decision JSON keeps that distinction explicit.

Complete and approved, within a stated scope

The baseline is compared with the same preserved baseline capture. Text, metadata, screenshots and automated findings are identical by construction. The baseline scan found zero violations in its configured rule set, on both viewports. This is a control comparison, not an independent second capture or evidence that an application has no bugs.

An illustrative approval note is: “Approve this static-fixture control comparison for the captured plan page and two viewports. No login, checkout or assistive-technology journey is in scope.” A real release must identify an actual reviewer and the broader checks that its team requires. Zero new automated findings alone is never the approval.

Complete, with changes needing review

The changed preview has three deliberate differences: yearly billing becomes monthly, its robots meta content becomes noindex, follow, and an email input is added without a label. Both viewports captured successfully. The configured axe scan detected a new label rule violation on #email, marked critical by axe. That severity is the scanner's finding classification, not a legal or business-impact assessment.

The baseline mobile capture and preview mobile capture preserve the smaller layout. Open the baseline source and preview source.

A useful review note assigns each observation an action: confirm the intended billing period, document the preview indexing exception and add a programmatically associated label before retesting the input. W3C's Name, Role, Value guidance explains the relevant programmatic information. A staging-only noindex may be expected; it still needs an explicit production expectation.

Incomplete and blocked

The harness requested a deliberately absent preview file and received HTTP 404. That response is recorded as missing evidence, not as a clean page with zero differences. There is no accepted preview screenshot or automated result for this case. The decision remains blocked until a valid public preview can be captured in a new comparison.

OnChange does not allow approval of an incomplete release check. Rejecting a complete comparison also fails the gate. A pending review stays pending; it does not become approval when a timer expires.

Use the API with a bounded gate

The downloadable Python CI example uses the shipped POST /api/v1/release-checks and GET /api/v1/release-checks/:id endpoints. It sends an X-API-Key with monitors:write and monitors:read scopes. Keep the key in your pipeline's secret store.

Provide a JSON request with public base URLs, paired paths, viewports and a unique request key for the comparison. An identical retry can reuse that key. If the page list or URLs change, use a new key. Replace the example domains and selector with your own reachable pages; #choose-plan is the control in our fixture, not a universal site selector.

{
  "name": "Plan page release",
  "production_url": "https://production.example.com",
  "preview_url": "https://preview.example.com",
  "request_key": "deploy-123-plan-page",
  "pages": [{
    "production_path": "/plans",
    "preview_path": "/plans",
    "required_selector": "#choose-plan"
  }],
  "viewports": ["desktop", "mobile"]
}

Save the request as release-request.json, set ONCHANGE_API_KEY in your environment, then run:

python3 release-gate.py release-request.json --timeout 600

The script has a total polling deadline and bounded HTTP requests. It exits successfully only when the returned gate is passed; failed, malformed responses, request failures and timeouts fail the job. While it waits, an authorized person reviews the result in OnChange. It never approves a check automatically. HTTP 200 and a completed scan are not substitutes for approval.

The initial release-check version requires publicly reachable previews. It does not inject credentials into protected previews. Dynamic content, animation, fonts and personalization can cause visual differences; use representative stable pages and inspect the evidence rather than assuming every pixel difference is a defect. A required selector confirms presence, not the completion of a customer journey.

Fill in your own sign-off

Use the blank template to capture environment URLs, release revision, page pairs, viewport conditions, expected differences, failures, automated and manual scope, outstanding work and a reviewer decision. Record “not tested” and “cannot determine” explicitly. Include the result revision so an approval cannot be confused with a later run.

For accessibility changes, attach the retest worksheet and choose the relevant worked decision. Automated findings are only one input. W3C states that no tool alone can determine accessibility conformance.

Reproduce and interpret the evidence

The source harness generated 28 captures of 14 fixtures, plus focused-state screenshots and one intentional missing-file observation. It runs locally against a temporary fixture server. It does not contact customer sites or issue production release checks. The public fixture ZIP and reproduction notes and self-contained reproduction kit describe the inputs.

This editorial harness uses axe 4.12.1. The deployed release worker currently bundles axe 4.10.2, so rule counts from the two environments must not be treated as interchangeable. The report makes no claim that a local harness export is an API response. All served fixture pages also carry a noindex response header, independently of their deliberately varied HTML metadata.

Initial publication: 13 October 2026, by OnChange. The PDF is a companion reading copy; this HTML report remains the primary version. No real customer approval, independent specialist review, ranking effect or compliance certification is claimed.