Precision (process mining)

What is precision (process mining)?

Precision measures how tightly a process model sticks to the behaviour seen in your event log. A precise model, after a given history of steps, mostly allows the next steps that also appear in the data. A loose model allows a lot of paths that never happen in practice.

Precision is the counterweight to fitness in conformance checking. Fitness asks whether the model can reproduce the recorded cases. Precision asks whether the model also permits a lot of other behaviour on top of that. You need both, because each one alone is easy to fool.

A model in which every activity is always possible may have perfect fitness, since it can replay anything. Its precision is low, because it barely distinguishes between a plausible next step and one that was never observed.

The intuition: allowed next steps

Picture a model where, after the step check order, every observed case goes on to either approve or reject. The model, however, also allows ship, cancel, and pay at that same point.

Those extra exits are not necessarily wrong. An event log never contains every possible future. But a large number of never-observed choices makes the model less specific to the data you are analysing. It describes a wider world than the one your log shows.

Most precision measures work by comparing the model states reached during replay with the activities that actually follow in the log. The allowed-but-never-taken steps are often called escaping edges: the points where the model lets you escape into behaviour the data never took.

Why there are several precision measures

Process models can contain loops, parallel branches, duplicate labels, and silent transitions. That makes it hard to say exactly which model state matches a given run of steps, so different tools answer the question in different ways.

Some methods use token-based replay and the markings it reaches. Others build prefix automata or use alignments to synchronise states. The scores these methods produce are not automatically comparable, so a precision of 0.8 in one tool is not the same as 0.8 in another.

Hidden duplicate behaviour complicates it further. A model can produce the same visible sequence through more than one internal path. A good precision measure tries to account for that freedom without punishing valid parallel behaviour that simply has several legitimate orderings.

Precision versus fitness

High fitness with low precision points to a model that covers the log but gives away too much freedom. Low fitness with high precision fits a strict model that only allows a small slice of the observed behaviour.

A workable model usually has to score reasonably on both. The right balance depends on the goal. A compliance model can afford to be stricter, while an exploratory model from process discovery should leave room for valid variants that have not been observed yet.

Do not optimise blindly for both numbers at once. A complicated model can describe historical data very precisely and still be unreadable, and it can be brittle when new cases arrive that no one has seen before.

Not the same as precision in machine learning

In classification, precision means something different. There it is the share of positive predictions that turn out to be genuinely positive, and it is usually reported next to recall. That pairing is covered under precision and recall.

Precision in process mining is not about positive predictions. It compares the behaviour a model allows against the behaviour an event log shows. The same word points to a different calculation and a different question, so in reports that touch both fields, write out which precision you mean. Otherwise a reader from a machine learning background will expect a classification metric and misread the number.

The event log is not the whole reality

Low precision means the model allows more than the log you studied. That extra behaviour might be unwanted, but it might also be rare, seasonal, or simply absent from the period you extracted. A small sample makes almost any model look too loose.

Segmentation has the same effect. A path that never appears for private customers can be perfectly valid for business customers. Use representative data, and check the extra behaviour with the people who own the process before you call it a fault. Treat never-observed behaviour as something to investigate, not as an automatic error.

What to watch out for with precision

Record which precision variant and which software settings you used, then compare models on the same log, with the same activity mapping and the same method. A comparison across different tools or settings is meaningless.

Look beyond the total score to where the model and log diverge. Allowed next steps after a risk control matter far more than a small difference in a harmless administrative loop. Judge precision together with fitness, simplicity, generalisation, and the intended use. A model worth having is more than a good numerical fit; it is also understandable and usable for the decisions people take from it.