Event correlation

What is event correlation?

Event correlation is the work of tying together events that belong to the same process instance or the same business objects. The result decides which events form a single trace or object lifecycle.

An explicit case ID makes this easy when every source event already carries the same stable key. In many systems, though, events are spread across tables, messages, and applications that each use a different identifier.

Correlation then relies on keys, relationships, time, and domain rules. The rules you pick are a modelling decision, not a neutral technical step, and they shape every result that follows.

Correlating on a shared key

An order number present in every event can act as the case ID. Order received, Payment recorded, and Order shipped are grouped on that number.

Check the key for uniqueness, reuse, and lifespan. A ticket number that restarts every year is not globally unique without the year attached. Normalise formats with care, too: stripping leading zeros can make two source codes look equal when they are functionally different.

Correlating through relationships

Sometimes an invoice event carries only an invoice ID while an order event carries an order ID. A relational link table can join the two so their events land in the same case.

One-to-many relationships force a choice. One order can have several deliveries, and one invoice can cover several orders. A classic event log usually pins down a single case notion up front, while object-centric event data keeps the multiple relationships and defers the choice until analysis.

Correlating on time and attributes

With no shared key, a rule can match events on customer, amount, and a time window. This is more probabilistic and can produce several candidates for the same link.

A payment for the same amount within two days need not belong to the invoice you expect. Use a score, a tolerance, and an explicit ambiguous status. Do not force a match just to get every event into a trace. An uncorrelated event that stays visible is safer than a confident but wrong link.

A service ticket example

The service desk works with ticket IDs. The phone system and the monitoring platform do not always know that ID.

An integration links a call to a ticket when the agent selects it during the conversation. Monitoring alerts are attached as candidate links through the configuration item and a narrow time window. The event log keeps proven relationships apart from inferred ones, so an analysis can test how sensitive its findings are by dropping the uncertain links.

Convergence and divergence

Convergence happens when the same event is copied into several cases, such as one payment attached to every order line. Frequencies and lead times can then inflate.

Divergence happens when events from several objects are merged into one case and form an artificial order, such as parallel deliveries inside one order. Spot both problems at the moment you choose a case notion. An object-centric model is often a better answer than adding more copy rules.

Ordering events after correlation

Once events are correlated they still have to be put in order. Identical or coarse timestamps do not give a reliable total order.

Use extra sequence numbers, the order the source system recorded, or lifecycle information where it exists. Do not invent milliseconds to break ties for the sake of appearances. Record how you break ties, because a directly-follows graph and the discovery algorithm behind it can change when the order changes.

Quality and privacy

Measure uncorrelated events, cases with no start or end, unlikely cardinalities, and conflicting matches. Sample both ordinary and extreme traces and compare them against the source systems, and let domain experts say which relationships are even possible in the business.

Correlation also has a privacy edge. It can join separate, harmless datasets into a detailed picture of a person or customer, and a pseudonym that stays stable across sources is still a quasi-identifier. Limit the linking to the analysis question, protect the mapping tables, and check the purpose, legal basis, access, and retention before you join sources. Being able to link data is not the same as being allowed to.