Process mining has become a cornerstone for organizations to analyze and optimize their operational workflows. However, as these methods become increasingly complex and data-driven, they often exhibit black-box characteristics, leading to an interpretability gap. This gap undermines stakeholder trust and widespread adoption. We introduce a domain-specific, declarative explanation approach for interpreting complex patterns in event data. We present a semantic event log data model derived from the object-centric event data (OCED) metamodel, which is represented as a formal ontology (relational perspective) and enriched with Declare constraints (temporal perspective). Based on the semantic event log, we use diferent concept-learning approaches to derive rule-based explanations for domain experts. We demonstrate our method in two real-world case studies: (1) explaining clustering results in a classic event log, and (2) deriving interpretable subprocess explanations from an object-centric dataset. The results show that our approach produces high-fidelity explanations for classical event data but that further research is needed for object-centric data.
Process Mining (PM) has emerged as a field at the intersection of business process management and data science, providing methods for analyzing and improving business processes. By extracting insights from event data generated by Enterprise Resource Planning (ERP) systems, PM enables organizations to gain an actionable understanding of their workflows, provided that these technical insights are communicated in an understandable and trustworthy manner.
Despite this, the field of PM sufers from interpretability problems in three ways: (1) As it is a subfield
of Data Science [
These challenges highlight the importance of explainability in process mining. Efective explainability ensures that stakeholders trust the results and understand the rationale behind them, thereby increasing the usefulness of process mining methods.
Despite these needs, a significant gap remains: an explainer tailored specifically to explaining and diferentiating subprocesses within event data, including object-centric event data, is lacking. Such an explainer could be used in combination with classical process models, that can become highly complex, and should be able to concisely explain what separates subprocesses within the data. In addition, the unique characteristics of PM need to be addressed. Temporal dependencies between events, which constitute a step in a process, are at the core of process understanding. For instance, the temporal dependency between receiving and closing an invoice must be expressible in an invoice handling process. Using process mining-specific languages to solve this need, such an explainer could bridge the technical-business divide and help overcome the interpretability problem.
Our contributions are the definition of a domain ontology for process mining and its application in an event data explainer. In Section 2 we will introduce related work and in Section 3 some preliminaries. Then in Section 4 we introduce the architecture of our explainer via the four steps shown in Figure 1. Section 5 presents preliminary results on two use-cases. And finally, in Section 6 we discuss our results, including its limitations and an outlook on future work.
Declarative process mining refers to techniques based on process models specified in declarative,
constraint-based languages. Early work on declarative PM was based on ℐℱ ℱ integrity constraints
(ICs) [
The first discovery method [ 14] for Declare constraints thus used automata, an approach which was later made more eficient [ 15] and more meaningful via the exclusion of vacuous (misleading) constraints [16, 17] and discovery approaches [18, 19]. Notably, many approaches increase the expressivity of Declare constraints, for instance, by including the data perspective [16] or by introducing disjunction [20, 17].
Particularly in the field of predictive process monitoring (predicting results for incomplete processes), various xAI approaches, such as Shapley values[21] or LIME[22] have been applied to PM. Beyond predictive process monitoring, xAI has been used to explain concept drift in event data [23], introduces methods to increase trust in suggestions provided by process-aware recommender systems [24] and is used to group events into cases based on a process model and missing case identifiers [25].
ERP systems record organizational workflows through events, each representing a step in a process (e.g., a payment) occurring at some time. Events have types, referred to as activities. Events relate to objects such as persons, documents, or units, which may also relate to each other. Both events and objects can have attributes. To analyze event data one or more case concepts are identified, which are objects representing a type of process (e.g., an invoice for an invoice handling process). The ordered sequences of events related to instances of a case concept form traces, representing instances of a process. Traces have a variant, which is the ordered sequence of activities for the events.
Classical event data flattens ERP records to a single table based on one case concept. This discards
object relations and can distort process behavior via the introduction of artifacts [
Object-centric event data (OCED) extends classical data by preserving the relational structure of ERP systems. It supports multiple case concepts enabling process interactions (e.g., an invoice process triggering a payment process), while avoiding artifacts from flattening and including more semantic knowledge. We base our ontology on the OCED metamodel [26], which includes: (A) events with types and attributes, which are equivalent to classical event data, (B) typed objects with attributes and interrelations, and (C) qualified event-object relations such as create or modify. It is shown in Figure 2.
We formalize our ontology in the Web Ontology Language (OWL) profile OWL2DL, which is defined based on the Description Logic (DL) ℛℐ(). For the formal definitions, we refer to [27].
For our upper ontology we can directly capture the concepts and relations in the OCED metamodel via the DL classes Event, Time, Attribute, and Object and the properties event_to_object_relation, object_to_object_relation, observed_at (a Event is observed at exactly one Time), has_attribute (a Event or Object has any number of Attributes) and has_value (a Attribute has exactly one data value).
We can then take any classical or object-centric event log based on our upper ontology to derive a processspecific ontology. For this, we introduce all the types (Event types, object types, attributes names) in the data as subclasses of their respective concepts (Event, Object and Attribute). We do the same Presence(x) At least one activity x must occur.
Absence(x) No activity x can occur.
Response(x, y) If activity x occurs, then activity y must occur afterwards.
Precedence(x, y) If activity y occurs, then activity x must occur beforehand.
ChainResponse(x, y) If activity x occurs, then there must immediately be an activity y afterwards.
ChainPrecedence(x, y) If activity y occurs, then there must be an activity x immediately preceding it. for qualifiers, specializing event_to_object_relation and object_to_object_relation with new properties for each qualifier. Whenever we create a property we also create its inverse. Then, we instantiate all individuals, relations and data values in accordance with the data.
In declarative process mining, the constraint language Declare defines process models as conjunctions of constraints over activities. Typically, Declare constraints specify temporal dependencies between activities, grounded in Linear Temporal Logic over finite traces (LTL ) [28]. For formal semantics, we refer to [29]. For an informal overview of some Declare constraints, see Table 1.
Selecting Declare Constraints We use several approaches from declarative process mining to determine which Declare constraints to instantiate. First, we compute itemset-support [30] to exclude rarely co-occurring activities from binary constraints, and then we apply a threshold to constraintsupport [30] to retain only frequently satisfied constraints. Finally, we filter out vacuously satisfied [ 17] constraints, which are logically correct but can be misleading and thus are less interpretable. To compute the metrics we use established declarative conformance checker. The results are then instantiated into our ontology. Since the OCED metamodel lacks explicit traces, we represent each Declare constraint as a subclass of the case concept (e.g., Presence(payment) as a subclass of Invoice). It represents all invoice traces where the constraint holds. As classical event logs lack objects, we introduce abstract case concept instances based on case IDs.
With the inclusion of Declare constraints our ontology is complete. We can now extract conceptlearning problems and use concept-learning algorithms to derive explanations for patterns within the data. Informally, a concept learning problem is: Given a knowledge base and sets of positive (+) and negative (− ) examples of a target concept, find a class expression that best fit the examples, balancing coverage of positive instances and exclusion of negative ones. We use our ontology as background knowledge and identify positive and negative examples based on the use case.
Our method is agnostic to the concept learner used. We employ two CELOE [31] and the EvoLearner [32]. CELOE finds less expressive concepts, excluding data values. Hence, it is suitable when focusing only on temporal dependencies and object relations. EvoLearner ofers greater expressiveness via including data values in its concepts, but potentially generates longer concept expressions.
In contrast to classical process discovery techniques, which produces process models that try to encompass the whole process, our explanations identify the core behavior that separates two sets of traces within one process from each other.
Restricting the Background Knowledge We introduce two settings of restrictions on background knowledge, which enable diferent types of explanations. First is the Declare-only setting. It limits the background knowledge to Declare constraints, simplifying explanations to the temporal perspective and produces explanations which can be interpreted as Declare models with atomic negation. Second is the unrestricted setting. It includes the temporal perspective via Declare constraints and the remaining relational knowledge encoded in the ontology. The explanations learned in this setting are an embedding of Declare into Description Logic.
We present preliminary results on two use cases: a classical event log (Declare-only setting) and an object-centric one (unrestricted setting). We evaluate explanation fidelity using standard classification metrics (Accuracy, F1-score) and use the syntactic length of the explanation as a complexity proxy.
We analyze clusters derived from the RTFMP log using density-based clustering on boolean activity presence vectors. Since only the presence or absence of activities is used for the clustering, we are only interested in the temporal perspective. Hence, we employ the CELOE algorithm together with Declare-only background restrictions. The RTFMP dataset captures the process of managing trafic ifnes, which includes issuing fines, notifying recipients, and resolving payments or appeals. Fines that remain unpaid are escalated to credit collection through several distinct escalation and appeal paths. Results Table 2 shows the results for the first use case, excluding the noise cluster from our evaluation. We can see that all clusters observe perfect or near-perfect fidelity, with accuracy, precision, recall, and F1-score all at or very close to 1.00. This indicates that the generated rules are highly efective in covering the positive traces while excluding negatives. The complexity of the explanations is lowest for cluster 0 with a length of 1 and highest for cluster 3 with a length of 9.
Figure 3 shows the explanation for cluster 3. It contains two distinct behaviors: First, a fine is created, followed by an appeal to the prefecture, but no results of this appeal are received. Second, a fine is created and appealed to the prefecture. However, further escalation, such as an appeal to a judge or involvement of credit collection, is not included in the trace, nor is payment from the ofender. An interpretation of this explanation is that it describes appeals that have not yet been resolved or were successful and require no payment.
Response(create_fine, send_appeal_to_prefecture)
∧ Absence(receive_result_appeal_from_prefecture), Response(create_fine, send_appeal_to_prefecture) ∧ Absence(appeal_to_judge) ∧ Absence(payment) ∧ Absence(send_for_credit_collection) Figure 3: The explanation learned for cluster 3, presented as two disjunct Declare models 1 2 3 4 1770 30215
21 4844 884 927 9 73
Evo CELOE
Evo CELOE
Evo CELOE
Evo CELOE
We evaluate explanations for subprocess types in the BPIC19 dataset using both CELOE and EvoLearner in the unrestricted setting. The dataset, which was initially released as a classical event log and then manually transformed into an object-centric one, poses challenges due to noise, imbalance, and high variant complexity. It is derived from the purchase order process of a large multinational and includes four annotated subprocesses with distinct behaviors, which we attempt to diferentiate with our explanations.
Results EvoLearner generally achieves higher fidelity, though with more complex explanations (avg. length 5.25 vs. 1.5). Both learners struggle on subprocesses 3 and 4, potentially due to label imbalance and noise. Subprocess 2 is best explained by both learners (Acc. 0.90, F1 0.94), with CELOE producing a smaller yet accurate explanation. Figure 4 shows an explanation with good fidelity. The explanation for subprocess one shows that we do indeed get a combination of the temporal perspective via a Declare constraint, requiring that no clear_invoice follows directly after a record_goods_receipt and a relational perspective via quantification over relations in Description Logic, requiring that the recording of a service sheet must modify the purchase order item.
Subprocess 1, EvoLearner:
NotChainResponse(record_goods_receipt, clear_invoice)
⊓ (∃ inverse_modify.record_service_entry_sheet)
We presented an ontology-based architecture to explain process behavior using concept learners and Declare constraints, supporting classical and object-centric event data. Through restrictions on the ontology, our method can incorporate temporal constraints alone (Declare-only setting) or both temporal and relational perspectives (Unrestricted setting). Applied to a classical log, we achieved good ifdelity in explaining clustering results in the declare-only setting. Initial results are promising but mixed for the unrestricted setting on object-centric data. The explanations include a temporal and relational perspective, but fidelity was low for some subprocesses.
Explanation fidelity for our object-centric use case is limited partly due to the quality of the OCED dataset. Additionally, our current approach requires identifiable negative examples and has only been evaluated using basic fidelity and complexity metrics. While we argue that explanations are understandable, this has not yet been validated, and future user studies are needed.
Future work will evaluate object-centric data more exhaustively. We want to look at explaining more complex clustering approaches, e.g. clustering based on Declare constraints, or an ontology embedding. We aim to improve interpretability, potentially using verbalization techniques. Furthermore, we also plan to integrate richer domain knowledge such as organizational structures or business rules to improve explanations.
Funded by the Bavarian collaborative research program (BayVFP) under project KIGA (DIK0313/02).
During the preparation of this work, the author(s) used ChatGPT-4o and Grammarly in order to: Grammar and spelling check, paraphrase and reword, improve writing style, drafting content. After using these tool(s)/service(s), the author(s) reviewed and edited the content as needed and take(s) full responsibility for the publication’s content.