Fitness (process mining)

What is fitness (process mining)?

Fitness tells you how well a process model can reproduce the behaviour that your systems recorded. If the cases in your event log can run through the model from start to finish without getting stuck, fitness is high. If many cases skip steps, take steps in the wrong order, or do things the model has no place for, fitness drops.

Fitness is one of the quality dimensions in process mining, and it sits at the heart of conformance checking. It answers one question: does the observed behaviour fit the model? It says nothing about how much extra, never-observed behaviour the model would also allow. That second question belongs to precision.

The score usually falls between 0 and 1, where 1 means every case flows through the model perfectly. But the number depends on the method, the normalisation, and how results are averaged, so never report a fitness figure without saying how it was calculated.

Fitness from token-based replay

The oldest way to measure fitness is token-based replay. Each case is played back on a Petri net version of the model, one activity at a time. When an activity cannot fire because the required tokens are not there, replay inserts the missing tokens and counts them. When tokens are left behind in the wrong places after the case ends, it counts those too.

Replay fitness compares missing tokens against consumed tokens, and left-over tokens against produced tokens. In plain terms, it is 1 minus the average of those two ratios. Fewer repairs means a higher score. A case that needs no artificial tokens at all scores a perfect 1.

This approach is fast and points you to the exact place and transition where things went wrong. Its weakness is that it repairs problems locally, so on models with many choices the diagnosis can differ from a proper global comparison.

Fitness from alignments

A newer approach uses alignments. An alignment lines the case up against the model and finds the cheapest way to explain the differences using synchronous moves, log moves, and model moves. The deviation cost of that best path is turned into a fitness score.

A case that matches the model step for step gets the maximum. Every extra or missing step lowers the score according to the cost model. You can make business-critical deviations weigh more heavily, but once you do, the score is no longer comparable to a standard calculation.

Alignment fitness is usually more accurate and easier to pin to a specific activity. The trade-off is compute: on large logs and complex models it takes more time and memory than replay.

Fitness versus precision

Fitness on its own is easy to game. A model with a single loop that allows every activity in any order can reproduce almost any case, so its fitness is close to perfect. It also tells you nothing, because it permits everything.

Precision measures the opposite: how much behaviour the model allows that never actually shows up in the log. A useful model balances the two. It covers the reality in your data without leaving every path open. Simplicity and generalisation matter as well, since a model that lists every historical case word for word fits beautifully yet is unreadable and rejects valid future variants.

Worked example

An order-handling model expects four steps: register, check, approve, and ship. Out of a hundred orders, ninety follow that exact path. Ten are missing the check step in the log.

The overall fitness will still look high, because the large majority fits. Yet the deviation may be serious if the check is a legal or financial safeguard. A single average hides that.

So read fitness alongside the number of cases involved, which steps deviated, and the amounts, customers, or risk categories behind them. A log with many perfect cases and a few very poor ones can share the same average fitness as a log where every case has a small deviation. Report the spread as well as the mean.

What to watch out for with fitness

A low fitness score is not always a process problem. Poor data quality produces the same symptoms: missing events, cases correlated to the wrong id, duplicate registrations, or unclear lifecycle statuses all look like deviations. Check the log before you blame the process.

An outdated or overly strict model can reject behaviour that is perfectly valid in practice. The reverse also holds: a high fitness on a model that was discovered from the same log is no achievement, since the algorithm was tuned to fit that data in the first place.

Treat fitness as one input to a judgement, not the judgement itself. Read it together with precision, model complexity, a review with the people who own the process, and a look at the concrete deviations behind the number.