Kept AI, Inc.Visit Website →
← Back to blog

Process Discovery Methods: 7 Steps, Model Tests, and What Logs Miss

October 14, 2026
Process Discovery Methods: 7 Steps, Model Tests, and What Logs Miss

Process discovery methods automatically build a process model from event logs so you can see how work actually flows, using formats like XES and algorithms such as Inductive Miner. Discovery is the first stage of process mining, followed by conformance checking and enhancement. A discovery effort succeeds when the resulting model is accurate enough to diagnose problems and guide real improvement, not when it merely looks complete.

TL;DR:

  • A usable event log needs a case ID, activity name, and timestamp for each event; without case IDs, correlate events before modeling.
  • Analysts can spend up to 80% of project time extracting, correlating, and abstracting data, so clean logs matter more than algorithm sophistication.
  • Use Heuristic Miner for noisy, infrequent behavior, Inductive Miner when soundness guarantees matter, and compare two algorithm families on the same prepared log.
  • Test models for fitness, precision, generalization, and simplicity, then replay logs, hold out traces, and review diagrams with the people doing the work.
  • Mine logs first to flag ambiguous or high variance branches, then interview employees about exceptions and decisions that timestamps cannot explain.
Kept
Capture the Context Logs Miss
Capture the process context event logs miss by letting employees describe their workflows in their own words with Kept's conversational AI.
Explore Kept

Table of Contents

How Process Discovery Works: A Step-by-Step Workflow

Discovery follows a predictable sequence, even though the details shift from one organization to the next.

  1. Locate and extract event data from ERPs, ticketing systems, or message logs, pulling at minimum a case id, an activity name, and a timestamp for every event.
  2. Add helpful attributes such as resource, cost, or department when they are available, since these enrich later performance and decision analysis.
  3. Correlate events into cases when no case id exists, using heuristic rules or probabilistic methods.
  4. Abstract raw events into business-level activities, collapsing dozens of system clicks into the step a manager would actually recognize.
  5. Sample and filter the log to manage scale and strip out noise that would distort the model.
  6. Run a discovery algorithm, inspect the output, and tune parameters before accepting it.
  7. Validate with conformance checking, then move into performance analysis or decision mining.

A few things determine whether that sequence produces something useful:

  • Missing case ids force you into correlation before any model will make sense.
  • Overly granular events (every field edit, every click) need abstraction or the model turns into a tangle no one can read.
  • Noise and rare, one-off paths need filtering, or the algorithm will contort itself trying to represent them.

Each step feeds the next, and skipping one tends to surface as confusion three steps later rather than as an immediate error.

Core Algorithms: Picking the Right Discovery Technique

Algorithm choice is less about brand loyalty and more about what your log actually looks like. The UPCommons evaluation of discovery algorithms groups the major families this way:

  • Alpha algorithm: the conceptual foundation of process discovery, valuable for teaching and simple cases, but fragile once real-world noise and loops enter the picture.
  • Heuristic Miner: built to tolerate noise and infrequent behavior, making it a dependable choice for messy, real operational logs rather than clean textbook examples.
  • Inductive Miner family: produces structured, sound models with formal guarantees like freedom from deadlocks, which matters when correctness has to be defensible, as the Inductive Miner and IMD research describes.
  • Evolutionary and hybrid techniques: optimize against a chosen objective function with more flexibility, at the cost of heavier computation.

The rule of thumb: log size, parallel activity, the amount of infrequent or exceptional behavior, and your need for soundness guarantees should drive the choice, not habit. Van der Aalst's work on process mining notes that no single algorithm wins across all log characteristics, so discovery is inherently a trial-and-compare exercise.

Pro Tip: Run two algorithm families on the same prepared log before committing. A structural disagreement between outputs usually points to a data issue worth fixing, not an algorithm to blame.

Event-Log Requirements and Preprocessing Before You Mine

Discovery quality traces back to the log, more than to the algorithm. Per guidance on event logs as mining input, a usable log needs at minimum a case id, an activity name, and a timestamp for each event, with the XES standard widely adopted for exchanging this data and CSV-to-XES conversion a common first step.

  • Extraction: pull data via connectors from ERP and ticketing systems where possible, reserving manual exports for sources without an API.
  • Correlation: when case ids are absent, heuristic rules can work for simple logs, while probabilistic approaches like EC-SA-Data assign case ids by optimizing against domain constraints and model alignment for messier ones.
  • Abstraction: group low-level events into business activities using clustering, pattern matching, or supervised mapping, bringing in subject-matter experts whenever the right grouping isn't obvious from the data alone.
  • Sampling: for large logs, sample deliberately rather than taking the first rows that load, checking coverage against the directly-follows relations present in the full dataset, as the Utrecht University sampling research recommends.

The UPCommons evaluation found that analysts often spend a large majority of project time on cleaning, correlation, and abstraction, well before discovery itself runs. A simpler algorithm on a well-prepared log tends to beat a sophisticated one applied to a noisy log.

