Incidents and audit in the console
In cloud mode every quarantine and audit entry is reported to the console as a decision record. This page lists what each record carries: its fields, the status it moves through, the outcome of a held change, and the fidelity of the stored diff.
The decision record
Each incident is one record. These are its core fields:
| Field | Meaning | Values |
|---|---|---|
path | The file that changed | Path only, never content |
reason | A short reason string for the outcome | Text, length-capped |
danger | The graded danger value, when numeric | A number, or absent |
threatLevel | Severity tier | low, medium, high |
category | The attack category, when set | From a fixed taxonomy |
redactedDiff | The judged change, redacted and added-only | Capped projection, never full content |
originalHash | Hash of the file before the change | SHA-256 |
platform, displayName | The device the incident came from | Copied onto the record so it survives device deletion |
redactedDiff is a projection, not the file: added lines only, secrets and PII replaced, size-capped. Removed-line text never leaves the device.Status: the review lifecycle
The status tracks a case from report to resolution:
| Status | Meaning |
|---|---|
pending | Reported, waiting for a decision |
superseded | Replaced by a newer case on the same path |
approved | The reviewer released the change |
discarded | The reviewer rejected the change |
applied | The device confirmed an approved change was applied |
stale | Approved, but the file had changed in the meantime |
expired | The quarantine blob passed its retention window and was deleted; the case is no longer restorable |
Kept candidates
A special status marks a middle-band change the user kept on the device:
kept_candidate: a user confirmation-prompt change the human chose to keep.- No review case: there is no quarantine blob and no restore or discard. The kept content becomes the new reference point and is recorded as approved by a human, visible in the console.
- Training candidate: it is recorded as a false-alarm candidate, not a case to action.
Outcomes of a held change
For a change that went through the user confirmation-prompt hold, the outcome names how it ended:
| Outcome | Meaning |
|---|---|
kept | The human kept the change; recorded as a false-alarm candidate |
rejected | The human rejected it; the change was rolled back |
timed_out | The answer deadline elapsed; the change was rolled back |
capped | The absolute hold limit elapsed; the change was rolled back |
Diff fidelity
A fidelity marker records whether the stored diff is byte-faithful to what was judged:
| diffFidelity | Meaning |
|---|---|
exact | The stored text hashes to the judged text: byte-faithful evidence |
projection | The stored text is provably a reduced projection of the judged text |
| absent | No judged-text hash was reported: not treated as verified |
exact: a record from an older device without a hash appears as unverified, never as byte-faithful.Feedback candidates
A reviewer can attach an after-the-fact judgment to an incident:
feedbackCandidate: set when a reviewer records a verdict, attack or legitimate, on an incident.- No device action: feedback does not change the status and triggers nothing on the device.
- Training signal, not truth: it marks the incident as a candidate for the improvement pipeline, gated by diff fidelity.
Read next
Why a private device shows none of this: cloud or private. The bytes behind redactedDiff: what Cloud mode sends. How long a case is kept and when it turns expired: storage, retention and cleanup.
Every decision, on the record.
Path, reason, threat level and a reversible outcome, per incident, reviewable in the console. Free for Linux, macOS and Windows.
Sign me up