precedents.md

Post-Mortem Map — Precedent Research

Contents

Short answer
Precedent survey
What the map does that a table/timeline can't
What the map does badly
Gut-check verdict
Sources

Research pass answering the open question from initial-prompt.md:

What is the value of a visual map really? Are we just looking for a problem to fit our solution? Are there existing precedents?

Date: 2026-07-24. Sources at the bottom.

Screenshots: product screenshots of these precedents are in precedents/ (Defender attack story GIFs, Detective finding-group graph, SentinelOne Process Graph, Wiz attack paths).

Short answer

Yes, there are strong precedents — an entity/actor graph on an incident page is an industry-standard pattern, shipped by Microsoft, AWS, Wiz, SentinelOne, CrowdStrike, and Palo Alto in exactly the position c18 proposes: on the incident detail page, alongside (never instead of) tables and timelines. We are not inventing a problem. The honest caveats are about when the map earns its place and what it must not pretend to know — captured in the verdict section.

Precedent survey

Microsoft Defender XDR — "Attack story" / incident graph

The closest precedent to the c18 concept. When an analyst opens an incident, the attack story view is the centerpiece of the investigation page: an interactive graph connecting the suspicious entities of the attack to their related assets — users, devices, mailboxes, applications. The root node on the left is initial access; branches to the right show lateral movement and impact. Analysts can click any node for entity details and take remediation actions directly from the graph, and can "play" the alerts chronologically to watch the attack unfold over time.

Nodes: entities + assets (user, device, mailbox, app, file, process)
Edges: attack relationships ("spread to", "accessed", "sent")
Time: handled with a play/scrub affordance layered on the graph, not encoded in layout alone
Position in workflow: incident page centerpiece, used for both triage and retrospective understanding

Amazon GuardDuty + Detective — finding groups / behavior graph

Detective builds a behavior graph from up to a year of historical activity and renders each finding group (a correlated cluster of findings + resources belonging to one security event) as an interactive graph of "the events, resources, and security findings that make up an event." Explicitly pitched at root-cause analysis after detection — the most post-mortem-flavored precedent. GuardDuty attack sequences pivot directly into it.

Nodes: AWS resources, principals, findings
Edges: observed relationships and actions between them
Time: separate activity-volume timeline views over a selected window
Position in workflow: investigation/root-cause, after the alert — closest to a post-mortem context

Wiz — Security Graph / attack path analysis

A different genus worth distinguishing: Wiz's graph models the standing state of the environment (nodes = identities, workloads, policies; edges = "can assume", "is exposed to internet", "has access to", "contains") rather than a specific incident's event history. Attack paths are traversals over that state. Relevant to c18 because it proves the value of state on the map — a node being internet-exposed or a bucket containing PII is exactly the "sensitive file / dis-allowed MCP server" overlay in the c18 prompt. But it visualizes potential paths, not what happened.

SentinelOne — Storyline / Singularity Process Graph

Every event the agent captures is tagged with a Storyline ID that flows from the first suspicious process through every child process, thread injection, file drop, and network call. The Process Graph renders that chain from initial execution through MITRE ATT&CK classification. Notably, SentinelOne pairs the graph with a timeline view — the graph carries structure (parent/child, injections), the timeline carries sequence.

CrowdStrike Falcon — incident graph view

Incident page offers a graph view where analysts add data elements progressively and click process nodes for command lines and process genealogy. Pattern of note: the graph starts small and grows on demand rather than rendering everything — an answer to the hairball problem.

Palo Alto Cortex XDR — Causality View

Renders the entire process execution chain that led up to an alert, with per-node context. The name is the honest part: it only draws edges the agent actually observed (process spawned process), which is why it can call itself a causality view. Edges that are merely temporal or inferred don't get drawn as causal.

AI-agent-specific precedents (emerging, no dominant player)

Agent observability tools (e.g., Galileo's Agent Graph, MCP tracing tools) are starting to render agent trace graphs — paths through multi-agent reasoning loops, MCP client/server call hierarchies. MCP security vendors (Nightfall et al.) inventory MCP servers and scan tool calls but present results as tables/alerts, not incident maps. Nobody owns "the post-mortem map of an agent incident" yet — actors like MCP servers, repos, and model endpoints with policy-state overlays (dis-allowed, sensitive) are not a picture any incumbent draws today. That's the differentiated part of c18; the interaction pattern itself is well-proven.

What the map does that a table/timeline can't

Consistent across precedents:

Scope / blast radius at a glance — "how far did this go" is a shape question. Defender sells the graph as showing "the full scope of the attack"; Detective as "the scope of the incident and all affected resources."
Paths, not just participants — a table lists actors; only the graph shows how the incident moved between them (agent → MCP server → file → external endpoint). This is the exfiltration-path story.
Fusing many alerts into one incident picture — when one incident spans multiple findings, the graph is the join surface (Detective finding groups, Defender incidents).
State anchored to actors — badges on nodes (Wiz's exposed/PII, our sensitive/dis-allowed) read faster than a state column scanned across rows.

What the map does badly

Equally consistent:

Sequence. Every serious precedent pairs the graph with a timeline or a play control. Layout position is a bad encoding for time. If the incident story is "then, then, then," a timeline/event chain wins.
Density. Graphs hairball beyond a few dozen nodes. CrowdStrike's answer is progressive disclosure; Defender's is grouping related assets. A post-mortem map must be curated to the incident's actors, not the whole environment.
Implied causality. A drawn edge reads as "this caused that." Cortex XDR earns its edges from observed process ancestry. If our telemetry only supports "these two events were in the same session," drawing a solid arrow between them is a lie. Observed vs inferred must be visually distinct.
Small incidents. With 2–3 actors, a card layout (see app/pages/c13/wireframes/wf1/ai-agent-policies-v1/violation.vue — Source/Target actor cards) delivers the same comprehension with less machinery.

Gut-check verdict

The map is justified, with conditions. It is not a solution looking for a problem — six major security products put an actor graph on the incident page, and post-incident comprehension (Detective, Defender's play-back) is an established use, not just live triage. The specific c18 framing — agent incidents whose actors are users, agents, MCP servers, files, repos, and model endpoints, with policy state overlaid — has no incumbent precedent, which makes it worth prototyping.

Conditions the brief must carry:

The map is the orientation layer, not the record. It sits at the top of the incident page and answers "what happened, who was involved, what state were they in" in seconds; tables/timeline below remain the evidence.
It earns its place when the incident has roughly four or more actors across two or more types, and the path between them is the story. The brief should not force a map onto incidents that are a single actor doing one bad thing.
Sequence lives in a timeline companion, not in graph layout. The map may number its edges or offer step-through, but the linear record is a separate element.
Observed vs inferred edges are visually distinct, and no edge is drawn that telemetry can't support (c15 "do NOT invent" rule).