Alignment (process mining)

What is an alignment (process mining)?

An alignment places an observed process trace next to the behaviour a process model allows, and finds a shared sequence of steps that shows which activities match and where the log or the model goes its own way. Instead of only telling you that a case does not fit, it reconstructs a path through the model so you can see the mismatch step by step.

Alignments are used above all for conformance checking. They give you more than a score. They give you a reconstructed route through the model, which makes it visible where a step was skipped, added, or done in a different order.

When several explanations are possible, the algorithm looks for the alignment with the lowest configured cost. Optimal here means cheapest according to the chosen cost model, not necessarily the only business explanation for what happened.

Three kinds of moves

A synchronous move pairs an event from the log with the same activity in the model. Observation and model agree at that point, and no deviation is recorded.

A log move handles an event that has no matching step in the model. That can point to extra behaviour, a mislabelled activity, or an activity the model simply does not contain.

A model move runs a step in the model with no matching event in the log. That can represent a skipped activity, missing logging, or a necessary silent transition. Silent transitions usually carry no deviation cost, because they are meant to have no visible event in the first place.

Worked example with an order

The model prescribes receive, check, approve, and ship. The event log for one case contains receive, approve, and ship.

The alignment pairs the three events that are present as synchronous moves and places check as a model move. That is a sharper diagnosis than a bare notice that the trace does not fit: at exactly that position, an expected step is missing from the log.

Now take the trace receive, check, call, approve, ship. If call is not part of the model, it becomes a log move. The analyst then has to decide whether the model is incomplete and should include call, or whether calling was behaviour that should not have happened.

Costs decide the explanation

Every non-synchronous move can carry a cost. A simple setup charges one point for each visible log move and model move. In real applications the costs can differ: skipping a legally required control should weigh more than a missing administrative note.

Those costs decide which path comes out as optimal. When two activities share a label, or the model contains many loops, several different alignments can share the same total cost, and the tool has to pick one.

Document the mapping, the costs, and how silent transitions are treated. Without that context an alignment score is hard to compare from one analysis to the next.

Alignment versus token-based replay

Token-based replay plays a trace straight through the model and inserts tokens whenever a transition cannot fire. It is usually faster and gives you diagnostics about missing and left-over tokens, but the repair path it finds is not necessarily the smallest overall deviation.

An alignment looks at the trace and the model together and searches for a minimal deviation path. The result is usually easier to interpret at the level of individual activities, but the search space can grow large. On complex models, tools fall back on heuristics, state-space limits, or per-variant computation, so the practical outcome can depend on time limits and algorithm settings.

From alignment to fitness

The cost of an alignment can be normalised into a fitness score. A trace with only synchronous moves reaches the maximum alignment fitness. More deviations, or more expensive ones, pull the score down.

A single average log score can let frequent variants dominate, so show the distribution across variants, process steps, and deviation types as well. A high overall score can hide a rare but serious violation, which is exactly the kind of case an alignment is good at surfacing.

What to watch out for with alignments

An alignment treats the event log as an observation, not as infallible truth. Missing events, actions recorded twice, and cases correlated to the wrong id all turn up as deviations too. Check activity labels, lifecycle, time order, and the process boundaries before you draw conclusions, because a model move can mean a skipped control or just a logging gap.

Use alignments to find concrete cases, then discuss those cases with people who know the process. Only then can you decide whether the logging, the model, or the actual execution is what needs to change.