Introduction
An incident is one control firing on one piece of content, recorded permanently. Almost everything on it is immutable — three fields are not, and knowing which three tells you exactly what triage can and cannot change.
What an incident is
An incident is created when a control evaluates an input and finds a breach. It records four things together: what was found, what was done about it, which rule found it, and where. Separating those four is what makes an incident useful later — a log line has the first, an alert has the second, and only the last two let you fix the cause.
The record
Field | Holds | Mutable |
| The surface family the incident came from | No |
| What happened: | No |
| The kind of check that fired | No |
| How serious, as stamped by the control | No |
| The control's confidence threshold ( | No |
| The control that raised it | No |
| The policy that control belonged to | No |
| The agent or model it was raised on | No |
| The run it occurred in | No |
| When | No |
| The owner of the asset, and the point the content came from | No |
| Where triage has got to | Yes |
| Who is handling it | Yes |
| Triage notes (text only) | Yes |
Note: The detection half of the record is immutable by design. You cannot edit the severity, reclassify the check, or change what action was taken — and that is the property that makes an incident admissible as evidence. If severity is wrong, the fix is on the control, for incidents from now on. The historical record stays as it was.
Confidence — the field most people miss
Alongside severity, an incident carries a confidence of Low, Medium or High. It comes from the control's confidence threshold setting, not from the individual finding; controls without a threshold record High.
Severity and confidence answer different questions and are routinely conflated:
Severity | Confidence | |
Asks | If this is real, how bad is it? | How likely is it that this is real? |
Comes from | The control's configuration | The control's confidence threshold setting ( |
Use it to | Prioritise | Judge how broadly the control was set to match |
Because confidence is set on the control, every incident from one control carries the same confidence. Use it to judge the control — a Low threshold catches more borderline matches — rather than to rank individual incidents.
The lifecycle
An incident has four statuses. Every incident is created Open:
| Raised, nobody has resolved it |
|---|---|
| Someone is working it |
| Dealt with |
| The control was wrong |
There is no enforced order — you can move an incident to any status from any other, and there is no reopening ceremony. That is deliberate: triage is a human judgement, and a workflow engine that forbids correcting yourself produces worse records, not better ones.
False Positive is the most valuable status
Resolved and False Positive both close an incident, and choosing between them casually destroys the only signal you have about control quality.
Resolved— the control was right and the situation has been handled.False Positive— the control was wrong. Nothing needed handling; the rule needs changing.
Closing false positives as Resolved is the fastest way to a permanently noisy governance programme: the queue clears, the control never gets tuned, and the false-positive rate — the one number that tells you whether a control is worth keeping — reads as zero. See Tuning Policy Noise.
"A queue with no false positives in it usually means nobody is marking them, not that there are none."
How an incident knows which asset it belongs to
Each incident carries scoping markers naming the asset it was raised on. That is what lets the same incident appear in several places without being copied: the global Incidents list, the agent's Incidents tab, the model's Incidents tab, the policy's Incidents tab, and the incident summary card on agent and model Overview tabs.
All of them are views of one record. Triaging it anywhere triages it everywhere.