All visual comparison rests on one sample — the baseline. This is what new snapshots are checked against. Below: how a baseline is arranged, how it lives over time, and what happens to it when tests and branches change.
What a Baseline Is
A baseline is an approved sample that new snapshots are compared against. It is not just a picture: a baseline has a version history and a memory of who approved it and when. Browsing and working through baselines is convenient in the baselines explorer: a signature tree, a version feed, and a variation list.
The Signature
A baseline is tied not to a page in general but to an exact set of conditions — the signature. It includes: the test, the step, the capture type, the environment, the browser, the operating system, the window size, the branch, and the variation.
Because of this, a snapshot from the test environment is never compared against a baseline from production, and a narrow phone window against a wide desktop one. Every condition is a separate lane of samples, and they never mix.
Branches
New snapshots are compared with the latest approved baseline of their own branch. If that branch has no baseline yet, the default branch’s baseline is taken — usually the main one.
An honest caveat: the product does not compute the common ancestor of branches, because the tested application’s code history is unreachable for it. A branch is simply a label to it. That is why one branch’s baseline never “merges” with another automatically: transfers are done manually — by promoting or forking.
Revisions
The first build creates a baseline automatically — that is revision number one. Every human approval after that adds a new revision, and it stores the name of whoever approved it. So the version feed always shows provenance: “First run” (created automatically on the first run), “Human approval”, “AI-suggested, human-confirmed”, “Carried forward by hash”.
If a picture returns to its former look, the revision is not captured again but carried forward by its content fingerprint. This saves both time and money: the page is not opened an extra time, and the baseline simply recalls an already approved sample.
Variations
The same check sometimes needs to be captured differently: a light and a dark theme, one locale and another, a phone and a desktop. For this a step has named lanes — variations. Each variation keeps its own baseline and is compared only against itself.
The limit is 20 variations per step, and each has an expiry. Expired variations are not deleted on their own: the product shows them as a list with a question — “Delete all”, “Choose which”, or “Keep — renew expiry”. Deletion is soft — there is an undo window, and you can cancel with the Ctrl+Z shortcut.
Promote and Fork
The current revision of a baseline can be promoted to another branch as that branch’s new baseline, or forked into a separate lane. This is how a baseline for a new branch is started without re-capturing the pages.
The copied revision keeps its approval provenance: you can see who and when approved the original sample. If exactly the same content already lies on the target branch, the product says so honestly and duplicates nothing.
Orphans and Retention
A baseline outlives branch deletion and test renaming — by design. It stops matching only when the capture declaration disappeared from the test files; then it becomes orphaned. Orphaned baselines are visible as a separate list, and they can be removed only manually and with a mandatory reason — together with the version history, nothing else is touched.
The retention sweep does not delete anything either: it only flags old revisions that have not been approved in a long time. What to do with them is a human decision. This way baselines never disappear quietly.
Snapshot Safety
Once per project you need to confirm that capturing is safe. The checklist is simple:
- no passwords, keys, or cookies get into snapshots;
- there is no real customer data on the snapshots;
- session tokens and identifiers do not remain on snapshots;
- keeping internal names and addresses is acceptable.
Who confirmed and when is stored, and the confirmation stays in force until it is reconsidered. If the captured surface changes significantly, the confirmation is requested again.
Next: how decisions on differences turn into the team’s work — in Review Board & Tasks.