Build a release evidence ledger that reviewers can trust
A practical method for separating release claims, proof, dates, scope, and unresolved limitations.
Start with a claim, not a file
Evidence is useful only when it answers a specific release question. Write the claim first: for example, the Android build preserves local data after an update. Then record the exact build, device, operating-system version, date, steps, outcome, and artifact. A screenshot without this context is decoration, not proof.
Keep verification levels separate
Automated checks, browser checks, physical-device checks, human usability work, and production operations answer different questions. Never promote a synthetic persona result into a real-user result. Keep a visible level on every entry so that a green automated result cannot hide an untested device or operational process.
Expire evidence deliberately
Store a reviewed date and a next-review date. A policy answer can become stale when a store rule, SDK, operating system, or app version changes. Expiry should not silently turn an old pass into a current pass; it should create a new verification task while preserving the historical record.
Record conflicts instead of deleting them
When a newer run fails after an older pass, keep both records and mark the claim as conflicted. The release decision should stay on hold until the scope difference is understood or a fresh run resolves it. This protects teams from selecting only the most convenient result.
Release-ready checklist
- Every claim names its platform and version
- Every artifact has a review date
- Synthetic and physical-device results use different labels
- Conflicting results remain visible
- The next verification action is assigned
This guide is written for planning and verification. Store rules and legal requirements can change; verify official requirements before submission.