What is conformance checking?

Conformance checking compares a documented process model (the “should” path) with actual execution traces from event logs (the “is” path) to detect deviations, missing steps, bypasses, and unexpected variants.

Is process mining enough without a process model?

Process mining can reveal what happened, but without a “should” model you can’t reliably distinguish improvement opportunities from intended design. Conformance connects operations to governance.

Do we need perfect logs?

No. Start with a minimal event set (case id, activity name, timestamp). Then incrementally improve log coverage where it drives decisions or controls evidence.

Process mining conformance checking playbook (should vs is)

19 min read

Advanced

Definition

Conformance checking is the measurement loop between process design and process reality: define the “should” path from BPMN, extract the “is” path from event logs, quantify deviations, and feed fixes back into governance and execution.

Key takeaways

Start with one journey and one log source; scale after you prove value.
Conformance works when the “should” model is operational (owned, versioned, scorecarded).
Measure drift as a KPI: bypasses, missing approvals, rework loops, and late evidence.
Close the loop: every conformance finding must become an improvement ticket or a model update.

When conformance checking is the right tool (and when it isn’t)

Use conformance checking when you have one or more of these problems:

documented SOP/BPMN exists but teams say “reality is different”
controls evidence is missing or late
variants multiply and you can’t tell what is “normal”
transformation programs can’t measure improvement beyond anecdotes

Conformance is less useful when:

no event logs exist at all (start with walkthrough capture)
the process is purely creative and has no stable path

Minimal data you need (start small)

Start with the minimum viable event log:

case_id: the unit of work (claim id, ticket id, onboarding id)
activity: step name (aligned to BPMN labels)
timestamp: when the event occurred

Then incrementally add:

actor (user/system/team)
outcome (approved/rejected/exception code)
system source

Don’t boil the ocean

Pick the event fields that change a decision. If a field doesn’t affect actions, don’t collect it yet.

Step-by-step implementation: should → is → drift KPI → remediation

Step 1: Define the “should” model

select a BPMN model that is owned and approved
mark decision points (approvals, gateways, handoffs)
define evidence expectations (where required)

Step 2: Map logs to steps

align activity labels to BPMN step ids/names
define how exceptions appear (codes, variants)

Step 3: Compute drift metrics

missing steps (% of cases with missing approval)
bypasses (cases skipping a control step)
rework loops (repeat counts, cycle time inflation)
evidence timeliness (time-to-approve/time-to-record)

Step 4: Create remediation workflows

create a ticket with owner and SLA
decide if fix is: model update, training, system change, or control redesign

Step 5: Publish results

executive dashboard for outcomes
operational dashboard for owners and teams

Common conformance findings (and what they usually mean)

Bypass of approval → unclear ownership or broken tooling
Late evidence → process bottleneck or missing automation
High variant count → process not standardized or exceptions are the real process
Rework loops → missing upstream validation or handoff ambiguity

The best fix is often upstream

Conformance often surfaces downstream pain, but the fix is upstream: clarify inputs, add validation, or redesign the handoff so exceptions stop being the norm.

Connect conformance to governance (or it becomes analytics theatre)

Conformance is not a dashboard project.

Make it part of governance:

weekly or bi-weekly drift review (time-boxed)
publish model updates through the standard workflow
update training/SOP and communicate changes

Process documentation data quality framework

Regulated operations angle: controls evidence and audit trails

In regulated operations, conformance checking is especially powerful because:

controls are defined as decision points
evidence must be provable (not anecdotal)
exceptions create risk and require oversight

Conformance turns these into measurable outcomes and repeatable remediation.

Avoid these

Common mistakes to avoid

Learn from others so you don't repeat the same pitfalls.

Starting with 20 processes at once

You won’t finish mapping logs and ownership for any of them.

Start with one journey and scale after you close the loop.

No remediation workflow

Findings don’t change behavior.

Turn findings into tickets or model updates with owners and SLAs.

Assuming the model is always right

Sometimes the “is” path is correct and the model is outdated.

Use conformance to decide whether to change the process or change the model.

Expert insights

What the experts say

"Conformance checking is the missing link between governance and reality. Without it, repositories become opinions."

Process Mining Lead

Take action

Your action checklist

Apply what you've learned with this practical checklist.

Select one end-to-end journey with clear pain (risk, cost, audit findings)
Define the approved BPMN “should” model and evidence points
Build the minimal event log mapping (case_id, activity, timestamp)
Publish 3–5 drift KPIs and assign owners
Create a remediation workflow (tickets or model updates)
Scale to the next journey only after the loop is closed

Conformance checking playbook: connect “should” (BPMN) to “is” (event logs)