Core concepts

Process mining has its own vocabulary. Most of it maps onto ideas you already know from working with logs or databases; this page connects the two.

Events, cases, and activities

An event is a single recorded occurrence: something happened, at a point in time, as part of some larger unit of work. In a support-ticket system, “ticket #4021 was escalated at 14:32” is an event.

A case (sometimes called an instance) is that larger unit of work — the order, the ticket, the patient visit. Every event belongs to exactly one case in a conventional event log.

An activity is the kind of thing that happened, stripped of which case it belongs to — “Escalate ticket” rather than “ticket #4021 was escalated.” Two events with the same activity label but different cases are two occurrences of the same step.

Traces and variants

A trace is the ordered sequence of activities for one case — the path that one order, or one ticket, actually took through the process. If two cases produce the same sequence of activities, they share a variant. Real processes are almost never one straight line: a discovered model typically has a handful of dominant variants that cover most cases, and a long tail of rare ones.

Process models

A process model describes which activities can happen, in what order. Promenade represents discovered models primarily as directly-follows graphs and Petri nets:

• A directly-follows graph (DFG) connects two activities if one was observed immediately after the other anywhere in the log. It’s fast to compute and easy to read, but doesn’t capture concurrency well.
• A Petri net (often produced via the Inductive Miner) explicitly represents choice, sequence, parallelism, and loops using places and transitions, and can be checked for soundness.

Discovery vs. conformance vs. performance

These are the three questions process mining usually answers, and they correspond to three views in Promenade:

• Discovery: what process does this event log actually show? (No reference model needed.)
• Conformance: how well does this event log match a given reference model? Where and how often does it deviate?
• Performance: where is time spent? Which transitions between activities are slow, and for which cases?

Classifiers

An event log can have several notions of “activity” depending on which log attribute you group by — often called a classifier. The default is usually the activity name, but you can classify by a combination of attributes (for example, activity name plus a lifecycle transition like start/complete) to get a more detailed model. You’ll see a classifier selector in the inspector panel whenever you’re looking at a discovered artifact.

Where this vocabulary breaks down

All of the above assumes one case per record. Many real processes don’t fit that: an order has multiple items, each of which might ship separately and be returned independently. Forcing that into a single case notion means either duplicating events across cases or picking one entity (the order? the item? the delivery?) and losing the others. Object-centric process mining, covered next, is the response to that problem — see Object-centric data.