Introduction

Triage is the three things you can actually change on an incident: who owns it, where it has got to, and what you found out. Everything else on the record is fixed. That constraint is what keeps an incident usable as evidence, and it makes triage a small job with a clear boundary.

Where to find it

AI Governance > Incidents > select a row. Triage happens in the drawer that opens over the list.

Read this before you start: nothing saves until you save

Changing the status, picking an assignee and adding notes all stage locally. They persist when you press Save, together. Cancel discards the lot.

Note: Closing the drawer is not saving. This is the single most common way triage work gets lost — reassign, write a careful note, close the panel, and none of it happened. The Save button stays disabled until something has actually changed, so an enabled Save is your signal that you have unsaved work.

The three moves

1. Assign it to a person — The Assigned to dropdown picks from your platform's users. Unassigned incidents show Unassigned, which is honest and is also how incidents sit untouched for weeks.

2. Move the status — Open → In Progress when you pick it up; Resolved or False Positive when you are done. Any status can follow any other.

3. Write what you found — The Note field takes a line at a time — type and press Enter, or use the add button. Notes show their text only. Anyone who can open the incident can delete a note; changes apply when you click Save.

What a good triage note contains

The record already holds what was detected, by which control, on which asset, in which run. A note that repeats any of that is wasted. What the record cannot hold is your reasoning — and that is the whole point of the field.

The test is simple: would this note let a colleague reach the same conclusion in six months without re-opening the trace? If not, it is a status change wearing a note's clothes.

Who to assign it to

The useful default is the agent's owner — they are accountable for it and are usually the only person who can tell a genuine breach from expected behaviour for that agent.

Two cases break that default:

• A suspected false positive belongs with whoever owns the control, not the agent. The agent did nothing wrong; the rule did.

• A cluster across many agents is one problem, not many. Assign the cluster to one person rather than routing each incident to a different owner who will each investigate it separately.

Closing well

1. Decide which kind of closure it is — Resolved means the control was right. False Positive means it was wrong. This is the field your control-tuning work depends on — see Tuning Policy Noise.

2. Leave a note saying why — A closed incident with no note is indistinguishable from a queue being cleared.

3. If it was a false positive, act on the control — Marking it changes one record. Editing the control changes every future one. Closing without doing the second is how the same false positive arrives again next week.

4. Press Save — Say it once more, because it is the step that gets skipped.

"Triage that only changes statuses is queue management. Triage that changes controls is governance."

What triage cannot do

Related

• Incident Data Model & Lifecycle

• Investigate an Incident

• Escalation & Notifications