Anatomy of an event
Everything on this platform is built on one record shape. Detection reads it, response writes it, the auditor re-checks it a year later. This page follows a single event from the machine it happened on to the rule it eventually changed, and shows what it costs at every step.
It happens on a machine
A web server runs a shell. The kernel writes an audit record about it, in the format the kernel happens to use, with the arguments hex-encoded. Nothing about that record is designed to be read by a machine that also has to read a cloud audit log, a firewall syslog line and a SaaS webhook.
The agent's job is not to interpret this. It is to carry it, intact, to the one boundary where every source becomes the same shape.
It becomes one shape
Twenty fields, one envelope, one schema version. A process execution, a failed login and a blocked connection all arrive as the same twenty fields, which is the only reason one detection engine can read all three. The taxonomy is four parts — domain, category, type, activity — and it is the routing and correlation key, not a display label.
Severity is stored as a number and written out as a word, and it reads both back, because a record that cannot survive a round trip through JSON cannot have its seal verified later. That is a small decision with a long shadow.
It gets a name it cannot lose
The identifier is derived from the content, so the same content decoded again produces the same identifier. That sounds academic until an agent's uplink drops. It spools telemetry, reconnects, and replays the backlog — the same frame legitimately arrives twice. With a random identifier, every duplicate becomes a distinct event and the outage is paid for in noise. Derived from content, the second delivery carries the identifier it carried the first time.
The reason it matters this much: detections cite events by identifier, and other events point at their causes by identifier. An empty name is not a harmless blank. It is a pointer that looks like a pointer and resolves to nothing.
Two clocks, both kept
When the thing happened and when the platform first saw it are different facts, and machines disagree about the first one. Both are recorded and neither is quietly corrected into the other. A logical clock and a sequence number sit alongside them so that events from hosts whose clocks drift can still be put in a defensible order.
That 588 milliseconds is not an error to be smoothed away. It is the transit, and an investigation is allowed to ask about it.
It is signed, and it points backwards
The record is rendered to canonical bytes, hashed together with the previous event's hash, and that digest is signed. The signature makes a changed byte detectable. The backward pointer makes an insertion, a deletion or a reorder detectable too — the interesting attack on a log is rarely editing one line, it is removing one.
prev → the previous digest
bytes → the canonical record
If the signer fails, the event keeps its place in the chain and carries no signature. Every verifier then fails it closed and it is flagged unverified rather than dropped — because dropping it would leave a link that the next event still points at, and a silent gap is worse than a visible one.
It is stored once, and handed out as copies
One store, not one per product. Every capability queries it and none keeps a private copy, which is what makes the same record answer a detection question and an audit question. Reads hand back an independent copy, so no caller can reach through a returned pointer and mutate a sealed record. The original source line stays retrievable by reference, so an argument about interpretation can always be settled against what actually arrived.
It points at what led to it
Entities are nodes; events are the edges between them. Because each event names its causes, the store is already a graph — nothing has to be assembled into one later. An alert is therefore a piece of that graph rather than a row in a table: a path you can walk, with the events that produced it attached at every step.
Something is done about it
A world-changing action does not follow directly from a detection. It passes one approval gate, which can allow it, hold it for a person, or refuse it. The gate is told how far the action reaches before it decides, and its reason is recorded in the words it used, not summarised.
The containment itself then becomes an event, in the same twenty fields, sealed into the same chain. What the platform did to your estate is recorded on the same terms as what happened to it.
The second machine does not wake anyone
What the analytics layer learned from this event is compiled into something the edge enforces by itself, and it does not go out to the whole estate at once. It reaches a small ring first, and it advances only on evidence: any failed application halts it, and a host that goes quiet after adopting halts it too. Silence holds the rollout rather than advancing it.
This is the whole argument for one platform instead of four that share a login. The next machine to try the same thing is stopped where it stands, and nobody reads an alert about it at two in the morning.
The same record answers the auditor
No export, no reconstruction, no second system of record. The event is re-read, its seal is re-verified, and if a link is broken the verification names which one. The answer to "how do you know" is the same object the detection used, which is the only version of that answer that survives being checked.