In the Diamond Model, why does every event carry a timestamp, direction and result?

## The mistake this corrects Ask a competent engineer what the Diamond Model is and you usually get the four core features — adversary, capability, infrastructure, victim — and a drawing. Ask what the meta-features do and the common answer is that they are metadata, the fields you fill in around the real content. That is exactly backwards. The four core features say *what* is connected. The meta-features are what turn a connection into a **claim**, and a claim is the only thing in analysis that can be checked, aged out, or shown to be wrong. ## The event, in full The model's atomic unit is not an intrusion and not a diagram. It is an **event**: an adversary deploys a capability over infrastructure against a victim, at a time, in a direction, in a phase, with a result, held with some confidence. Everything after the fourth noun is a meta-feature, and each one closes a specific hole. ### Timestamp An event has a start and an end, not a moment. This is the meta-feature people drop first and regret most. Adversary infrastructure is leased, rotated and re-leased; cloud addresses in particular pass between tenants on a timescale of days. A pivot that said *this host is the same operator's* in February may be asserting something about a completely different tenant by May. With the timestamp attached, that edge is a bounded statement about a window. Without it, the graph makes a permanent claim, and a permanent claim can never be falsified — which sounds like strength and is actually the absence of information. The timestamp also gives you the only honest way to retire an edge. An artefact does not become wrong; it becomes stale. A dated edge can be aged out on its own terms. ### Direction Direction records which way the event ran between core features: infrastructure to victim, victim to infrastructure, infrastructure to infrastructure, adversary to infrastructure, and so on, with bidirectional and unknown as legitimate values. This is not pedantry. "A staging host reached a cloud control-plane endpoint" and "a cloud control-plane endpoint reached a staging host" are different events with different implications about who initiated and who was already inside. Draw the edge without an arrow and a later reader will guess, and half the time will guess the flattering way. Direction is also frequently genuinely **unknown**, and recording it as unknown is a real answer, not a gap to be tidied up. ### Result Result takes success, failure or unknown. It is the meta-feature that separates *contact* from *outcome*. A pivot that reaches a new victim vertex through shared infrastructure almost always has result **unknown** — you have established that an edge exists between an operator's host and an asset, and nothing whatsoever about what happened at the far end. Writing `success` there because the graph looks alarming is the single most consequential error available in this model, because everything downstream inherits it: the peer organisation you contact, the priority you assign, the story you tell. Failure is equally load-bearing and equally under-recorded. An adversary attempt that did not work is a real event with a real capability and real infrastructure, and dropping it distorts everything you later say about what the operator can do. ### Phase and confidence Phase places the event in the ordering you are using, so events can be strung into a sequence rather than sitting as an unordered pile. Confidence records the analytic weight of the whole tuple, which matters most for the vertices you filled by inference rather than observation — a pivoted vertex and an observed vertex sit at the same place on the drawing and deserve very different confidence. ## What this looks like in practice Take the certificate pivot: one self-signed certificate, the same public key, fronting two staging hosts, and an edge from the second host to a cloud control-plane endpoint at an organisation nobody has touched. As a bare graph: *operator infrastructure connects to that company*. Alarming, unfalsifiable, and quite possibly wrong. As an event with meta-features: *between these two dates, a host presenting this public key initiated a connection toward this endpoint; result unknown; confidence moderate because the endpoint's ownership is inferred from lease records.* Now every part of it can be attacked. Someone can show the address changed hands inside the window. Someone can show the connection was inbound scanning of the whole range rather than anything directed. Someone can show the key leaked and is now used by two unrelated operators. That is what a usable claim looks like. ## The test to apply Before you accept an edge on a diamond, ask what evidence would remove it. If nothing would — if the edge is a bare line between two nouns — the meta-features are missing, and you are looking at a picture rather than an analysis.