Reading a discovered model

A discovered model is a claim about your process. This page is about reading it critically.

The shapes

Boxes are activities — things that happened, named as your data names them.
Arrows are ordering — this tended to follow that.
A split into several arrows is either a choice (a case goes one way or the other) or parallelism (both happen, order not fixed). Which one it is matters enormously, and the model distinguishes them visually.
The start and end markers show where cases enter and leave.

Numbers on activities are usually frequencies: how many cases passed through. Thick arrows carry many cases; thin ones carry few.

Four things to look for first

The happy path. Follow the thickest route from start to end. That is what usually happens, and it is the baseline everything else deviates from.

Loops. An arrow going backwards means rework: something was done again. Check credit → Request documents → Check credit is a process telling you it did not get what it needed the first time. Rework loops are frequently the most valuable finding in a first analysis, because they are pure waste and usually fixable.

Skips. A path that bypasses an activity everyone believes is mandatory. Sometimes that is a legitimate exception; sometimes it is a control that is not working.

Activities nobody mentioned. Names in the model that were not in the workshop version of the process. These are often the manual workaround that keeps the real process running.

Which parts to distrust

A discovered model is only as good as its log, and three patterns should make you suspicious of the model rather than the process:

Unexpected parallelism everywhere usually means coarse timestamps — activities stamped with the same date cannot be ordered, so the miner assumes they are concurrent.
A very high activity count usually means the activity column holds something too specific — an ID, or a name with a case number in it.
A model that allows everything — where any activity can follow any other — usually means the case ID does not identify one journey. This is the classic symptom of data that is really object-centric being forced into a single case notion.

Simplify deliberately, not reflexively

Real logs contain rare behavior, and showing all of it produces a diagram nobody can read. The Inductive Miner has a noise threshold: raise it and infrequent behavior is filtered out of the model.

Do this deliberately. A rare path is not automatically noise — the 2% of cases that skip a compliance check may be the entire point of the analysis. Filter to make the common case readable, then go back and look at what you filtered out.

You know what happens. Find out what it costs.