Template

Release-review checklist

A checklist for reviewing a release's visual evidence before calling it done. Complete only fields you can substantiate — write not tested, unknown, or blocked rather than inventing a result. It doesn't require UIProof — it's the discipline behind how we label evidence in the product itself. This checklist is not independent certification.

Evidence is attached, not implied
Every changed screen has an actual captured image for this release — not a description of what should have rendered.
Checks are labeled by source
Imported test results are marked reported, not verified. Required checks that were skipped or blocked are still counted against the release, not dropped from the score.
Changed screens are reviewed first
Start with what actually changed since the last release. The full set is one click away, but it isn't the default view.
Every verdict has a screen and a release
A reviewer's note says which exact screen, at which exact release, needs what change — not a general "looks off" comment days later.
Public and viewer feedback is moderated before it's public
Public-view comments from non-collaborators or viewer-role collaborators require owner approval before appearing publicly. Owner, editor, and commenter feedback is approved immediately.
Sample data is never mistaken for real data
Demo boards, synthetic fixtures, and local test runs are clearly labeled. They inform the process; they aren't cited as a customer result.
Sharing is a deliberate choice
A release or screen is published because someone decided to share it — not because a link happened to be reachable.

Copy this into your own review

A working-document version of the same checklist, field by field. Keep skipped, blocked, and missing cases in the scope table rather than dropping them — a capture is not a passing assertion.

1. Define the decision

• App / board
• Release label
• Source commit (provenance: asserted / verified by a named process / unknown)
• Environment
• Reviewer / owner
• Decision this review supports
• Explicit exclusions

2. Declare the scope

• Case ID
• Tenant / fixture
• Role
• Route pattern
• State
• Viewport
• Capture status (not started / captured / missing / blocked / skipped)
• Assertion result / source (not tested until it is)

3. Identify the evidence

• Stable logical screen
• Capture date
• Browser / version
• Fixture revision
• Artifact reference / digest
• Results source
• Rendering or comparison differences
• Synthetic / customer-authorized / other approved origin

4. Write actionable feedback

• Finding ID
• Release and screen
• Observed
• Expected
• Affected scope
• Impact as assessed by reviewer
• Supporting artifact
• Owner / next action
• Recheck expectation
• What this observation does not establish

5. Record a fresh recheck

• Original finding ID
• New release
• Same state / role / viewport reproduced (yes / no, with explanation)
• Expectation evaluated
• New evidence
• Actual outcome (passed / failed / blocked / not tested / inconclusive)
• Remaining limitations
• Reviewer and actual review date

6. Make the release decision explicit

• Decision
• Known unresolved items
• Reason the decision is appropriate for this scope
• Decision owner and actual date

A patch claim is not a recheck result — preserve the original release and attach new evidence to the new version.

See it applied to executed synthetic examples in the review patterns, or read the guides.

Want to see this checklist against a working example first? Open the synthetic Proof Studio demo, or create a private board to run it on your own release.