Process Mining Live — Discovering a Workflow from an Event Log

Event Log Stream

Discovery threshold (dependency) 0.50

Noise level (deviant traces) 15%

Replay speed 1.5 traces/s

Live Metrics

Traces processed

Model fitness

—

Edges discovered

0 / 0

Deviant traces

Legend

Discovered edge (dependency ≥ threshold) Filtered edge (below threshold) Conformant trace token Deviant trace token

How it works

Each token is one case (order, ticket, claim…) replaying its recorded activity sequence from the event log. Every time a case moves from activity a to activity b, the directly-follows count freq[a→b] is incremented. The discovered process model is built with the Heuristics Miner dependency measure:

D(a,b) = ( freq[a→b] − freq[b→a] ) / ( freq[a→b] + freq[b→a] + 1 )

edge a→b is kept in the model  ⇔  freq[a→b] ≥ 3  AND  D(a,b) ≥ threshold

Raising the threshold slider prunes rare or contradictory transitions out of the model — exactly what an analyst does when moving from a noisy "spaghetti" process map to a clean, governed one. Noise level controls how many cases follow a bypass path (e.g. payment issued without validation) instead of the standard workflow — a live picture of the "automation sprawl" problem, where uncoordinated shortcuts fragment a process.

Model fitness is the running percentage of completed cases whose every step-to-step transition is currently part of the discovered model (conformance checking). A case with even one transition outside the model — like Auto-Approve → Reject, or Submit → Payment skipping Validate — counts as non-conformant and turns its token red.

Real-world relevance: this is the same discover-then-conform loop production process-mining tools (Celonis, Disco, ProM) run continuously against ERP and CRM event logs to find where an automated business process actually deviates from its designed workflow.

Directly-follows graph — discovered live from the event log

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.