Three terms are doing a lot of work in vendor decks at the moment: process mining, process intelligence and execution intelligence. A fourth, the idea that a process model is the context an AI needs, is arriving behind them. They are used loosely, sold hard, and often as if they were interchangeable.
They are not. They are stages of one thing, built on one event log, and the order is not optional. This article defines each by what it does, using a single order that runs through the whole piece: order 20471, which was received on a Monday with a two-day delivery promise, hit a credit check that ran twice, and was still sitting in the queue on Thursday.
If you have not read what an event log needs to contain, that piece is the foundation for this one. Everything below assumes the three fields, case, activity and timestamp, are already in hand.
Process mining: the picture
Process mining reads the event log and reconstructs the process as it was actually run: every path a case took, how many took each one, and how long every step and every wait between steps took.
For order 20471, mining shows the path received → credit check → credit check → pick and pack → shipped, and it shows that 31 per cent of orders in the last quarter took that same loop through credit check, adding a median 2.4 days. It shows this by product, by channel and by team, because those attributes were in the log. It also shows conformance: where cases deviated from the designed process, skipped a control, or reached a step by a route the procedure does not allow.
That picture is the thing most organisations have never had. Before it, the conversation about the credit-check delay ran on anecdotes; after it, the delay is a number with a cause attached.
Its limit is that it is a picture. It was true on the day it was built, from a log extracted on that day, and it describes what happened. It cannot say what is happening now, and it cannot tell you what will happen to the order that entered the queue this morning.
Process intelligence: the picture kept live, and explained
Process intelligence is what mining becomes when it stops being a project and becomes a capability. Two things change.
The model stays live. Instead of a one-off extract, the event log is connected to the systems that write it and refreshed continuously, across every product, region and touch-point the process runs through. The discovered process is no longer a snapshot from March; it is the process as of this morning. That is what makes improvement measurable: when the credit team changes its rules, the rework loop is seen to shrink, or not, in the same model that found it. It is also what catches regressions, because a control that quietly stops being applied shows up as a conformance change the week it happens rather than in the next audit.
The model is explained. Discovery says where cases stall; it does not say why. The explanatory layer puts models on the case attributes, product, channel, team, time of day, order value, customer segment, and finds which of them predict the loop. For order 20471’s process, the answer turns out to be that the second credit check is triggered almost entirely by orders above a value threshold placed through one channel, where the first check is run against a stale limit. That is a root cause, and it points at one fix rather than a general instruction to “speed up credit”.
What changes for the business is the cadence. The monthly process review, built on a report someone assembled, becomes a daily view of the live process. And the argument about causes becomes a query.
Execution intelligence: acting while the case is open
Everything so far describes the process. Execution intelligence intervenes in it, case by case, while there is still time to change the outcome.
It works in three steps, each of which depends on the layer beneath it.
Score. Every open case is scored for the probability of a bad outcome: missing the delivery promise, breaching an SLA, failing a control, being reworked. The score comes from the same explanatory models, now applied to cases still in flight. Order 20471, on Tuesday morning, is at 82 per cent probability of missing its promise, because it is above the value threshold, came through the channel with the stale limit, and has been at credit check for longer than the median.
Recommend. For each at-risk case, a next-best-action: release the hold and expedite, split the shipment, re-route to a senior queue, request the missing document now rather than at the next step, or wait, because intervening would cost more than it saves. The recommendation is chosen by measured outcome: what actually worked for cases like this one, in this process, recorded in the same log.
Act. Where the fix is routine and the control allows it, an agent performs the action: releasing the hold, re-assigning the queue, sending the request, opening the ticket. Where it is not routine, or the control requires a person, the recommendation goes to the team lead with the case and the reason attached. Either way, the action itself is written back into the event log as an event, so that what was done, by whom or by what, and what happened next, is part of the record the next model learns from.
The honest caveat, and the reason the order of the stages matters: execution intelligence without a live, explained process is automation of a guess. A score with no model behind it is a threshold somebody set; a recommendation with no measured outcomes behind it is a rule somebody wrote. Both can be built quickly, and both fail quietly, because nothing is checking them against what the process actually did.
Context for AI: why the log is what the model needs
This is the stage most current material skips over, and it is where the previous three stop being process-improvement techniques and become the precondition for using AI on real work at all.
Give a language model or an agent the procedure document and it knows how the process is supposed to run. Ask it about order 20471 and it will answer from the document: the credit check happens once, orders ship within two days. It has no way to know that this order is on its second credit check, that the channel it came through has a stale limit, or that releasing the hold is the action that worked for the last two hundred cases like it.
Give it the live process model and the case’s own event history instead, and it knows how the process is running and what state this case is in. That is context, in the specific sense the word deserves:
- Definitions. What a case is, what each activity means, what counts as a breach, what the designed path is. The process model is the semantic layer the AI reads from, so that “credit check” means the same thing to the agent as it does to the credit team.
- State. Where every open case is right now, how long it has been there, and what has already been tried. Not a document’s idea of the process, but the log’s record of it.
- Evidence. The measured outcomes of past interventions, which is what turns “recommend” from a plausible sentence into a choice with a track record.
The same structure is what makes the AI governable. An agent operating on a process model can only take actions the model defines; it cannot invent a step. Everything it does is an event, in the same log, with the same timestamps and case IDs as everything a person does, which means it is auditable by the same conformance checks that audit the humans. The control function does not need a separate AI-oversight system; it needs the event log it already has, with the agent’s actions in it.
That is the difference between “AI-powered” as a label and AI whose behaviour is bounded by a model of the real process. The first is a claim; the second is an architecture.
What each stage looks like from the business side
The four stages read differently depending on where you sit.
- An operations leader gets, from process intelligence, a live view of where the process is stalling this week, by product and team, with the cause attached.
- A team lead gets, from execution intelligence, this morning’s at-risk cases with a suggested action for each, and the routine ones already handled.
- A control or compliance function gets every intervention, human or agent, as an event in the log, checkable against the designed process.
- A CIO gets AI whose scope is defined by the process model, whose actions are logged, and whose value is measured in the same numbers the business already uses: promise kept, SLA met, rework avoided.
Where to start, and why you cannot skip
The stages are a ladder, and the rungs are load-bearing.
There is no execution intelligence without an explained, live model to score against. There is no live model without discovery having established what the process is. There is no discovery without a log that has the three fields, harmonised across the systems the process runs through. And there is no trustworthy AI on the process without all of the above, because the model is the context.
Most organisations are at the first rung or the second, and that is fine; the first rung is where the largest and cheapest findings are. What matters is knowing that the ladder exists, so that “we want agents on our order process” is understood as a destination with a route, rather than a product to be bought.
The route starts the same way every time: with the event log your systems are already writing. Check whether yours is ready in five minutes. If it is, a two-week pilot climbs the first rung with your real data, and shows you, on day ten, how far up the ladder the process is worth taking.