Skip to content

Process Mining / Trace Analysis

Trace-analysis tool — instantiates Event-Log-Centered Modeling

Reconstructs the real process from event traces — discovering the actual control flow, its variants, and where reality deviates from the intended path — that the log reveals but no diagram admits.

Every organization has a process diagram, and every organization's process actually runs differently. Process Mining / Trace Analysis closes that gap by reading the event log itself as evidence of how work truly flows. It groups events into traces (all the events of one case, in order), and from thousands of traces it infers the control flow — which activity actually follows which, how often, where the loops and shortcuts and rework are — and then flags where reality conflicts with the intended model. Its defining stance is descriptive, not prescriptive: it does not tell you how the process should run; it shows you, from the log, how it did, including the messy variants nobody documented. The output is a discovered map of causal/sequential dependencies plus an honest register of deviations — the parts of the log that don't fit the story the organization tells about itself.

Example

A company suspects its procurement is slower than it should be. The official purchase-to-pay diagram is clean: requisition → approval → purchase order → goods receipt → invoice → payment. Process mining is pointed at the procurement event log — every requisition, approval, PO, receipt, and payment event with its case id and timestamp. From tens of thousands of traces it discovers the real process, which is nothing like the diagram: about one case in five has the purchase order created before the approval (a "maverick buying" variant), a common loop where invoices bounce between AP and the vendor three or four times, and a shortcut where small purchases skip receipt entirely.

The analysis does two things the diagram never could. It reconstructs the actual control-flow dependencies — the discovered graph of which activity leads to which, weighted by frequency — so the real bottleneck (invoices stuck in the rework loop) is visible instead of assumed. And it surfaces the conflicts: the traces where events happen out of the intended order, which conformance checking marks as deviations against the reference model.[1] The company now argues about the one variant that actually costs it money, using evidence from its own log, rather than about a diagram everyone knew was fiction.

How it works

Trace analysis is distinguished by inferring structure from behavior rather than imposing it:

  • Assemble traces. Events are grouped by case id and ordered, turning a flat log into per-case sequences of activities.
  • Discover the control flow. From the population of traces, infer the graph of which activity follows or leads to which, with frequencies — the process as it actually runs, not as drawn.
  • Check conformance and flag deviations. Compare observed traces against an intended model (if one exists) and register where they conflict — skipped steps, wrong order, unexpected loops.
  • Rank by frequency and impact. Surface the variants and bottlenecks that matter, so attention goes to the deviations that carry cost, not every rare path.

Tuning parameters

  • Case-notion / correlation key — what defines a single "case" whose events form a trace. Choosing it well is decisive; a wrong case notion stitches unrelated events together and discovers a fictional process.
  • Discovery threshold — how frequent a path must be to appear in the model. A high threshold yields a clean, readable map that hides rare-but-costly variants; a low threshold shows everything and becomes a "spaghetti" tangle.
  • Conformance strictness — how tightly observed traces must match the reference model to count as conforming. Strict flags more deviations (including harmless ones); lenient risks normalizing real drift.
  • Time vs. frequency lens — whether analysis optimizes for where time is lost or where paths are common. Time reveals bottlenecks; frequency reveals dominant behavior; they are not the same picture.
  • Noise filtering — how aggressively rare traces are treated as noise versus signal. Filtering clarifies the common process but can discard the exceptional cases where the real problem lives.

When it helps, and when it misleads

Its strength is that it replaces belief with evidence: the actual process, its true bottlenecks, and its undocumented variants are read straight from the log, so improvement targets the real behavior instead of an idealized diagram. It is the analytic payoff of event-centric modeling — the log was worth keeping precisely because it can be mined for how the world really works.

It misleads most through the case notion. Correlate events into traces by the wrong key and the discovered process is confidently wrong — a classic and hard-to-spot failure. Process mining also shows what happened, not why: a discovered "A is followed by B" is a sequential/correlation link, and reading it as proof that A causes B is the cardinal error, since the log records order, not causation. And a clean discovered model can lull an organization into thinking it has understood a process when it has only filtered out the inconvenient variants. The discipline is to validate the case notion against domain reality, treat discovered links as correlational until corroborated, and keep the deviating traces in view rather than smoothing them away.

How it implements the components

Process Mining / Trace Analysis realizes the analytic-derivation side of the archetype — the components that read structure and disagreement out of the raw log:

  • causal_and_correlation_link — it discovers the control-flow graph of which activities follow or lead to which across traces (as correlation, to be distinguished from true causation).
  • uncertainty_and_conflict_record — it registers where observed traces deviate from or conflict with the intended process, surfacing variants and non-conformance.

It analyzes but does not reconstruct or persist: assembling one entity's ordered path across records is Entity-Trajectory Projection, guaranteeing a bit-exact rebuild is Deterministic Replay Protocol, and holding the linked events as a queryable graph is Event Knowledge Graph.

References

[1] Conformance checking — a core process-mining technique that measures how well an event log agrees with a reference process model, quantifying and localizing deviations. It presupposes both a log and a model, and reports where the two disagree rather than which is correct. ↩