Methodology
Evidence levels
UIProof helps preserve visual release evidence and review context. Different artifacts support different conclusions — combining them on one board doesn't make every claim independently verified. Match the claim to the artifact:
| Evidence type | What it records | What it doesn't establish by itself |
|---|---|---|
| Screenshot | The rendered state visible when captured | Transactions, persistence, security boundaries, or uncaptured paths |
| Visual comparison | A difference against a chosen reference under declared conditions | Whether the reference or the change is correct |
| Imported assertion result | What an external test run reports about a named expectation | Independent UIProof execution, or trustworthy provenance of that run |
| Asserted commit | A source identifier supplied with the evidence | That the capture was actually produced from exactly that source |
| Artifact digest | The identity/integrity reference for a specific piece of content | Application correctness or authorship |
| Reviewer observation | What a person noticed in a specific release | A functional result beyond the observed evidence |
| Release decision | A scoped judgment by a named decision-maker | Universal production readiness or independent certification |
| Fresh recheck | New evidence evaluated against a specified previous expectation | Unrelated behavior, or every possible state |
What UIProof's data model actually stores
That's the conceptual model. Here's the narrower slice of it UIProof's own release record actually captures today:
- Captured. A screen attached to a release, with a stable key, route, viewport, and persona — an image exists for this exact screen at this exact release, nothing more.
- Reported. A check result (passed / failed / skipped / blocked) imported from your own test runner. Required checks that were skipped or blocked stay in the denominator instead of being dropped, so a score can't be inflated by omission.
- Imported vs. sample. Every release is tagged evidence: "imported" (from your real app) or "sample" (synthetic demo data, like /proof/demo) — the two are never blended without the label.
- Reviewed. Feedback carries a status: pending or approved. Public-view comments from non-collaborators or viewer-role collaborators require owner approval before appearing publicly. Owner, editor, and commenter feedback is approved immediately. There is no separate release-level approval field — a release decision is something your team records (see the checklist), not a status UIProof stores.
Keep coverage honest
Declare the intended cases before interpreting the result. Preserve blocked, skipped, failed, missing, and not-tested cases. A captured screen is not a passing functional assertion. A selected highlight set is not complete application coverage. Show the relevant scope beside counts — release, role, route, state, viewport, environment — and say so plainly where a value is unknown.
Preserve the review record
Keep the original evidence tied to the original release. Add the next version rather than replacing what a reviewer saw. A recheck should name the original finding, the expectation, the new release, the new artifact, and the actual outcome.
Label media accurately
A screenshot walkthrough or timelapse is a sequence of source images. It may explain a flow or show evolution, but it is not a recording of real interactions. A real browser recording must be labeled separately and still has a limited captured scope. Synthetic examples demonstrate a method or interface; they are not customer outcomes. Conceptual diagrams — like the illustration below — explain relationships; they are not product screenshots or measurements.
Publish deliberately
Use private boards for working material. Before public sharing, review the selected evidence and visible labels. A public link may be forwarded, and revocation cannot recall previously downloaded or cached copies.
None of this replaces your own test suite or a human decision to ship. See it applied in the guides, or the practical version of this in the release-review checklist. Related: product status · explore the synthetic example.