Measuring Model Quality: Fitness, Precision, Generalization, Simplicity

A discovered model is only as useful as its fit to reality, and that fit gets measured across four dimensions identified in process discovery evaluation research: fitness (how much observed behavior the model can replay), precision (how much the model avoids allowing behavior that never happened), generalization (how well it handles unseen but plausible cases), and simplicity (how interpretable the resulting diagram actually is).

  • A model with perfect fitness but poor precision has usually overfit the log, permitting paths nobody ever took.
  • Chasing high precision too aggressively can produce a model so rigid it rejects legitimate variation as noise.
  • Simplicity often trades directly against fitness: a model that captures every exception gets harder to read with each added branch.

One of the clearest findings from the literature is that data preparation, not algorithm sophistication, is the dominant lever on these four quality dimensions. (UPCommons)

Validate the output before trusting it: replay the log against the model to catch obvious conformance gaps, hold out a portion of traces to test against, and walk the diagram past the people who actually do the work. Van der Aalst's research treats this as inherently iterative, since discovery is sensitive to log characteristics and rarely gets validated correctly on the first pass.

From Discovered Model to Business Action

A discovered model is a starting point, not a finished deliverable. What you do with it determines whether the exercise pays off.

  • Conformance checking compares the model against new cases to flag deviations, policy violations, and compliance gaps.
  • Performance analysis overlays timestamps on the model to expose bottlenecks, rework loops, and SLA breaches.
  • Decision mining examines the branching points in the model to surface the rules driving each path, which also sets up predictive monitoring for likely outcomes.
  • Improvement and automation programs take the validated model as their baseline, whether the goal is redesigning a workflow or scoping which steps a bot could take over.

Each of these treats discovery as groundwork: the model earns its keep once it changes a decision, a staffing plan, or a piece of automation.

Where Event-Driven Discovery Meets Conversational Capture

Event logs reconstruct what systems recorded, but they stay silent on why someone deviated from the standard path, which exceptions get waved through, or which judgment calls a tenured employee makes without writing them down. That is the gap conversational capture closes, by letting people describe their own process in their own words rather than inferring it secondhand from timestamps.

  • Combine event-log discovery with structured SME interviews whenever the mined model has unexplained branches or edge cases that fitness scores flag but can't interpret.
  • Conversational capture adds the reasoning behind a step, the kind of context a timestamp can't hold.
  • A short workshop, grounded in practical process-mapping steps, works well for walking a team through where the discovered model and the lived process diverge.
  • Asking "what do you do when the standard path doesn't apply" surfaces more exceptions than asking "what do you normally do."

The two methods answer different questions, and running them together closes gaps neither closes alone.

The Role of Conversational AI in Modern Process Discovery

Conversational AI has moved from a novelty to a working complement to log-based discovery, mainly because it addresses what logs structurally cannot capture: the reasoning behind a step. A system that interviews an employee in natural language can ask follow-up questions the way an analyst would, probing "what happens when the customer disputes the charge" rather than waiting for that exception to show up, rarely and ambiguously, in system timestamps.

This matters most in processes where judgment plays a large role: approvals, exception handling, escalation decisions. Those are exactly the cases where a mined model shows a branch in the data without explaining what drove someone down it. A guided conversational interview can ask directly, and because the interaction happens in the employee's own words, it preserves nuance that a rigid form or checklist tends to flatten out.

Integration works best treated as a second data source feeding the same model, not a replacement for log mining. Analysts can take an unexplained branch point from a discovered model and turn it into a specific interview question, then fold the answer back into documentation that sits alongside the model. The practical workflow in AI-assisted process mapping follows this pattern: mine what the systems show, then interview to fill in what they don't, and export the combined result into something teams can actually use, such as BPMN.

Event Logs Versus Conversational Discovery: What Each Actually Captures

Event log-based discovery and conversational discovery are answering different questions, and conflating them leads to disappointment with both.

Log-based discovery gives you scale and objectivity. It processes every case that ran through the system, with no sampling bias toward whoever happened to be available for an interview, and it reflects what actually happened rather than what someone remembers happening. Its blind spot is anything the system never recorded: the informal workaround, the phone call that resolved an exception, the judgment call that never generated a timestamp.

Conversational discovery gives you reasoning and context at the cost of scale. A guided interview captures why a step exists, what triggers a deviation, and how an experienced employee handles a case the SOP never anticipated, in their own words rather than a generic template's. It cannot process thousands of cases automatically, and it depends on the person being interviewed actually remembering and articulating their own behavior accurately.

Treat them as complementary layers rather than competing techniques. A practical sequence: mine the log first to get the skeleton of the process and flag any ambiguous or high-variance branch points, then use conversational interviews to resolve exactly those points rather than reinterviewing the whole process from scratch. The output from each layer, as laid out in guidance on documentation and decisions, should live in the same document rather than in two disconnected artifacts.

