A dashboard tells you picking time was up 12% this week. That's a fact, but it isn't an answer. Up 12% compared to what — a designed target, a contractual SLA, or just a slightly quieter shift last week? Was it a problem, or was it a Tuesday?
Most process mining and operational BI tooling stops exactly there. It surfaces a deviation from a historical average and leaves the reader to decide whether the deviation mattered. That's the "where's the delay" question, and it's a genuinely useful one. It is also a different question from "did this process actually do what it was supposed to do" — and the gap between the two is wider than it looks.
Conformance checking is the discipline of asking that second question properly. It compares what actually happened, event by event, against a model of what the process was supposed to do — rather than against the process's own historical average. It sounds like a small reframe. In practice, it changes what gets flagged, what gets ignored, and how much of your team's attention gets spent on things that were never going to cause a problem.
What is conformance checking in process mining?
Process mining has three standard uses. Discovery builds a model of the process from event data. Enhancement enriches that model with timing, cost, or resource detail. Conformance checking compares real executions against the model and reports where reality and the model diverge — which steps were skipped, which happened out of order, which missed a deadline the model says they were bound by.
The critical detail is where the model comes from. Conformance checking against a hand-drawn flowchart of how someone believes the warehouse works tends to produce noise, because real operations carry legitimate variation that no one documented. Conformance checking against a model discovered from the operation's own data — including its legitimate variation — produces something much narrower: a list of executions that broke a rule the process itself demonstrably follows the rest of the time.
That is the difference between "unusual" and "wrong". An efficiency view can only ever tell you the first.
What does an efficiency dashboard actually measure?
Efficiency-oriented tooling is built around one comparison: this instance versus the historical norm. A step usually takes eight minutes; this time it took eleven; the tool flags it. That's descriptive statistics, and it's a reasonable first read of a busy operation. It tells you where things are running slower than usual.
What it doesn't tell you is whether eleven minutes broke anything.
Every instance gets the same statistical treatment — the shift-ending non-event and the one delay in the whole week that cost a client their delivery window are scored by the same yardstick. The model has no concept of a rule being violated. It only has a concept of a number sitting further from its average than usual. Severity, in that world, is a function of standard deviations, not of consequences.
Same delay, two different verdicts
Two shipments both take longer than average to clear a hub. An efficiency dashboard flags both as anomalies with roughly equal severity: both are slower than usual, full stop.
A conformance check looks at the sequence behind the duration, and reaches two different verdicts.
| Shipment A | Shipment B | |
|---|---|---|
| Dock arrival scan | 14:12 | 14:26 |
| Same-day dispatch cutoff | 15:30 | 17:00 |
| Trailer load confirmed | 15:51 | 17:40 |
| Time in hub | 1h 39m | 3h 14m |
| Efficiency view | Slower than average — flagged | Slower than average — flagged |
| Conformance view | Cutoff rule breached. Client SLA at risk. | Cleared every downstream window. No action. |
Shipment B sat in the hub almost twice as long and is, by every measure a duration-based dashboard has, the worse of the two. It is also fine. Its lane runs a later cutoff, its onward leg had slack, and every downstream step landed inside its allowed window. Shipment A moved faster and still broke the only rule that determined whether the customer got their parcel on the day they were promised it.
The only way to tell those two apart is to stop at the single "how long did it take" number and look at the sequence behind it: when the shipment was scanned in, when it was due to leave, when it actually left, and what happened to it downstream. One sequence shows a cutoff missed before the delay was large enough to register on any dashboard. The other shows a slow shipment that was never out of line with what was supposed to happen.
"We don't have the data for that" — usually you do
The most common objection to this is instrumentation: surely checking conformance at that level of detail means capturing more data than we already do.
It generally doesn't. A hub already captures dock arrival scans, cutoff timestamps, trailer load confirmations, and downstream delivery scans for every shipment that passes through it. That data exists because someone needs to track parcels, and it is far more granular than an average-based dashboard puts to use. Most of it is collected, written down, and then quietly discarded the moment a shipment is rendered as a single row with a single duration.
An efficiency view distils all of that into one number. A conformance check uses the same records, already being collected, to reconstruct the full sequence and test it against what should have happened at each stage. Nothing new gets installed. Something that was already being thrown away gets used.
Efficiency view vs conformance view
| Efficiency view ("where's the delay?") | Conformance view ("did it actually break?") | What that buys you |
|---|---|---|
| Flags both shipments identically — both slower than the historical average. | Separates a genuine rule violation from ordinary variance. | Attention goes to the one shipment that needs a decision. |
| No link to a specific downstream consequence, just a deviation. | Ties the violation to a traceable outcome, such as a missed SLA. | A missed SLA gets caught before the client catches it. |
| Every instance competes equally for attention. | Only instances that actually matter surface as action items. | Teams stop chasing anomalies that were never going to cause a problem. |
| Treats a one-off delay and a network-wide pattern the same way. | Flags a shared root cause once, even when it spans many sites. | One fix addresses every affected site, instead of one ticket at a time. |
| Alert volume grows with network size — more sites, more noise. | Alert volume tracks genuine violations, not raw instance count. | Growing the network doesn't mean drowning in false alarms. |
Why does the gap widen as operations scale?
This distinction gets more important, not less, as a network grows and automates.
A handful of sites can absorb a noisy dashboard. Someone eyeballs the flagged list every morning and uses judgment to sort real problems from statistical noise, and that judgment is usually good — it just doesn't scale. Run dozens of sites, each generating its own stream of "unusual" instances, and a noisy efficiency view becomes genuine alert fatigue: everything is flagged, nothing is prioritised, and the one violation that mattered is buried in a list of ninety that didn't.
The failure mode isn't that the dashboard is wrong. It's that the dashboard is equally right about everything, and the cost of that falls on whoever has to read it at 6am.
Why conformance checking needs an object-centric model
Precise, per-relationship comparison is only possible once a process is modelled as a graph of objects rather than flattened into a single case — the distinction covered in Objects, Not Case IDs: A Plain-English Guide to OCPM.
The reason is structural. The rule Shipment A broke wasn't a property of the shipment on its own. It was a relationship between the shipment, the lane it was assigned to, the cutoff that lane runs, and the trailer that was supposed to carry it. Flatten all of that into one case ID and the rule has nowhere to live: the lane becomes a label, the cutoff becomes a static field, and there is nothing left to check conformance against.
Conformance checking is what an object-centric model is ultimately for. Without the relationships between orders, resources, and locations preserved, the only thing left to compare against is an average — which is exactly where we came in. It is also the layer where process intelligence stops describing the past and starts being able to say something about what happens next: a rule that has been breached at 15:30 has consequences at 19:00 that nothing in a duration average can anticipate.
Five questions to put to your own dashboard this week
A quick self-check. For the last five items your operational dashboard flagged:
- What was each one compared against — a designed target, a contractual commitment, or last month's average?
- Which of them had a named downstream consequence, and which were just further from the mean than usual?
- How many were the same underlying cause reported as separate incidents at separate sites?
- How many were closed with no action taken? That number is your false positive rate, and nobody is measuring it.
- What broke that week without being flagged at all, because it never looked slow enough to stand out?
If question five has an answer, the gap in this article is already costing you something.
Frequently asked questions
What is conformance checking in process mining?
Conformance checking compares actual process executions against a model of how the process is supposed to run, and reports where the two diverge — skipped steps, out-of-order activities, missed deadlines. It differs from process discovery, which builds the model, and from performance analysis, which measures durations against historical averages.
How is conformance checking different from anomaly detection on a dashboard?
Anomaly detection asks whether a number is unusual relative to its own history. Conformance checking asks whether a specific rule was violated. A slow instance that broke no rule is not a conformance violation; a fast instance that missed a cutoff is. The two methods routinely disagree about which instances matter.
Does conformance checking require new sensors or instrumentation?
Usually not. Most warehouse and logistics operations already capture the timestamps required — arrival scans, cutoff times, load confirmations, delivery scans — for tracking purposes. Conformance checking reconstructs the sequence from records that already exist but are collapsed into a single duration by average-based reporting.
Where do the rules being checked come from?
They can be authored by hand, but hand-authored models tend to generate noise, because real operations carry legitimate variation nobody documented. Rules discovered from the operation's own event data reflect how the process actually runs, including that variation, so deviations flagged against them are narrower and more credible.
Can conformance checking be done with traditional case-ID process mining?
Partially. A flattened, single-case model can check rules that concern one entity in isolation. It cannot check rules that are relationships between entities — a shipment against its lane's cutoff, an order against its dock slot — because those relationships aren't preserved in the model. See Objects, Not Case IDs for why.
Do efficiency dashboards still have a use?
Yes. They're a reasonable first read of a busy operation and they answer their question well. They just answer a different question from the one that determines whether something needs fixing.
None of this makes efficiency dashboards useless. They answer their question honestly. They simply answer a different question from the one that decides whether something needs fixing — and that gap is what pAud's conformance layer was built to close.
We're taking on a small number of early operational partners right now. If separating real violations from ordinary variance is something you're wrestling with, we'd like to talk.