Process mining event log quality
An event log is ready for process mining only when each recorded event can be tied to the right case, activity, time, and source. A visually convincing process map cannot repair mixed case identifiers, overwritten timestamps, missing lifecycle states, or selective exports.
That direct answer sets the boundary for this study. The question is not whether process mining software can open the file. It is whether the underlying observations are accurate, complete, applicable to the operational decision, and reproducible from governed records.
The Process Mining Manifesto describes event data as the starting point for discovery, conformance, and enhancement. The IEEE XES standard supplies a common structure for events and traces, but a valid structure does not prove that the recorded history matches what happened.
What the source standards require
The minimum analytical unit is an event attached to a case. A case might be one request, order, complaint, approval, or service job, while an event records a defined change such as receipt, assignment, approval, completion, or reopening.
Case identity must remain stable across systems. If an intake form uses one identifier and the work queue creates another, keep the relationship in a crosswalk rather than merging records by customer name or approximate time. The W3C provenance model supports explicit relationships among entities, activities, and agents, which is useful when an event log combines several sources.
Activity labels also need operational definitions. "Complete" might mean work performed, evidence attached, owner approval, or customer notification. A log that assigns one label to those different states will compress several handoffs into an apparent single event.
The OMG BPMN specification distinguishes activities, events, gateways, and flows in a process model. An operational log does not need to reproduce BPMN, but the distinction helps reviewers ask whether a status field represents work, a decision, or a message.
Test the log before interpreting the model
Begin with coverage. Count eligible cases in each source system, exported cases, cases with at least one event, and cases that reach the stated terminal condition. Reconcile those totals before calculating path frequency or duration.
Next, test identity. Sample cases from the log back to source records and sample source records forward into the log. The GAO data reliability guide treats accuracy, completeness, and applicability as purpose-specific questions and recommends tracing records as one way to assess reliability.
Then test event order. Record the original timestamp, time zone, precision, extraction time, and any transformation. Do not silently sort equal timestamps into the sequence that best matches the expected workflow.
Lifecycle states need their own check. A task can be scheduled, started, suspended, resumed, completed, accepted, and reopened. If the source retains only the latest state, elapsed-time analysis will confuse active work with waiting and may erase rework.
The NIST log management guide explains that logs come from different sources and need consistent management across their lifecycle. Its security context is broader than routine operations, but the recordkeeping point transfers: collection, storage, access, analysis, and disposal rules affect what evidence remains available.
Quantify defects by consequence
Report defects in units a reviewer can lift into a decision note. Examples include the share of eligible cases missing from the extract, duplicate event identifiers, events without a case, impossible timestamp order, unknown activity labels, and terminal cases without completion evidence.
Do not combine every defect into one quality score unless the weighting rule is documented and justified. A missing optional note and a case assigned to the wrong customer do not carry the same analytical consequence.
The ISO/IEC 25012 data quality model separates data quality characteristics rather than reducing quality to one property. The Federal Data Strategy framework likewise connects data value with governance, documentation, and responsible use.
Classify each defect by the conclusions it can distort. Missing early events may bias cycle-time estimates downward. Duplicate completion events may inflate throughput.
Unlinked reopened work may make first-pass completion appear stronger than the record supports.
Run a bounded conformance analysis
Freeze the event dictionary, inclusion rule, extraction query, and observation window. Retain the raw extract separately from the analysis table, and record every transformation as code or a versioned instruction.
Build the simplest expected path that can answer the decision question. Conformance checking compares recorded behavior with a model, while discovery derives a model from the log. The peer-reviewed overview Process Mining textbook explains why those are different analytical tasks.
Treat deviations as records to inspect, not automatic errors. A skipped approval may be a control failure, an authorized exception, a logging defect, or a changed policy. The source evidence and effective procedure version decide which label applies.
Privacy also constrains the extract. Use the least identifying case key that preserves valid linkage, limit event attributes to the question, and restrict access to row-level records. The NIST Privacy Framework provides a risk-based structure for considering how data processing can affect people.
Interpretation boundaries
A discovered path shows recorded sequence, not motive or causation. Frequent rework may point to unclear intake, difficult cases, missing authority, or a logging convention. The model alone cannot choose among those explanations.
The analyst should disclose excluded systems, unmatched identifiers, timestamp precision, overwritten status history, manual corrections, and process changes during the window. The NIST Big Data interoperability taxonomy emphasizes common concepts across data roles and system components, which helps make those boundaries explicit.
For the wider evidence library, use the Research index. The adjacent study on intermittent demand covers a different question: predicting irregular request volume rather than reconstructing process paths. The operations VA guide explains the service context without changing the research limits here.
Review packet
The review packet should contain the decision question, case definition, event dictionary, system inventory, crosswalk rule, extraction query, raw-file checksum, transformation history, coverage table, defect table, sample trace results, model version, deviations, and limitations. Keep the first extract so later corrections do not rewrite the evidence available to the original decision.
An accountable process owner decides whether the log supports action. A coordinator may reconcile identifiers, maintain definitions, run documented checks, and assemble exceptions, but should not reinterpret policy or remove inconvenient cases to improve the model.
Sources
- Process Mining Manifesto
- IEEE Standard 1849-2016 for XES
- W3C PROV-O
- OMG BPMN 2.0
- GAO Assessing Data Reliability
- NIST SP 800-92
- ISO/IEC 25012
- Federal Data Strategy framework
- Process Mining textbook
- NIST Big Data taxonomy
- NIST Privacy Framework
These sources support standards, definitions, and study design. They do not prove that a particular log is complete or that a discovered path caused an operational outcome.