Self-healing audit trail

The audit trail answers who or what changed which locator, why, and on what evidence. Every self-healing decision in the project is written to it as it happens, whether a person or a rule made it, including the decisions that changed nothing.

Open Self-healing → Audit trail for the whole project. From a test, the Self-healing audit trail for this test link in its History opens the same view narrowed to that test. Show the whole project widens it again.

Everyone in the project can read the trail. Entries about someone else’s private test are left out. An entry about a component step that a private test found is shown without naming the test.

What is recorded

Entry	When
Suggested / Seen again	A run filed a suggestion, or found the same fix again
Rules checked	After a run, the project’s rules looked at a suggestion it filed or found again: the verdict and, condition by condition, why. Only written when the project has an enabled rule.
Applied by a rule	A rule applied a fix
Rejected by a rule	A rule rejected a suggestion
Left for review	A rule would have acted but was held back: dry run, a guardrail, the daily limit, a paused rule… The entry says which. See What a rule records.
Approved / Rejected	A person decided, with their note if they left one
Reverted	A person reverted a fix. For a rule’s fix, it also says whether the rule was paused for that step.
Rule created / Rule changed / Rule deleted	The rule in full, as it then was

Each entry records:

when it happened, and the actor: a person, or a rule written as rule:<id>@v<version>, so you can tell exactly which version of a rule decided,
the test, step and, where relevant, the component and the run,
the locator before and after, shown as a line-by-line diff,
the evidence the decision was made on: tier, confidence, lead, risk and how many runs found it,
for a fix, the revision it changed and the one it produced (e.g. Test v4 → v5),
for a rule’s decision, a snapshot of the rule as it was at that moment.

Editing a rule does not rewrite history. An entry from March still shows the rule as it was in March, even after it was edited in April or deleted.

Finding entries

View	Shows
Changes (default)	Everything that changed a test or a rule: fixes, rejections, reverts, rule changes
Fixes and reverts	Applied fixes (by a rule or a person) and reverts
Held back	Rules checked and Left for review: what the rules decided not to do, including dry-run results
Rule changes	Rules created, changed and deleted
Everything	Every entry, including Suggested and Seen again

Narrow any view with From and To dates. Entries are newest first.

Export CSV downloads the entries of the current view and dates, one row each, with the before and after locators, versions, evidence, reasons and each entry’s hash. Spreadsheet formulas in names are neutralised, so the file is safe to open in Excel.

Verify integrity

The trail is append-only, one file per project. Each entry carries a hash of itself and of the entry before it, so entries form a chain. Verify integrity walks the whole chain and reports either that every entry is intact, or the first entry that was changed, removed, added or moved after it was written.

Verification always checks the whole project, including entries you cannot see, so the answer is the same for everyone.

The chain shows that the file was tampered with. It does not stop someone with access to the server’s data folder from rewriting the whole file and its chain. Back up the data folder and protect it as described in Data and backup.

The trail cannot be skipped

An automatic fix is not applied if its decision cannot be written to the trail. The suggestion waits for a person instead.
A person’s approval, rejection or revert still goes through if the trail cannot be written (for example, a full disk). The server log records a warning, and the general server audit log still records the action.