A night of alerts triaged into incidents with evidence

The decision tree

6 typed decisions, each with an action for every answer

At fixed moments in a run, the engine puts one narrow question to a decision model. The decision model never writes text: it answers yes or no with a probability, picks from listed options, or gives a score, about a small slice of the material. The engine then does exactly what this tree says, which is what makes the run auditable. The thresholds are the template's design values, not measured results.

1. 1

   Planner, while planning

   Scope checkYes or no, with a probability

   Before work starts on a unit

   Does this alert come with at least one raw log line and an identifiable host or account?

   Sees only: One alert record with its attached log lines

   Why: An alert without logs cannot be judged, so it goes to a person instead of being closed.

   00.30 and 0.601

   • Yes: 0.60 or higher→thenAccept
   • Unsure: 0.30 up to 0.60→thenAccept
   • No: below 0.30→thenMark unresolved
2. 2

   Before workers, before a task runs

   Small worker or strong modelYes or no, with a probability

   Before a task runs

   Is this alert from a detection rule and asset class for which the runbook gives explicit triage steps?

   Sees only: The alert's rule name, the asset record and the runbook index

   Why: Routine alerts stay on cheap workers; unfamiliar ones get a strong reader.

   00.30 and 0.601

   • Yes: 0.60 or higher→thenAccept
   • Unsure: 0.30 up to 0.60→thenEscalate to a strong model
   • No: below 0.30→thenEscalate to a strong model
3. 3

   After workers, the judge checks

   Evidence checkYes or no, with a probability

   After a worker answers

   Do the quoted log lines match the documented benign pattern on every condition it lists: source, account, process and time window?

   Sees only: The quoted log lines and one entry from the known-benign list

   Why: A wrongly closed alert is how an intrusion is missed, so partial matches stay open.

   00.50 and 0.901

   • Yes: 0.90 or higher→thenAccept
   • Unsure: 0.50 up to 0.90→thenEscalate to a strong model
   • No: below 0.50→thenMark unresolved
4. 4

   Reconciler, while merging

   Conflict checkYes or no, with a probability

   While reconciling

   Do these two alert summaries share a host, account or indicator, close enough in time that one could have led to the other?

   Sees only: Two alert summaries with their entities and timestamps

   Why: Links related alerts into one incident while marking weak links as weak.

   00.45 and 0.801

   • Yes: 0.80 or higher→thenAccept
   • Unsure: 0.45 up to 0.80→thenMark unresolved
   • No: below 0.45→thenContinue
5. 5

   Run control, between rounds

   Retry or stopYes or no, with a probability

   After a rejection or low confidence

   Does this alert involve a privileged account, a directory server or a system the inventory marks as critical?

   Sees only: The alert summary and the matching inventory rows

   Why: Alerts on the assets that matter most are re-read by the strongest model before grouping.

   00.20 and 0.501

   • Yes: 0.50 or higher→thenEscalate to a strong model
   • Unsure: 0.20 up to 0.50→thenEscalate to a strong model
   • No: below 0.20→thenContinue
6. 6

   Accountable person, before anything is settled

   Person decidesYes or no, with a probability

   Before anything is reported as settled

   Does this candidate incident contain any alert that was not confirmed benign against a documented pattern?

   Sees only: One candidate incident with the verdict for each alert in it

   Why: An analyst declares incidents; the swarm never closes anything on its own authority.

   Accountable: An analyst declares incidents and approves any suppression rule; the swarm never closes an alert on its own authority.

   00.10 and 0.301

   • Yes: 0.30 or higher→thenAsk a person
   • Unsure: 0.10 up to 0.30→thenAsk a person
   • No: below 0.10→thenAccept