Is Process Mining Dead?
As the entry ticket to automation, yes. As a precision instrument for a specific question, no.
Your AI can start the way a capable new hire does, with an assignment, someone to ask, and the freedom to question why things are done the way they are.
The real problem was never a lack of process maps
It was automation that could not handle doubt. Traditional RPA follows predefined paths and breaks on a variation nobody anticipated. Early LLM-based automation fails the other way: it invents the missing rule, producing a decision that is plausible and wrong. Either way, the defensive move was to specify everything in advance.
Breaks. The only defense is to catalogue every variation upfront.
Guesses. Invents a rule and moves on: plausible, and wrong.
Asks. A person answers once, and the answer becomes a reviewed rule.
Judge an automation the way you would judge a promising hire: by what it does at the edge of what it knows, not by the length of its briefing.
Logs tell you what happened. They never tell you why.
An event log will tell you an invoice was put on hold, two receipts were merged, and someone overrode the match. It won’t tell you whether that override followed policy, was a one-off call, or was an error. That missing reason is what an automation needs to get the next case right, and most of the time it exists only in someone’s memory.
Match receipts to the order line
- Reconcile against the quantity received.
- Combine the receipts for one order line, because a supplier can deliver in several shipments and the match has to see the whole quantity, while goods from other lines stay out of it.
The reason lets a person check the rule, not just its output.
The reason shows when the rule applies to a similar situation.
When circumstances change, the why says whether the rule still holds.
Hire AI the way you hire people
A good new hire doesn’t wait until they know every edge case. They do what they’ve been taught, look things up, and ask when they hit something they can’t resolve. That is the minimum sufficient assignment, and it is enough for well-designed AI.
A goal
What done looks like, stated plainly.
Authority & access
Permission to use the systems the work needs.
The standard process
The documented way, or someone to watch perform it.
Good output
A sense of what acceptable results look like.
A mentor
A person who answers the questions it can’t resolve.
It doesn’t make things up. When it can’t justify the next step, it stops and asks. A person answers. It learns.
Compile once. Learn on the job.
Kognitos builds the onboarding into the product. Quill does the first week’s investigation at build time. Astral handles the cases that don’t fit the manual, together with a person, and turns the answers into rules that people approve.
Quill: the new hire who reads everything on day one
Hand Quill an objective and permission to the systems involved, and it starts reading: which tables and fields in the ERP or CRM matter, how they relate, and what real records look like. It studies how recent transactions were actually settled, drafts and tests the steps, and only interrupts a person, with a specific question, when something it needs is still unclear.
That investigation is a build-time cost, paid once. After that, each run applies the compiled steps to whatever data is current.
Astral: learning on the job
When a case falls outside the compiled process, it goes to the Kognitos workbench, where Astral resolves it with a person and records why. As patterns emerge, Astral documents them as rules, and people approve them before they run in auto-mode.
One-off judgments stay one-off; reusable answers become reusable instructions: business logic your company owns, not settings in someone else’s menus (see build the logic, buy the platform). See how this works in the Kognitos platform and in English as Code.
Retire the ritual. Keep the instrument.
Requiring a full mining exercise before any automation can begin no longer makes sense. Pointing process mining at one well-defined question still does. What should drive the work is the question being asked, not the habit.
Process mining as the front door
- Mapping everything before any automation can start
- Pulling weeks of logs and desktop recordings before anyone builds
- Committees debating a spaghetti diagram for months
- Signing off on a map after the process it describes has already changed
Process mining as a precision instrument
- Conformance audits against a documented process
- Targeted bottleneck analysis when nobody knows why performance is poor
- End-to-end redesign across many-to-many relationships, where object-centric standards such as OCEL 2.0 help
- Any broad analysis that a specific question genuinely warrants
“But doesn’t AI need process intelligence?”The objection, answered in section 07 of the paper
It does, and on that point we agree with Wil van der Aalst, whose paper No AI Without PI makes the case that AI inside an organization has to rest on process intelligence. The disagreement is narrower: whether that intelligence has to be mined before anything else happens. A new colleague builds the same understanding by looking at the systems, reading the documentation that exists, and asking whoever knows. The IEEE Process Mining Manifesto itself recommends beginning with questions instead of extracting everything.
Don’t take our word for it. Run the side-by-side test.
Pick a single live assignment and run both approaches on it, discovery-first and Kognitos, with identical access to systems, policies, and documents. Agree on what counts as acceptable before you start, keep build effort and runtime results in separate columns, run in shadow mode first, and make sure the test set holds the awkward cases: rules open to interpretation, records split across documents, and steps nobody has the authority for.
Time and total effort
All the effort from preparation and discovery through review and fixes, up to the point the automation is accepted.
Verified outcomes
How many eligible cases ended correctly and with proper authorization, reported with the sample size and anything left out.
Independent discovery
What each approach worked out unaided, measured against a person learning the same process.
Handling doubt
Whether it stopped when it should have, which ambiguities slipped through, which questions were unnecessary, and how much of people’s time it took.
Learning and redesign
Whether approved rules keep holding up, and what proposed process changes actually do once they are tested.
Asking less is only a win when the results are still right. Count unresolved cases and failures alongside the completed ones; a short, polished demo says nothing about running reliably.
Questions about process mining and AI
Is process mining dead?
As the required first step before automation, yes. As a field, no. Exhaustive mining and discovery became mandatory because older automation couldn't cope with what it hadn't been told: RPA failed on unexpected variations, and unsupervised LLMs filled gaps with invented rules. AI designed to investigate, stop and ask when uncertain, and improve on the job no longer needs that safeguard. Process mining is still the right tool for a pointed question, such as checking conformance or finding the cause of a bottleneck.
Do you need process mining before AI automation?
Not by default. A capable automation can begin with what a new hire gets: a defined goal, permission and access to the systems, the documented process or someone to demonstrate it, a sense of what good output looks like, and a person to ask. The non-negotiable part is that it stops and asks instead of guessing when it can't justify a step. Bring in targeted process mining when a specific question calls for it.
Why doesn't process mining capture the why?
Because event logs only record actions. They show a held invoice, two merged receipts and an overridden match, but not the reason for the override: a policy exception, a one-time decision, or an error. An automation needs that reason to handle the next similar case, and usually only the people involved know it.
How does Kognitos discover a process without process mining?
While the automation is being built, Kognitos Quill, the English-as-Code builder, investigates the connected ERP or CRM: which tables and fields matter, how they relate, and what sample records contain. It reviews a small set of recent transactions and how they were settled, checks its conclusions against the written policy, builds and tests the steps, and asks a specific question only when something essential is still unclear. The investigation happens at build time; every run afterwards applies the compiled steps to current data.
How does Kognitos learn from exceptions?
Cases the compiled process can't handle go to the Kognitos workbench, where Astral works through them with a person and asks why that resolution was the right one. The reasoning is kept. When the same kind of exception keeps appearing, Astral writes it up as a rule, and people review and approve it before it can run in auto-mode. Writing a rule down doesn't turn it on; a human approval does.
Doesn't AI need process intelligence?
It does, and Wil van der Aalst's No AI Without PI is right that organizational AI must rest on process intelligence. The open question is where that intelligence comes from. A new employee builds it by looking at the systems, reading what already exists, and asking colleagues, and AI can work the same way. Intelligence gathered like that is specific to the task, carries the reasons behind decisions, and grows with every exception that gets resolved.
When should you still use process mining?
When a particular question justifies a broad analysis: auditing conformance, explaining a bottleneck nobody can account for, or redesigning a process end to end across many-to-many relationships, where object-centric formats such as OCEL 2.0 are useful. The IEEE Process Mining Manifesto also recommends starting from questions instead of extracting everything. Let the question set the scope, not the habit.
How do you prove an AI-first approach works?
Run both approaches on the same real assignment, with the same access to systems, policies and documents. Track build effort apart from runtime results, include difficult cases such as rules open to interpretation, records split across documents and missing authority, run in shadow mode first, and agree the acceptance bar before widening what the automation may do. Asking fewer questions only counts if the results stay correct.
Process Mining Is Dead.
The full argument: why the ritual existed, how to onboard AI like a new hire, what Quill and Astral do, the objection from process intelligence, and a scorecard for testing it on your own work. Free, with 17 references.
