Process Events: Turning Real Work into Analyzable Event Data

What is a process event?

The Process Mining Manifesto describes event logs as the starting point for process mining. In the classic basic model, each event relates to an activity and a specific process instance; events are ordered and may contain additional information such as timestamps or executing resources.^[1]

An event is therefore more than a technical log line. To understand it operationally and analyze it later, it must be clear which real occurrence it represents. The string task.completed alone conveys little information. Only its connection to a specific task, batch, time, result, and responsible role turns it into usable process information.

A consumption event with an unambiguous trigger

In an illustrative operation, a person confirms the consumption of 2.4 kilograms from material batch M-04 within task A-17 for product batch C-24. Event E-208 documents this confirmation. A generic click on “Task completed” is not sufficient to assert that same quantity.

Such events can be building blocks of an Electronic Batch Record. The EBR, however, is the complete batch-specific record rather than an individual event.

This record explains what was confirmed and in which context. It is not independent proof that precisely this quantity was physically consumed. The capture method and any associated evidence remain relevant to the assessment.

Semantics determines later value

Structure alone does not establish unambiguous meaning. When a system logs Aufgabe abgeschlossen, it may mean that the person confirmed the final step. It may also mean that a substantive result was generated, a test passed, or a subsequent process triggered. People may infer these distinctions from the user interface; in event data, they must be modeled explicitly.

The Process Mining Manifesto calls for event data to be treated as a distinct, high-quality foundation. It emphasizes, among other things, that events should have well-defined semantics and be recorded at an appropriate level of abstraction.^[1]

In practice, this means:

• event types have a documented meaning,
• identical labels refer to comparable actions,
• units and value ranges are unambiguous,
• state changes identify the starting and resulting states,
• participating objects are connected in their respective roles, and
• technical system messages are not presented as domain events without review.

A semantically sound event structure matters beyond analysis tools. It also improves understanding between operations, quality assurance, development, and subsequent reviewers.

Reuse known context and confirm the action

Task A-17 may already know its product reference and the applicable work instruction. This information need not be typed again for every consumption entry. Capture should nevertheless show which association was reused and which information was explicitly confirmed.

A proposed material batch has not yet been confirmed as actually used. Likewise, a planned quantity is not measured consumption. Event design must preserve these distinctions so that a conveniently prefilled form does not create an incorrect factual assertion.

What information a process event needs

The specific structure depends on the use case. Some elements are nevertheless regularly required to keep an event from remaining isolated.

The right granularity

OCEL 2.0 describes events as discrete, atomic actions or observations at a specific point in time.^[3] Atomic does not mean that an event must represent every smallest technical operation. It should represent a meaningful domain unit that does not need further decomposition for the intended purpose.

If granularity is too coarse, relevant differences disappear. A single event Produktion abgeschlossen does not show which materials were used, which tests were performed, or which rework was required. If it is too fine, a flood of technical messages makes the operational context difficult to reconstruct.

The appropriate level therefore depends on the question to be answered later. In a batch process, separate events may be useful for:

• the start and end of an executed task,
• use of a specific material batch,
• capture of a measurement relevant to a decision,
• occurrence and classification of a deviation,
• request and completion of rework,
• review of a result, and
• granting, restricting, or refusing a release.

Individual clicks, page views, or purely visual changes, by contrast, are not automatically domain process events.

A later review is another event

If E-208 is reviewed later, the review decision refers to the specific consumption record. It must not appear as though it already existed at capture. An objection or required correction also receives its own reference.

This keeps execution and assessment distinguishable. Later sequence alone is insufficient to establish the association: a reviewer may handle multiple records, and their decision must identify the item actually affected.

Order is more than sorting by time

Processes arise from sequences and dependencies. A timestamp supports chronological sorting, but does not fully represent every domain relationship. Two actions may take place in parallel. A later correction may explicitly reference an earlier result. A review event may confirm a particular execution without having been stored immediately afterward.

Direct relationships may therefore be needed in addition to time information:

• this event corrects an earlier event,
• this review refers to this execution,
• this material consumption occurred within this task,
• this release applies to this product state,
• this rework was triggered by this objection.

Such relationships prevent process context from being reduced to a mere chronological list. Time order remains important, but is supplemented by domain connections.

Events, states, and records are not the same

A state describes the condition of something at a particular time: a batch is on hold, material inventory is 18 kilograms, or a task awaits review. An event, by contrast, describes what contributed to that state: the batch was placed on hold after a deviation, four kilograms of material were consumed, or an execution was sent back for rework.

An ordinary record is not automatically a process event either. A master data row may contain an equipment name or the current product label without representing a specific action. Conversely, an event can reference such records and make their meaning within a process visible.

The distinction matters:

States can be derived from or explained by events. The architectural principle of event sourcing uses such an ordered event sequence to derive a system's state. This requires events with unambiguous content, correct connections, and a reliable order.

Data quality begins before analysis

An analysis method can work only with what the event data contains. Missing events, changing meanings, unreliable timestamps, or incorrectly connected objects do more than create a technical quality problem. They change the picture of the actual process.

The Manifesto identifies trustworthiness, completeness, and well-defined semantics as central quality requirements for event data.^[1] The XES context also emphasizes that standardized event data should be transportable, storable, and exchangeable between tools.^[2]

The quality of an individual event is part of a larger question. Data integrity requires data to remain complete, consistent, accurate, and reliable throughout its lifecycle. For event data, this concerns generation, correction, transfer, retention, and later usability for analysis, among other things.

The data item's provenance also needs separate consideration. Data provenance makes it traceable which observation, entry, or processing generated information and which actors or operations were involved. An event can carry such relationships, but does not replace a complete provenance model.

When selecting the first production digitization use case, the available data must therefore be assessed first: which required information already exists, which has unclear associations, and which would need to be collected?

From event meaning to the analysis question

Process mining can use event data to investigate processes.[1][2] In the consumption example, the meaning of a time measurement depends on whether E-208 dates the physical consumption or its later confirmation. Otherwise, the same interval would be interpreted differently.

Conformance checking compares recorded behavior with a model. Here too, the event type must match the action being compared: a recorded quantity confirmation is not simply equivalent to any task completion.

What process events do not prove

• A stored event does not automatically prove factual accuracy. An incorrect input can be logged correctly and still be wrong.
• Process events are not equivalent to an audit trail. An audit trail's requirements, scope, and purpose depend on the specific system and regulatory context.
• Analysis does not produce an automatic compliance assessment. Results must be interpreted in their respective domain and legal context.

An event label is a commitment about domain meaning

Someone reading E-208 as “Material consumption confirmed” must be able to identify the quantity, material, and confirmation concerned. This meaning must not change unnoticed between forms, interfaces, and analyses.

Designing a process event therefore starts with its trigger and claim. Identity, time reference, and objects keep that claim attributable. Only then can one assess which process question the stored trace can actually answer.