When a build finds differences, someone has to decide what to do with them. Walking them one build page at a time is inconvenient, so every difference waiting for a human decision is gathered in one place — on the review board. This is the reviewer’s workplace: here you can see how much still awaits a decision, who has already decided what, and what was postponed for later.
Cards and Filters
Every difference awaiting a decision is a card. There can be many cards, so the board can filter them:
- By state — what is still in the queue, what is deferred, and what is already decided.
- By author — “Mine” shows only what is assigned to you.
- Waiting for designer — differences in shared interface parts, where a design reviewer’s decision is needed.
- Overdue — todos that have been waiting for more than a week.
A lucky set of filters can be saved as a view — then you return to it with one click. At the top, review progress is visible: how many decisions have been made of the total. Only human decisions count — AI suggestions are not in that number. Beside it are the participants and the latest decisions: who, when, and what they decided.
What a Human Can Do
On each card you can take one of several actions. These are the same verdicts as in the diff viewer, only here they are collected into one flow:
- Approve — the difference is declared normal. The snapshot becomes the new baseline, and the next builds compare against it.
- Request changes — the difference looks wrong, but the final word belongs to whoever edits the interface.
- Reject — the difference is declared an error. You can immediately open a fix issue with a reason.
- Set a fix todo — the difference is not finally decided yet, but the fix needs tracking.
- Unapprove — return to the queue what was approved earlier. Useful when a decision was made in haste.
Besides verdicts there are two organizational things: a card can be taken on yourself (then it is clear a specific person is on it), and a reviewer can be assigned — choosing who will decide.
Review Todos
A rejection without consequences is a decision that is easy to forget. Therefore a rejected snapshot gets a review todo with the reason it was rejected. Until the todo is closed, the snapshot stays in the queue: the next build will show this difference again, and it will not be forgotten.
A todo has a deadline and an assignee. You can put a link to an external tracker in it — if you are used to tracking fixes in another program. Closing a todo without a result is not allowed: you must write what was fixed — or why no fix is required. This way history keeps an answer, not an empty checkmark.
Who Can Do What
Permissions depend on the role. Roles are created by the administrator; there is no email login or sign-in through third-party services here — a login is handed to a person personally:
| Role | What it can do |
| Viewer | View builds, differences, and baselines. Decides nothing. |
| Reviewer | Pass verdicts, comment, run todos. This is the role the review board is open to. |
| Member | Plan builds, launch agent campaigns, edit tests. |
| Administrator | Project settings, baseline lifecycle, users. |
| Owner | API keys, encryption key rotation, ownership transfer. |
Separately there is the design-approver mark. It is needed where a difference touches shared interface parts: only a person with this mark can approve such a difference. If someone else approved it, the audit log gets an “Approved without design approval” mark.
Bulk Actions — Safe Ones Only
When there are dozens of differences, going through them one by one takes long. Hence the “Accept all safe” button. It accepts only the differences whose safety was proven by strict rules, not by the AI and not by a human:
- The picture returned to a previously approved state.
- Only what fell inside masked regions changed (for example, the date in the corner of the page).
- The differences are below the configured comparison thresholds.
- Only dynamic content changed — dates and identifiers.
Everything else is not accepted in bulk — only card by card. Before the press, the product honestly warns: a bulk action can miss a real regression, precisely because every item passed the safety classification, not because a human looked at it. In degraded mode — when the database is broken or space is short — bulk actions turn off completely, while single verdicts keep working.
While a Snapshot Has Not Arrived
It happens that a build has finished while a snapshot is still on its way to the server — for example, the runner lost connection. While there is no content, there is nothing to decide: approving something you have not seen is impossible, and deferring it is not allowed either. The row simply waits until the proof arrives. This is deliberate: a verdict must rest on the picture, not on the memory of how things used to look.
Next: how to check who made every decision and on what grounds — in Audit Log.