Skip to content

Event Knowledge Graph

A tool — instantiates Event-Log-Centered Modeling

Materializes the event log as a queryable graph, linking events, participants, and entities across layers with typed participation and causal-or-correlation edges.

Most projections of an event log answer questions about one axis — a timeline, a balance, a single entity's state. An Event Knowledge Graph answers relational questions the log cannot answer directly: how a set of happenings, actors, and objects are connected across many hops. It projects the log into a graph where events and the entities they touch are nodes, and every participation, location, and inferred link becomes a typed edge — actor —performed→ event, event —transferred-to→ account, event —correlated-with→ event. Its defining move, and the one that separates it from every other projection here, is that connection itself is the first-class object: the graph is the layer where "who is linked to whom, through which events" becomes traversable, and where a causal or merely correlational link is drawn explicitly and labelled as one or the other rather than left implicit in the raw stream.

Example

An anti-money-laundering team is staring at a fraud alert on a single account. The event log has everything — every transfer, login, device fingerprint, and KYC update — but as a flat stream it answers "what did account X do?" and stops there. The Event Knowledge Graph projects that stream into nodes (accounts, people, devices, transactions) and typed edges (performed, sent-to, shared-device-with, same-beneficial-owner-as). Now the analyst can traverse: account X shares a device with account Y, which received three transfers within an hour of X's deposits — a correlated-with edge the graph drew from a temporal-proximity rule, not a caused-by edge, because co-timing is not causation.

Walking two more hops surfaces a ring of eleven accounts funnelling into one beneficiary, invisible in any single-entity view. Crucially, the graph also shows its seams: two "accounts" were merged into one node by entity resolution, and the analyst can click through to the provenance and decide whether that merge is safe before acting on it. The output is not a verdict but a navigable map of connection that turns a needle-in-a-haystack search into a few graph queries.

How it works

  • Project events and their referents as nodes. Each event becomes a node; so does each distinct entity it names (person, account, place, object), pulled up out of the event's fields into the graph's own layer.
  • Resolve identity before linking. References that denote the same real-world entity are merged into one node, so the graph's connectivity is real and not an artifact of spelling variants — the step where most of the value and most of the risk lives.
  • Draw typed edges. Participation (actor→role→event), spatial and cross-layer membership, and inferred links (causal or correlational) are added as distinct, labelled edge types — never collapsing "these co-occurred" into "this caused that."
  • Answer by traversal. Multi-hop questions — rings, shared intermediaries, shortest connection between two entities — become graph walks, which the flat log cannot serve.

Tuning parameters

  • Edge-type ontology richness — how many relationship types you distinguish. More types make queries expressive but raise modelling and maintenance cost; too few collapse meaningfully different links into one.
  • Causal-vs-correlational threshold — the rule that decides when a co-occurrence earns a causal edge rather than a correlation edge. Loosen it and the graph over-claims causation; tighten it and genuine mechanisms go unmarked.
  • Entity-resolution strictness — how aggressively references are merged into one node. Aggressive merging finds hidden links but manufactures phantom ones from false merges; conservative merging keeps nodes clean but fragments real actors.
  • Temporal windowing — the window within which two events are considered related. Wider windows surface slow-moving patterns and drown in noise; narrower ones miss them.
  • Scope and horizon — how much of the log the graph ingests. A focused sub-graph is fast and legible; the whole corpus is powerful and expensive.

When it helps, and when it misleads

Its strength is questions of connection — rings, intermediaries, provenance chains, "how are these two things related" — that a timeline or a state view simply cannot express. Because it is a projection, it is rebuildable and disposable: you can re-run it with a stricter resolution rule and get an honest new map, not a mutated source of record.

The graph's danger is that it looks authoritative. A correlated-with edge read as causation is the classic error — a suggestive path is a hypothesis, not evidence, and the graph will happily draw a compelling shape out of pure co-occurrence.[1] False entity merges are worse: one bad merge fuses two people into a node and invents a connection that never existed, and the more aggressively you resolve identity the more such phantoms you create. And the graph silently inherits every gap in the log — a missing event reads as an absent edge, so "not connected" can mean "not recorded." The discipline that keeps it honest is to keep causal and correlational edges typed apart, to carry entity-resolution confidence and provenance onto every merged node, and to treat the graph as a lens over the log — always rebuilt from it, never edited in place as a second source of truth.

How it implements the components

The Event Knowledge Graph realizes the relational slice of the archetype — turning the stream into a linked structure — not the storage, timing, or state-folding slices:

  • causal_and_correlation_link — its reason for existing: co-occurrence and inferred-cause links become first-class, distinctly-labelled edges, so the two are never confused.
  • participant_role_binding — each actor and object an event names is bound to it as a typed participation edge (performer, beneficiary, instrument), making "who did what to whom" queryable.
  • cross_layer_index — the graph is the cross-layer index: events, entities, and places co-resident as nodes so a query can hop between layers in one traversal.

It does not define the generic projection contract or its rebuild path — that is Event-Sourced Projection — and it does not fold events into an entity's evolving state; that is Entity-Trajectory Projection, whose per-entity histories the graph links rather than reconstructs.

Notes

The graph is a derived view, so its edges are only as trustworthy as the resolution rules and inference thresholds that drew them. Rebuilding it after tightening those rules is cheap and expected; treating a materialized graph as a durable record to be hand-edited quietly turns a lens into a rival source of truth and defeats the whole model.

References

[1] Judea Pearl's ladder of causation distinguishes seeing (correlation) from doing and imagining (intervention and counterfactuals); a graph edge built from co-occurrence sits on the bottom rung and cannot, by itself, license a causal claim. Labelling correlation and causal edges as different types is the modelling expression of that distinction. ↩