Event log
The raw record of what happened, in what order, to what. The substrate every process claim rests on, and the easiest thing in the stack to underestimate.
An event log is a table with three columns that matter: a case ID (which claim, which order, which patient), an activity (what happened), and a timestamp (when). Everything else is optional. Add the person or system that acted and you can answer questions about handoffs. Add a cost or an outcome and you can answer questions about money.
That is the whole format. Its power is that almost every enterprise system already emits it, whether or not anyone asked for it.
Why it matters now
Process mining, simulation, and agent supervision all read the same substrate. When a team says the redesign is “evidence-based,” the evidence is an event log. When an agent needs to know which variant of a process it is in, it is reading one. When the auditor asks what the agent did in March, you are handing over one.
This makes log quality a strategic question rather than a plumbing question. An organization with clean, case-keyed, cross-system events can redesign a process in weeks. One without cannot, and no amount of model quality substitutes.
The misuse
Two failures are near-universal.
The first is confusing an application log with an event log. Your systems produce enormous volumes of technical logging: errors, API calls, page loads. Almost none of it is case-keyed, so none of it answers “what happened to claim 4471.” Volume is not the same as structure.
The second is the broken case ID. A process that crosses four systems usually has four identifiers for the same piece of work, and no reliable join between them. Reconstructing that join is the real cost of a process-intelligence program, and it is where most of the timeline goes. Budget for it, and be suspicious of any vendor demo that skips it.