Glossary

Activity — a named step in the process, as it appears in the log. A modelling choice disguised as a data field, since the naming granularity determines how many variants you find.

Case — the unit of work a trace belongs to: an order, an invoice, a ticket. Choosing the identifier is the most consequential decision in a project.

Case identifier — the field linking events into a trace. A different choice produces a different process.

Conformance checking — comparing the log against a model or a rule set and reporting deviations. More useful as rules than as a fitness percentage.

Cycle time — elapsed time from the case start to the case end, both defined by the chosen boundary. Not comparable across analyses with different boundaries.

Directly-follows graph — the raw count of which activity followed which. Fits the data perfectly and is unreadable for any real process.

Event log — one row per event, with at minimum a case identifier, an activity and a timestamp.

Fitness — whether a model permits the behaviour observed. Trades against precision and simplicity; a model permitting everything has perfect fitness and no value.

Happy path — the intended sequence. Frequently describes a minority of cases, which is itself the first finding in most projects.

Process mining — reconstructing how a process ran from event records the systems already produced.

Rework — an activity performed more than once in a case, or a transition backwards. Always caused upstream of where it appears.

Task mining — capture of desktop activity to characterise work the systems do not record. Employee monitoring, with the obligations that attach.

Trace — the ordered sequence of events for one case.

Variant — a distinct trace sequence. The count is a function of activity granularity, not of process discipline, which is why it is not a finding.

Terms used loosely elsewhere

"Digital twin of an organisation" describes an aspiration and obscures what is actually being modelled. These notes say what the model contains.

"Object-centric" describes logs with several interacting case types. Useful and not necessary for a first project, where one case type is enough.

"Hyperautomation" bundles mining, automation and orchestration into one purchase. These notes treat them as separate decisions with separate justifications.

"Real-time process mining" usually describes an hourly refresh, which is faster than the decisions in a process whose cases take days.

"X percent conformance" is a number nobody can act on. These notes report specific deviations with case counts and case numbers.

How to read these notes

A short orientation for anyone arriving at the collection rather than at one page.

Start with the foundations if the subject is new, particularly the note on which questions each technique answers.

Start with the data section if you have a tool and no usable log, which is the most common situation.

Start with the task mining section if desktop capture is being proposed, and read it before anything about technology.

Start with common failures if a deployment has stalled.

The reference section states the boundaries — what the log cannot show, where the rules come from, and what a working arrangement looks like.

None of it is legal advice, and the notes say so where it matters.