Correlation and incidents

An incident is the operator-owned form of a correlation detection. The sequence evaluator identifies a story across events; the alert writer routes that story into incident persistence rather than pretending it is a single-event alert.

Traceability

An incident is named from the correlation detection and preserves one event per stage in rule order. The detection ID ties the operational record back to the analytical decision. A repeated batch does not create a new story with a new identity. Assignment and state changes do not rewrite component events or the detection.

Confidence is separate from severity

A severe sequence can have weak ordering evidence when endpoint clocks disagree. The platform derives confidence from measured timing spread relative to the story and its window. The rule author's severity is not a claim about clock agreement.

Current boundaries

The current incident does not group alerts. That would need a supported event-to-alert index in the operational store. There is no documented generic graph engine, arbitrary entity-link scoring system, or automatic response planner. Do not infer those capabilities from the term XDR.

Use the incident contract for states, stage records, and API messages, and the HTTP route reference for search, history, assignment, and transitions. For a story that did not appear, inspect temporal rule constraints before blaming persistence.

Source evidence

Reviewed against the source baseline. Seagull-backend-v2/docs/decisions/0020-a-sequence-is-decided-by-the-window-that-holds-it.md · Seagull-backend-v2/docs/decisions/0021-an-incident-is-a-correlation-somebody-owns.md · Seagull-backend-v2/internal/incident/raise.go.