Process Discovery: Deriving a Process Model from Event Data

Deriving a model from the log

The Process Mining Manifesto identifies discovery as a fundamental form of process mining. Whereas conformance methods compare an existing model with events, discovery first generates a model from the log itself.[1]

The structures produced are shaped by event selection, case construction, and the chosen method. The model can summarize observed paths while also allowing behavior not yet present in the selected data. A frequently observed path may be operationally undesirable, while a rare path may be a necessary exception.

Example: From observed sequences to a model

An illustrative, simplified log contains three sequences of completed activities. Observation begins after manufacturing in each case:

• Test → Quality decision → Release
• Test → Rework → Test → Quality decision → Release
• Test → Quality decision → Place on hold

The first modeling question concerns the shared sequence: in all three sequences, a test precedes the quality decision. The observations then show two different endings. A model could represent these as alternative outcomes. The sequences alone do not, however, specify which domain condition governs the choice.

The model a discovery method actually generates depends on factors including the method, parameters, and data preparation. The example does not specify a particular algorithm and therefore does not guarantee a particular output model. It shows which structures need explaining and where a modeling assumption goes beyond the observations.

A published foundational example makes this aggregation step measurable: event log L1 contains 16 cases and three observed trace variants. Ten cases follow ⟨a, b, c, e⟩, five follow ⟨a, c, b, e⟩, and one follows ⟨a, d, e⟩. For a Directly-Follows Graph, these observations are aggregated into frequencies including the activities that immediately follow a.^[6]

Grouping process variants brings together identical complete activity sequences. Discovery instead derives a model representing the structure of multiple observed sequences.

Observing a repetition, allowing a loop

The second sequence returns to testing after rework. A model can include this path observed once. A loop may allow further rounds of rework. This additional possibility comes from the method's generalization, not from further observed rounds.

The second sequence also lacks a separate quality decision before rework. The log leaves open whether an event is missing, the decision was included under “Test,” or the actual process differed. The three sequences alone cannot resolve this. Event meaning is therefore part of assessing the data foundation.

Varying orders raise a related question: if a document review is recorded before a material confirmation on one occasion and after it on another, a method may model possible parallelism. Inaccurate timestamps or different event meanings would be other explanations.

Different methods discover different models

There is no single universally correct algorithm for process discovery. Methods differ in the relationships they examine, the model notation they produce, their treatment of rare behavior, and the formal properties they guarantee.

The Alpha algorithm is one of the foundational early methods. It derives relationships such as causality, parallelism, and choice from directly observed ordering and constructs a workflow net from them. The original work by van der Aalst, Weijters, and Măruşter illustrates the basic problem of automatic process discovery, while also identifying limitations involving short loops and certain complex structures.^[2]

Heuristic approaches also consider frequencies. Rare relationships may be weighted less heavily or filtered out. This helps with noisy real-world logs, but risks losing rare yet operationally important exception paths.

Inductive mining methods progressively decompose observed behavior into structures such as sequence, choice, parallelism, and loop. Leemans, Fahland, and van der Aalst describe a constructive approach that generates block-structured models and ensures formal soundness and fitness to the observed log for the discovered model.^[3]

Choosing a method is therefore more than a software setting. It influences which process structures become visible, how complex the result is, and which additional behavior the model allows.

The result can take different model forms

A discovery result need not be a complete BPMN diagram. Depending on the method and purpose, different representations are possible:

• Directly-follows graph: shows which activity immediately followed another and how often that relationship was observed.
• Process tree: represents processes hierarchically using operators for sequence, choice, parallelism, and loop.
• Petri net or workflow net: formally describes possible execution behavior and can express synchronization or concurrency.
• BPMN model: translates discovered structures into a process notation familiar to many domain users.

A simple representation is easier to read, but may hide important conditions. A formally rich model may support more precise analysis while making human interpretation harder. The model form must therefore fit the question: is the aim an initial overview, an explanation of execution variants, or a later formal behavioral check?

The starting point is a domain-understandable event log

A discovery method does not directly process real work. It processes data about that work. Process events with clear domain meaning therefore form the basis of the event log and thus of the discovery result.

