Visual checks are useful only when it is clear who approved what, when, and on what grounds. Half a year later nobody will remember why the baseline changed on exactly that day. The audit log answers this question: every meaningful decision leaves a record in it, and these records are immutable.
What Gets Into the Log
A record appears not on every click but on every meaningful change. The log receives:
- Verdicts on snapshots and approval withdrawals.
- Baseline creation on the first run, its approval, deletion, promotion to another branch, and forking.
- Variations: creation, deletion, restoration, expiry renewal, resolving expired ones.
- Settings changes: configuration edits, diff-threshold overrides, the snapshot checklist confirmation, AI budget changes.
- Bulk accepts of safe differences — one record with the list of affected snapshots.
- Actions on builds: marking failed, retrying, deleting.
- Access changes: users, roles, API keys, credentials, variables, environments.
- Failure triage and test healing: cluster verdicts, applying and reverting a proposed heal.
- The log export itself: the fact that someone exported the history is also worth remembering.
Filters
The log fills up quickly, so what you need is found with filters. You can filter by author, by source (human, AI, or system — this way a model’s suggestion cannot be confused with a human decision), by action family, single or bulk actions only, and by period: recent weeks or a custom date range.
Every record shows what was before and what became after, plus a reason if one was given. The before and after fields are shown as an ordinary text comparison — what exactly changed is visible at a glance. The record’s author is a frozen name: even if the user was later deleted, the history stays readable.
Bulk Actions and Risk
A bulk accept of safe differences carries a permanent risk mark — it does not fade with time. Beside it you can see how many snapshots were accepted by the single action. The record can be expanded into individual snapshots to understand what exactly fell under the bulk decision. If some items have no separate records, it says so: the action simply listed its targets inside itself.
Special Marks
Some records get a mark that matters on its own:
- Approved without design approval — a difference in shared interface parts was approved by a person without the design-approver mark. The mark is computed at view time, not stored in the record, so it cannot be “lost” by editing the data.
- Degraded mode — the decision was made while part of the product was working badly (for example, the database was not answering). This explains why bulk actions were unavailable in that period.
- User deleted — the record’s author no longer exists in the system, but their name is preserved: the log does not lose history together with the account.
Export
Filtered records export in two forms: a table for spreadsheets and a file for programs. The export is not “everything there is” but exactly what remains after the filters. If there are too many records, the export is refused and names their number — the filters must be narrowed. This way the whole archive cannot be pulled out of the log by accident.
What the Log Does Not Have
Log records cannot be edited or deleted — not a single one. This is not “hard” but impossible: the log exists precisely so it can be leaned on in a disputed situation. If some action was a mistake, it is not erased — instead a new record appears that explains the cancellation.
Next: how to work through a failed build when there are many failures — in Build Failure Triage.