How Discovery Works
What the algorithms do, the trade-off between fitting the data and staying readable, and why two tools give different maps.
Explainer
Discovery turns an event log into a model. Every algorithm makes a trade-off, and knowing which one explains most disagreements between tools.
The basic idea
Read cases in order and record which activity follows which.
Count the frequencies, producing a directly-follows graph: nodes for activities, edges for observed transitions.
That graph is the raw material. It fits the data perfectly and is unreadable for any real process.
The four criteria
Every algorithm balances these, and improving one worsens another.
Fitness: does the model allow the behaviour actually observed.
Precision: does it also allow behaviour that was never observed. A model permitting anything has perfect fitness and no precision.
Generalisation: will it still describe next month's cases.
Simplicity: can a person read it.
A model can have any three. Choosing which to sacrifice is a judgement about what the map is for.
What the filters do
Frequency filtering hides rare paths. The usual first control, and it is where the map becomes readable.
It also hides the interesting cases. The expensive failures are frequently rare.
So filter for the overview and unfilter for the investigation, and never present a filtered map as the process without saying what was removed.
Report the coverage: "this model describes 78 percent of cases."
Why two tools disagree
Different algorithms, with different trade-offs.
Different default filtering.
Different tie-breaking on simultaneous timestamps.
Different handling of incomplete cases.
None is wrong. The disagreement is a property of the choices, which is why the choices belong in the report.
What to look at rather than the map
The map is the least useful output for most questions.
The variant list, ranked by volume and by cost.
The transition frequencies, which show the real paths.
The waiting times per transition, which locate the delay.
The rework edges, which are where cases go backwards.
Cases per path segment, which sizes each finding.
A table of the ten most costly transitions is more actionable than any diagram, and it survives being emailed.
The presentation trap
A large discovered map is impressive and communicates nothing.
Nobody in an operational meeting can read four hundred nodes.
Show the simplified map for orientation, with the coverage stated, and then show the specific finding as a number.
The map is a working artefact for the analyst, not the deliverable for the audience.
Reporting the model coverage
The single figure that makes a discovered map honest.
State what proportion of cases the displayed model describes.
State what filtering was applied to reach it.
Show the unfiltered variant count alongside.
A map presented without coverage invites the question, and the question then dominates the discussion instead of the finding.
Coverage below about two-thirds means the map is a simplification rather than a description, and it should be labelled as one.
The ten-transition table
More actionable than any diagram and it survives being emailed.
Columns: from activity, to activity, case volume, median wait, total delay.
Sorted by total delay, which is volume times median wait.
That ordering is the work queue, and it is almost never the same as the ordering by median wait alone.
Add the reason category — capacity, availability, dependency, batching — once established.
One table, ten rows. It is the deliverable that produces decisions.
Reading a discovered model sceptically
The picture reflects the algorithm as much as the process, and the settings are rarely reported.
Filtering hides behaviour. A model showing the frequent paths has discarded the exceptions, which is where the cost usually sits.
Simplification invents structure the log does not contain, in order to produce a readable diagram.
Loops may be an artefact of coarse activity naming rather than real rework.
Always report coverage: what share of cases the displayed model actually explains.
Look at the unfiltered variant list once, however unreadable, because that is the process.