Is process mining dead?

As the entry ticket to automation, yes. As a discipline, no. Exhaustive process mining and discovery became a prerequisite because automation could not handle what it did not know: traditional RPA broke on variations nobody anticipated, and unchecked LLMs invented missing rules. AI that is built to investigate, ask when it is unsure, and learn on the job does not need that workaround. Process mining keeps a place as a precision instrument for a specific question, such as a conformance audit or a targeted bottleneck analysis.

Not as a default. A capable automation can start with the minimum sufficient assignment: a clear goal, the authority and access to do the work, the standard process or someone to show it, a sense of what good output looks like, and a person who answers questions. It must also stop and ask, rather than guess, when it cannot justify the next step. Commission targeted process mining when a defined question warrants it.

Event logs record what happened: an invoice was held, two receipts were combined, an approver overrode a match. They do not record why. Was the override a policy exception, a one-time judgment call, or a mistake? That reasoning is what an automation needs to handle the next case correctly, and it usually lives in people's heads.

At build time, Kognitos Quill, the English-as-Code builder, explores the connected ERP or CRM: the relevant tables, fields, relationships, and sample records. It examines a focused sample of recent transactions and how they were adjudicated, checks what it inferred against the written policy, builds and tests the steps, and asks a pointed question only when a necessary detail remains unresolved. The exploration happens once; every runtime execution reuses the compiled steps against current data.

When a case falls outside the compiled process, it goes to the Kognitos workbench, where Astral resolves it together with a person. Astral asks why that resolution was chosen and records the reasoning. As patterns emerge, Astral documents them as rules, and people review and approve those rules before they are enabled in auto-mode. Recording a rule does not switch it on; approval does.

Yes. Wil van der Aalst argues in No AI Without PI that organizational AI must be grounded in process intelligence, and he is right about grounding. The disagreement is about where that intelligence comes from. It can be gathered the way a new employee gathers it: by inspecting the systems, reading what already exists, and asking the people who know. That intelligence is tied to the task, includes the why, and keeps growing with every resolved exception.

When a specific question genuinely warrants broad analysis: a conformance audit, a bottleneck nobody can explain, or an end-to-end redesign across many-to-many relationships, where object-centric standards such as OCEL 2.0 help. Even the IEEE Process Mining Manifesto advises starting from questions rather than extracting everything. The difference is who is in charge: the question, not the ritual.

Run a side-by-side test on one real assignment. Give a discovery-first approach and Kognitos the same access to the same systems, policies, and documentation. Measure the build separately from runtime, include hard cases such as ambiguous rules, split records, and missing authority, start in shadow mode, and agree on acceptance thresholds before expanding what the automation is allowed to do. Fewer questions only count if outcomes stay correct.