Inductive Miner

What is the Inductive Miner?

The Inductive Miner is a family of process discovery algorithms and, for most teams today, the default choice. It takes an event log and produces a process model that is guaranteed to be sound: every case that starts can always run through to a proper finish, with no dead ends or stuck steps.

It gets there by splitting the log. Rather than looking at activities pair by pair, it looks for one clean cut that divides the whole process into blocks, then repeats the same trick inside each block until nothing is left to split. The result is a process tree, which can be translated directly into a Petri net.

The algorithm was introduced around 2013 by Sander Leemans, Dirk Fahland, and Wil van der Aalst. It was the first widely used approach that could promise a well-formed model rather than hoping for one.

How the recursion works

The algorithm looks for a cut: a way to divide the activities into groups that fit one of four control-flow patterns. Once it finds a cut, it splits the log to match, then runs the same procedure on each smaller piece. The recursion stops when a piece is just a single activity.

When no clean cut can be found, the miner falls back on a safe default that still produces a valid model rather than giving up. This is why it always returns something sound, even on awkward data.

The four ways it can split a process

Sequence. One block always happens before another. In cases like A, B, C and A, D, C, the miner can pull A to the front and C to the back, then work on the middle.

Choice. Only one of several branches runs per case. If B and D never appear together in the same case, that points to an either-or choice between them.

Parallel. Two branches both run, but their steps can interleave in any order. If B and C show up in both orders across the log, that supports true parallelism.

Loop. A block can repeat. A "do" part runs, and a "redo" part can send the case back around before it finally exits.

Soundness and what it does not promise

Because every block has one clear way in and one clear way out, the model avoids the deadlocks and tangles that looser algorithms can produce. That is what soundness means here.

Soundness is a promise about structure, not about truth. A model can be perfectly sound and still be wrong, if the log it was built from had bad timestamps or badly linked cases. A sound model on bad data will faithfully describe the wrong process.

So soundness is a floor, not a finish line. You still have to check fitness and precision, the numbers that conformance checking gives you, and whether the model makes sense to the people who run the process.

The infrequent variant

Real logs are full of one-off behaviour, and the plain Inductive Miner will try to fit all of it, which can produce an over-complicated model. The infrequent variant, often written IMf, filters out rare directly-follows relations while it works.

A noise threshold controls how rare a path has to be before it is set aside. Filter harder and you get a simpler model that covers less of the data. As always, report the threshold and look at what you excluded, because rare and wrong are not the same thing.

How it compares to older miners

The Alpha Miner derives a model from a footprint of directly-follows relations and struggles with noise and short loops, without any soundness guarantee. The Inductive Miner handles those structures explicitly and always returns a well-formed model.

The Heuristics Miner scores dependencies by frequency and produces a heuristics net, which is flexible but structurally weaker. The Inductive Miner trades some of that local flexibility for a stronger, guaranteed shape. Which one wins depends on your log and your question, so compare them on the same data.

What to watch out for with the Inductive Miner

Clean the log first. Consistent activity labels and correct case linking matter more than the algorithm. Discovery does not repair data quality for you.

Try several thresholds. Run the infrequent variant at a few noise levels and lay the models side by side with the real variants before you settle on one.

Show your working. Present the model together with the time period, the filters, and the variant you used. The tree is a summary of one slice of data under one set of assumptions.