For a classic case-based analysis, it must be possible to associate events with at least an activity and a process instance and place them in order. Timestamps, executing roles, results, systems, and other attributes extend the analysis options. A meaningful process model can be discovered only if identically named events have the same domain meaning and the chosen case reference represents a coherent process.

An example illustrates the problem: grouping all events from a calendar day into one case mixes multiple batches. Treating each individual task as its own case fragments the broader batch history. In both situations, an algorithm may formally generate a model. The model does not, however, answer the intended process question.

The start and completion of an activity must also be interpreted consistently. An event labeled “Test” may denote the start of a check, the recorded result, or the final release. If these lifecycle states are not distinguished, apparent sequences emerge that meant something different in actual operations.

The XES and OCEL models can represent event data in a structured way. They do not automatically determine which domain granularity, object relationship, or activity semantics is correct for a specific discovery question.

Filters change which reality becomes visible

Real event logs often contain rare variants, incomplete cases, technical repetitions, or activities that occur at many points regardless of the actual process state. Without preparation, these can produce confusing models.

Filters can limit cases to a period, remove incomplete executions, group activities, or hide rare relationships. Each measure changes the data foundation, however. A clearer model may also contain less complete information.

Tax, Sidorova, and van der Aalst show that so-called chaotic activities can substantially impair the precision of discovered models and that simply removing rare activities does not reliably solve this problem.^[5] Frequency and domain relevance are not the same.

In a regulated process, deviation handling may occur rarely yet be essential to assessing the control system. An operationally appropriate filtering strategy should therefore document which data was excluded, grouped, or renamed and which question the resulting model is intended to answer.

Good models balance several quality goals

A discovered model cannot be assessed solely on whether it reproduces the event log. Four quality dimensions often pull in different directions:

• Fitness: How much of the observed behavior can the model reproduce?
• Precision: How strongly does the model restrict behavior not observed in the log?
• Generalization: How well does the model also capture possible behavior of the same process that has not yet appeared in the selected log?
• Simplicity: How understandable and uncomplicated does the representation remain?

A model that represents every individual trace as a special case may achieve high fitness yet remain unreadable. A model allowing any arbitrary sequence reproduces all observed cases but is hardly precise. An extremely simple model may lose the central process logic.

Buijs and colleagues describe these four dimensions as competing criteria in process discovery.^[4] The appropriate balance depends on the analysis purpose. For an operational discussion, understandability may matter more than maximum detail. For a formal check, other properties may dominate.

For fitness and precision, the meaning of a value also depends on the calculation method. Quality metrics therefore do not replace substantive assessment. A high numerical value does not establish whether activities were named correctly, relevant exceptions were retained, or the cases were selected representatively.

A single case identifier can distort the process

Classic discovery methods often examine events along a case ID. In real operations, however, multiple objects interact: a batch uses different materials, passes through tasks and tests, uses equipment, and may split into intermediate products or merge with other objects.

Making one of these perspectives the sole case dimension can lose relationships or artificially duplicate events. A batch analysis may show its main path while concealing that equipment was used for multiple batches at the same time. A material perspective shows ancestry, but not automatically the complete task sequence.

Object-centric process mining expands this perspective by keeping events connected to multiple objects. Here too, a discovery method must decide which relationships and model structures to derive from the object-centric data. The problem does not disappear; it is described in a way that better fits the domain.

The discovered model initially has an analytical status

The discovery result is initially treated as a model of the selected observed behavior. A domain review can examine which alternatives, repetitions, and simplifications it contains. Existing process knowledge helps interpret these decisions.

To check conformity with a requirement afterward, conformance checking compares recorded behavior with a model defined for that purpose. Discovery itself does not approve the observed process.

Investigate causes and compliance separately

A discovered process model describes process structures; why a waiting time or rework occurs, for example, must be investigated using additional information.

Nor does it demonstrate adherence to binding requirements: the processes must be assessed separately against the applicable requirements for that purpose.

The unresolved quality decision remains a question for the data

The model may show a loop even though only one round of rework was observed. It cannot, by itself, explain why no quality decision was recorded before that rework. Anyone using the result must distinguish the two: the method's generalization and the unresolved question about the event data. The chosen data perspective and method settings therefore belong with the model handed over.