Why Verbal Process Articulation Is Harder Than It Sounds

Asking someone to describe their own process sounds straightforward until you try it. People tend to describe the ideal version of their work, the one from training, rather than what they actually do when a case gets complicated. They also skip steps that feel too obvious to mention, the kind of tacit knowledge that becomes a serious gap the moment that person leaves.

A few specific failure modes show up repeatedly:

  • Idealized recall: employees describe the documented SOP rather than their actual, adapted behavior.
  • Omission of the obvious: steps so automatic to an expert that they never think to say them out loud.
  • Inconsistent terminology: the same step described with different words by different people, which fragments what should be one unified process.
  • Missing exceptions: edge cases that come up rarely enough that they don't surface unless specifically asked about.

Addressing this takes structured, guided questioning rather than an open-ended "walk me through your process." Asking specifically about exceptions, about the last time something went wrong, and about what a brand-new hire would need to know surfaces far more than a generic prompt does. The seven-step approach to process documentation is built around exactly this kind of targeted questioning, aimed at capturing the decisions and exceptions a generic interview tends to miss.

Why Personalized, Context-Aware Documentation Changes the Outcome

A generic template asks everyone the same questions regardless of role, which means it captures the lowest common denominator of a process rather than the specific judgment calls that make one person's version of a job different from another's. Context-aware documentation adjusts its questions based on what the person has already said, the way a skilled interviewer follows a thread rather than reading from a fixed script.

This matters directly for discovery effectiveness. A mined model shows that a case sometimes takes path A and sometimes path B at a given decision point, but it can't explain the difference. A documentation approach that adapts its questions to the specific role, system, and scenario an employee describes is far more likely to surface the actual rule driving that split, because it can ask "why did you choose that option" in the moment rather than relying on a checkbox answer collected afterward.

The practical effect shows up most clearly during onboarding and knowledge transfer. A new hire reading a generic SOP gets the standard path. A new hire with access to documentation built from someone's actual articulated judgment, including the exceptions and the reasoning behind them, gets something closer to what an experienced colleague would tell them over coffee. That difference compounds across a team, since every retained piece of context reduces how often a newcomer has to guess or escalate.

Why Personalized, Context-Aware Documentation Changes the Outcome — overview diagram

What the Research Actually Supports, and What Gets Overstated

The evidence here points somewhere less exciting than the marketing around process mining tools would suggest: data preparation, not algorithm selection, is where projects succeed or fail. The UPCommons evaluation found analysts spending up to 80% of their time on extraction, correlation, and abstraction, which tells you where attention belongs. A lot of conventional advice skips straight to algorithm comparison, as though swapping Heuristic Miner for Inductive Miner will rescue a log full of unresolved case ids.

The bigger blind spot, though, is treating the event log as the whole story. Logs are an honest record of what systems captured, nothing more. They cannot tell you why someone deviated or what an experienced employee does by instinct, and no amount of algorithm tuning fixes that. We think the practitioners getting the most out of discovery are the ones who stop treating it as a purely computational problem and start treating the gaps in a mined model as a prompt to go ask someone. Prioritize clean data first, then validate with the people doing the work, in that order.

— Anthony

Capture the Knowledge Your Event Logs Can't See

Event-log discovery tells you what the system recorded. It won't tell you why your best account manager handles disputes differently than the SOP describes, or what a departing engineer knows that never made it into any ticket. That is where conversational capture earns its place alongside discovery rather than instead of it: it lets someone describe their process, exceptions and all, in their own words, and turns that conversation into structured documentation your whole team can search and cite.

Kept

Our platform works through guided interviews that ask about edge cases a template would never think to mention, then organize the answers into documentation tied to context, not just steps.

FAQ

What Is a Discovery Process in Business?

A discovery process in business generally means investigating how work actually happens, through methods like interviews, log analysis, or process mining, before deciding how to document, fix, or automate it. In process mining specifically, discovery refers to the automated construction of a process model from event log data.

Is Process Mining a Good Career?

Process mining combines data analysis, process modeling, and domain knowledge, and demand tends to track how widely organizations adopt data-driven process improvement. It suits people who enjoy both technical log analysis and the more conversational work of validating findings with the teams who actually run the process.

What Are the Four Types of Processes?

Common process management frameworks (not specific to process mining) typically distinguish primary, support, management, and governance processes, though naming conventions vary across sources. Definitions differ by framework, so check the specific model your organization follows before treating any single breakdown as standard.

What Are the Three Main Types of Process Mining?

Process mining is generally organized into three types: discovery (building a model from an event log with no prior model), conformance checking (comparing a model against real event data to find deviations), and enhancement (extending or improving an existing model using insights from the event log). The UPCommons evaluation frames discovery as the foundational first step that the other two build on.

Sources