# Extracting Process-Aware Decision Models from Object-Centric Process Data

Alexandre Goossens, Johannes De Smedt , Jan Vanthienen  0000-0001-8907-330X
0000-0003-0389-0275 0000-0002-3867-7055<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
###### Abstract

Organizations execute decisions within business processes on a daily basis
whilst having to take into account multiple stakeholders who might require
multiple point of views of the same process. Moreover, the complexity of the
information systems running these business processes is generally high as they
are linked to databases storing all the relevant data and aspects of the
processes. Given the presence of multiple objects within an information system
which support the processes in their enactment, decisions are naturally
influenced by both these perspectives, logged in object-centric process logs.
However, the discovery of such decisions from object-centric process logs is
not straightforward as it requires to correctly link the involved objects
whilst considering the sequential constraints that business processes impose
as well as correctly discovering what a decision actually does. This paper
proposes the first object-centric decision-mining algorithm called Integrated
Object-centric Decision Discovery Algorithm (IODDA). IODDA is able to discover
how a decision is structured as well as how a decision is made. Moreover,
IODDA is able to discover which activities and object types are involved in
the decision-making process. Next, IODDA is demonstrated with the first
artificial knowledge-intensive process logs whose log generators are provided
to the research community.

###### keywords:

Object-centric Event Logs , Process Mining , Decision Mining

organization=Leuven Institute for Research on Information Systems (LIRIS), KU
Leuven, addressline=Naamsestraat 69, city=Leuven, postcode=3000,
country=Belgium,

##  1 Introduction

Organizations and companies regularly execute business processes to achieve
specific objectives, like delivering a product or creating a website. Business
processes can be monitored with so-called process-aware information systems
logging each step of the process hence storing the history of business
processes in process logs. Traditionally, business processes have been logged
and discovered from a single point of view with, e.g., only the traveler’s or
the airplane’s point of view in an airport luggage handling process [22, 13].
However, business processes, like information systems, often include multiple
object types within their process, e.g., in a luggage handling process objects
include travelers, luggages, airlines, airplanes and the airport, with
distinct perspectives and interactions (e.g., passenger checking in luggage
with an airline) in the system. This complexity means that traditional single
object type process logs, such as eXtensible Event Stream (XES) [17], are not
always suitable to log and discover complete process models involving multiple
object types [30]. These so-called object-centric processes have recently
gained traction with multiple object-centric process modelling proposals [31,
20, 29, 14] and object-centric process logging proposals [22, 32, 13, 15]
being introduced. Object-centric event logs enable the logging and analysis of
object-centric business processes. For instance, in the airport luggage
handling process, the check-in event can now be associated with all relevant
objects like the passenger, luggage, and airplane, instead of just one.
Furthermore, companies make decisions based on information from multiple
object types, such as luggage handling decisions influenced by factors like
the customer’s ticket, luggage details (weight, dimensions and content),
aircraft and potentially airport policies [33]. Decisions can therefore be
considered as inherently object-centric and are fit to be logged alongside
object-centric processes with object-centric process logs.

This study is particularly interested in knowledge-intensive processes (KiPs)
where the order of activities is heavily influenced by the knowledge and
decision-making of the process performers. Such KiPs are mainly driven by
decisions which based on various inputs determine an output which in turn
might influence individual process instances. Finally, it is considered good
practice to model operational decisions in decision models [33]. A common
standard for this is the Decision Model and Notation (DMN) standard allowing
to model both the decision structure and decision logic [24] allowing to
communicate, model, execute and automate operational decisions. Note that DMN
allows also for more complex rules involving multiple variables.

This paper presents a novel object-centric algorithm, the Integrated Object-
centric Decision Discovery Algorithm (IODDA) which discovers both the decision
structure and the decision rules present in the object-centric process log and
brings both together in a complete DMN model [24]. IODDA is also able to
identify how and which activities and object types are involved in the
decision-making process. The algorithm draws inspiration from a single-object
perspective DMN discovery algorithm implemented on XES logs [8]. Due to a lack
of publicly available knowledge-intensive object-centric process logs, this
paper also provides the two first artificial knowledge-intensive process logs
and log generators in the recent DOCEL standard. The algorithm’s effectiveness
is validated through its successful application on these two artificial logs,
effectively rediscovering the relationships between variables and the
underlying logic governing process execution. The main contributions of this
paper are:

  * 1.

Proposing the first algorithm, IODDA, to discover object-aware DMN models from
Data-aware Object-Centric Event Logs (DOCEL).

  * 2.

The first artificial DOCEL log generators for two different problems are made
available together with the set of artificial DOCEL logs used in this paper.
The source code of the log generators is also provided so that the research
community can replicate this for other knowledge-intensive process generators.

The rest of the paper is structured as follows: Section 2 deals with the
related work followed by Section 3 illustrates the problem. Next, Section 4
deals with the preliminaries and Section 5 introduces the novel algorithm.
Section 6 introduces the artificial log generators with Section 7 illustrating
how the algorithm works in practice. Sections 8 and 9 respectively deal with
the discussion, limitations and future work. Lastly, Section 10 concludes this
paper.

##  2 Related Work

The following section first deals with the field of object-centric processes
and secondly an overview of works studying the extraction of decision models
from single-object point of view process logs is provided.

###  2.1 Current Research in Object-Centric Processes

Despite the recent surge in interest for object-centric processes, the concept
of multiple object types influencing a business process was already proposed
in 2001 with the introduction of so-called proclets, which are sub-processes
dealing with an artifact within the context of a business process [31]. Over
the years, various object-centric visualization proposals have been introduced
such as Colored Petri Nets (CPN) [20], Catalogue and Object-aware Nets (COA)
[14] or Guard-Stage-Milestone models (GSM) [19]. Despite these proposals,
there is still no established standard modelling language for object-centric
processes.

The execution of object-centric processes can be logged in event logs.
However, due to the object-centric nature of these processes, a single object
point of view event log such as XES logs results in some information loss due
to divergence and convergence issues [30]. Divergence issues cause certain
activities to not clearly be allocated to the correct object anymore whilst
convergence issues incorrectly multiply certain activities to incorrectly
match their actual number of occurrences.

Because an object-centric process can be viewed from the point of view of
multiple objects simultaneously, the traditional concept of cases and traces
is not valid anymore for object-centric processes. To execute an object-
centric process it is therefore important to know which objects are related to
one another and which objects are involved in each activity [13, 22, 15, 11].

With the XES event logging format [17] being unusable to store object-centric
event processes [30], other logging formats were introduced to solve this
issue. Both Object-Centric Behavioral Constraint (OCBC) models [32] and
eXtensible Object-Centric (XOC) logs [22] realized the importance of object-
object relations when dealing with object-centric processes. As such, these
event log formats would store the relevant object-object relations with each
event together with all their attributes having the side-effect of causing
scalability issues with these formats. To solve these scalability issues,
Object-Centric Event Logs (OCEL) were introduced [13]. An OCEL log stores the
various objects and their attributes separately from the business process
events whilst linking objects to events with the use of foreign keys. In [25],
the authors propose an algorithm to convert XES logs to OCEL logs. Even though
OCEL addressed the issue of scalability, certain aspects regarding object-
attribute allocation were not implemented due to design choices. For example,
in OCEL, it is not possible to unequivocally know which attribute belongs to
which object when stored in the events table, making attribute value changes
or even batch attribute value changes difficult to track [15]. These issues
have been addressed with the proposal of a Data-Aware Object Centric Event Log
(DOCEL) where a distinction is made between static and dynamic attributes
[15]. Static attributes are attributes belonging to an object that do not
change over the course of a process execution whilst dynamic attributes are
attributes that can change value over the course of the process execution and
are assigned to both an event and an object [15]. In [16], an algorithm is
proposed to convert OCEL to DOCEL.

With object-centric processes having multiple object types, new precision and
fitness conformance metrics were proposed in [3] and process performance
measures in [10]. With the concept of cases and traces of traditional process
mining not being valid anymore for object-centric process mining, the study in
[2] uses graph isomorphism to introduce a similar case concept usable for
object-centric processes. In [1], a framework to encode object-centric
features using tabular, sequential and graph-based encodings is introduced.
Next, an approach to filter and sample object-centric event logs is laid out
in [5]. Object-centric process discovery was analyzed to discover Object-
Centric Petri Nets [29] and Object-Centric Directly-Follows Multigraphs [6]
respectively. To reduce the complexity of the discovered process models, the
study in [12] clusters similar objects in the object-centric event logs whilst
the study conducted in [9] also identifies interacting objects of different
object types. In summary, the study in [11] shows that incorporating object-
interactions into object-centric predictive analysis improves performance,
highlighting the importance of adapting single object type algorithms for this
context.

The discovery of decisions from object-centric event logs is not
straightforward as it requires correctly matching activities with decisions as
well as correctly identifying which attributes are used within the decision-
making process. Next to that, it is crucial that the correct objects and
object types are linked together. Finally, all this information is spread over
multiple events which need to be analyzed in a control-flow conforming manner.
In short, even though the variables are linked to the objects, this increase
in dimensions also increases the complexity of the problem.

Currently, the discovery of decisions and their logic within object-centric
processes have not been researched yet.

###  2.2 Decision mining with traditional process logs

Decision mining with single point of view logs has been researched before with
the emphasis on decision point analysis. Decision point analysis aims at
discovering gateways in a process where the routing of a case depends on the
outcome of a certain decision [26]. Discovering complete DMN models with
multiple decision levels is different though and implies discovering when
decision variables are introduced or derived in the process and how these
relate to one another. This analysis reduces the complexity of the process
model as the decision logic is now separated from the process logic [7]. Works
that focus on both control flow and decision analysis simultaneously to
discover DMN models are not very prevalent. In [4], an approach to find DMN
models from traditional event logs is proposed using decision trees. However,
the approach is not capable of dealing with loops, nor can the discovered DMN
model be linked to the business process making that the control flow and
decision logic are still intertwined which is in conflict with the principle
of separation of concerns[7]. A DMN discovery algorithm has been proposed in
[8] which is compliant with the principle of separation of concerns. The
previous algorithms were developed for XES logs and are not directly usable
within an object-centric context. Lastly, a broader overview of the decision
mining field and its future from other sources such as textual descriptions
can be found in the following studies [21, 33, 8].

An important remark is that due to the dimension reduction taking place from
object-centric logs to single object point of view logs, there is a loss of
information taking place such that certain object relations might be lost or
certain activity orders are not correct anymore making that the complete
decision might not be discoverable anymore due to the convergence and
divergence issues where for example a luggage might not be traced back to the
correct traveler anymore or that it might be unclear on which luggage was put
in first in an airplane. The other way around where single object point of
view logs are combined to create object-centric process logs will not generate
more information given that the dimension reduction already took place and as
such already reduced the available information. Another point of view is that
if a decision contains multiple objects, these need to be stored together to
be analyzed together. Therefore, there is a need for a native object-centric
decision discovery algorithm that is developed for an object-centric event log
format.

##  3 Problem Illustration

This section introduces a knowledge-intensive process dealing with a
publication process to illustrate the problem. Next, the research goals are
laid out.

###  3.1 Running Example

The problem is illustrated with a knowledge-intensive publication process of a
book. The DMN model driving the business process is shown in Figure 1 and the
BPMN model is shown in Figure 2. The process is considered as the
representation of the system generating object-centric event logs in which
various decisions are embedded. Note that this first running example has a
linear control flow for simplicity, but the second running example contains
more gateways and loops. The first running example contains three different
object types: Author, Book and Publisher with the following attributes:

  * 1.

Author: Name, Author Specialty Genre, Total number of published books

  * 2.

Book: Genre, Number of pages, Publication status, Review Score, Quality,
Compliance with the publisher requirements

  * 3.

Publisher: Name, Publisher Specialty Genre

Figure 1: DMN model of the running example

Book publication process and decision: Each author has already published a
number of books in the past. This is considered to be available information at
the start of the process. The process is initialized by an author who first
has to prepare a manuscript and then writes a book. Afterwards, the author
submits their book manuscript to a publisher which sets the publication status
of that book to pending. Next, the book manuscript is received by the
publisher and the publisher will read the manuscript details. The activity
Read manuscript details will check whether the book complies with the
publisher requirements. Next, this process takes the assumption that every
submitted book is entitled to be read in more detail after which a reviewer
score is given at the end of activity Read manuscript. The DRD (a Decision
Requirements Diagram visualizes the general structure of a decision, see
Section 4 for a more detailed explanation) of Figure 1 shows that a Book’s
Quality is determined by the reviewer score and by the amount of books an
author has published in the past. For example, the decision table of Book’s
Quality shows that if an author has published 5 books in the past and the
reviewer gives a score of 4 then the Book’s Quality is considered to be
average. This decision is executed by activity Determine book quality.
Finally, a publication decision is made by the publisher by taking into
account the Book’s Quality and the compliance of publisher requirements in
activity Decide on publication. This is then communicated to the author which
ends the process.

Figure 2: BPMN model of the running example

For this study, DOCEL logs are deemed more suitable to capture knowledge-
intensive processes as they unambiguously link attribute value changes to the
correct objects and events with the use of foreign keys. A snippet of a DOCEL
log applied to this running example is shown in Tables 1, 3 and 3. The objects
tables of the Author and Book object types are similar to the Publisher object
table. Given a DOCEL log of the running example, the aim of this research is
to discover:

  * 1.

the DRD graph of Figure 1 so as to know how the decisions driving the process
are structured.

  * 2.

the decision logic driving each subdecision, i.e. discovering the logic of the
decisions Book’s Quality and Publish or not (see Figure 1).

  * 3.

Discovering which activity in the business process alters and introduces the
variables needed to make a decision, e.g., activity Read manuscript creates
the Reviewer Score and activity Decide on publication alters the variable
Publication status.

  * 4.

Discovering to which objects which variables belong to, e.g., Total number of
published books belongs to the object type Author whilst the variable Review
Score belongs to the object type Book.

Table 1: Snippet of DOCEL Event Table

EID | Activity | Timestamp | Authors | Books | Publishers
---|---|---|---|---|---
e1 | Find inspiration | 2022-01-01 10:53:45 | a951 |  |
e2 | Find inspiration | 2022-01-01 10:59:42 | a155 |  |
e3 | Write book | 2022-01-01 11:00:30 | a951 | b2 |
e4 | Submit book manuscript | 2022-01-01 11:08:23 | a951 | b2 | p90
es | Write book | 2022-01-01 11:08:32 | a155 | b3 |
e6 | Read manuscript details | 2022-01-01 11:17:26 |  | b2 | p90
e7 | Submit book manuscript | 2022-01-01 11:18:13 | a155 | b3 | p86
e8 | Read manuscript details | 2022-01-01 11:22:06 |  | b3 | p86
e9 | Read manuscript | 2022-01-01 11:27:06 |  | b2 | p90
e10 | Read manuscript | 2022-01-01 11:31:22 |  | b3 | p86
e11 | Determine book quality | 2022-01-01 11:36:09 | a951 | b2 | p90
e12 | Determine book quality | 2022-01-01 11:36:51 | a155 | b3 | p86
e13 | Decide on publication | 2022-01-01 11:38:02 |  | b3 | p86

Table 2: Snippet of DOCEL Publisher Object Table PID | Name |  | Publisher
---
Specialty Genre
p44 |  | Source Industries
---
Universal Publishing
Romance
p86 |  | Telecom
---
Electronics Publishing
Romance
p90 |  | Studio West
---
Software Publishing
Fantasy

Table 3: Snippet DOCEL Publication Status Table PSID | Publication Status | EID | BID
---|---|---|---
ps1 | Pending | e19 | b1
ps2 | No | e23 | b1
ps3 | Pending | e4 | b2
ps4 | Yes | e14 | b2
ps5 | Pending | e7 | b3
ps6 | Revise | e13 | b3

###  3.2 Problem Statement

With a knowledge-intensive process log, discovering decisions can help
decision-makers understand how these are executed in the business process.
This way processes and decisions can be changed and analyzed independently of
one another [18]. Additionally, linking decisions to the control flow provides
a holistic view of the process, showing when decision-related activities
occur.

Just as it is valuable to discover multiple object types and variables in a
process [31], it is also important to identify the object types and variables
involved in decision-making process. However, this information is not stored
in single-case process event logs such as XES logs and can therefore not be
discovered in such logs. Secondly, the only other holistic decision discovery
algorithm [8] is not applicable to an object-centric process log as it was
designed with a single process point of view in mind. Lastly, currently the
main object-centric process discovery algorithms focus on the control flow
without decision information [29, 6]. In short, given an object-centric event
log, the goal of this research is to:

  1. 1.

Discover which activities introduce decision-relevant variables and executing
decisions.

  2. 2.

Discover to which object types the relevant input variables belong to. As
such, the object types are also connected to the activities in which they
participate.

  3. 3.

Discover a DMN model for the discovered decisions with both the decision
structure and decision logic.

##  4 Preliminaries

This section first introduces the terminology relevant for the proposed
algorithm, next DMN and its terminology are explained.

###  4.1 Object-Centric Processes

######  Definition 1.

(Data-aware Object-Centric Event Log). A data-aware object-centric event log
is a tuple
$L=(E,OT,O,A,AT,AV,\pi_{ot},\pi^{o}_{at},\pi_{id},\pi_{a},\pi^{e}_{at},\pi_{t},\pi_{o},\pi_{av},\pi^{e,o}_{at})$:

  * 1.

$E$ is the set of events, $OT$ is the set of object types (e.g., {Author,
Publisher,Book}), $O$ is the set of objects, $A$ is the set of activities,
$AT$ is the set of attributes, $AV$ is the set of attribute values.

  * 2.

Each $o_{i}\in O$ is a tuple $o_{i}=(oid,ot_{i},AT_{i})$ where:

    * (a)

$oid$ is a unique object identifier (e.g., {p44,p90,a951,b2}).

    * (b)

$\pi_{ot}(o_{i})=ot_{i}$ assigns the object to an object type (e.g.,
$\pi_{ot}($p44$)=$Publisher).

    * (c)

$\pi^{o}_{at}(o_{i})=AT_{i}$ assigns a subset of attributes to an object with
$AT_{i}\subseteq AT$ (e.g., $\pi^{o}_{at}($p44$)=$ {Name, Publisher Specialty
Genre}).

  * 3.

Each attribute $at_{i}\in AT$ is assigned a value $\pi_{av}(at_{i})=av\in AV$.
This allows us to obtain the values of attributes of events and objects:

    * (a)

$\pi_{av}(\pi^{e}_{at}(e_{i}))=av$ for static event attributes.

    * (b)

$\pi_{av}(\pi^{o}_{at}(o_{i}))=av$ for static object attributes (e.g.,
$\pi_{av}(\pi^{o}_{at}($p44$))=$ {Source Industries Universal Publishing,
Romance}).

    * (c)

$\pi_{av}(\pi^{e,o}_{at}(e_{i},o_{i}))=av$ for dynamic attributes (e.g.,
$\pi_{av}(\pi^{e,o}_{at}(e_{19},\texttt{b1}))=$ Pending) which are the sets of
attributes that have been changed by an event belonging to an object.

  * 4.

Each event $e_{i}\in E$ is a tuple $e_{i}=(id_{i},a_{i},at_{i},t_{i},o)$ where
$a_{i}\in A$ is an activity, $at_{i}\subseteq AT$ a set of attributes,
$t_{i}\in\mathbb{N}$ a timestamp, $o\subseteq O$ a set of objects. We write:

    * (a)

$\pi_{id}(e_{i})=id_{i}$ assigns a unique ID to each event. (e.g.
$\pi_{id}(e_{1})=e_{1}$).

    * (b)

$\pi^{e}_{at}(e_{i})=at_{i}$ assigns attributes to events (e.g.,
$\pi^{e}_{at}(e_{1})=$ resource).

    * (c)

$\pi_{a}(e_{i})=a_{i}$ assigns an activity to each event (e.g.,
$\pi_{a}(e_{1})=$ Find inspiration).

    * (d)

$\pi_{t}(e_{i})=t_{i}$ assigns a timestamp to each event (e.g.,
$\pi_{t}(e_{1})=2022{-}01{-}01$ $10{:}53{:}45$).

    * (e)

$\pi_{o}(e_{i})=o$ assigns a set of objects to each event (e.g.,
$\pi_{o}(e_{1})=$a951).

###  4.2 DMN

DMN and its corresponding models were introduced in 2015 by the Object
Management Group (OMG) as a Decision Model and Notation standard to model,
communicate and execute operational decisions [24]. Figure 1 shows a DMN model
dealing with whether or not to publish a book. Every DMN model consists of two
parts, one part visualizes the structure of a decision (left side of Figure
1), the other part represents the decision logic (right side of Figure 1).

To represent the decision structure, DMN uses Decision Requirement Diagrams
(DRD) where a decision such as Publish or not or Book’s Quality is represented
with rectangles whilst the inputs of decisions such as Author’s number of
published books are represented with rounded rectangles. Inputs and decisions
are connected with solid arrows which are also called information
requirements. Finally, it is possible for the output of a decision to be used
as an input for another decision, e.g., the output of Book’s Quality is used
as input for decision Publish or not. The following terminology is introduced:

######  Definition 2.

Below we provide the relevant definitions for a DMN model.

  * 1.

$D$ is the universe of decisions and $d$ is a tuple defined as
$d=(I_{d},O_{d},a_{d},\pi_{adec},\pi_{out})$ with:

    * (a)

$I_{d}\subseteq AT$, the input variables (e.g. Reviewer Score, Author’s number
of published books are inputs of Book’s Quality).

    * (b)

$O_{d}\subseteq AT$, the output variables (e.g., Book’s Quality is the output
of the decision Book’s Quality)

    * (c)

$a_{d}\in A$, the activity executing the decision (e.g., Determine book
quality executes the decision Book’s Quality).

    * (d)

$\pi_{adec}:A_{d}\rightarrow D$ is the function associating an activity to a
decision (e.g. $\pi_{adec}:\texttt{Determine book
quality}\rightarrow\texttt{Book's Quality}$). Every decision needs to be
linked to maximum one activity but not each activity needs to be linked to a
decision.

    * (e)

$\pi_{out}:2^{AT}\rightarrow AT$ is a function producing an output variable
taking as input the input variables (e.g. $\pi_{out}:$ {Reviewer Score,
Author’s number of published books} $\rightarrow$ Book’s Quality with a
possible rule: if Total number of published books $<$ 5 and Reviewer Score in
[0..5] then Book’s Quality = Bad.)

  * 2.

A DRD is defined as a tuple with $DRD=(D_{drd},I_{drd},R_{drd})$ with:
$D_{drd}\in D$ all the decisions in the DRD, $I_{drd}\in AT$ all the input
variables of $D_{drd}$, $R_{drd}:(I_{drd}\times D_{drd})\cup(D_{drd}\times
D_{drd}$) the connection between the inputs or intermediary decisions with the
decisions to one another.

The decision logic can be represented with decision tables in DMN as they
allow for consistency, correctness and completeness of decision rules [34].
Each rule in a decision table is read as an IF-THEN statement, e.g., in the
decision table Publish or not, the third rule must be read as: If Book’s
Quality is average and if Complying with Publisher requirements is true, then
the Publication Decision is revise. A complete overview of DMN specifications
can be found in [24].

##  5 IODDA Algorithm

This section introduces the Integrated Object-centric and Decision Discovery
Algorithm (IODDA), which aims to uncover decisions in an event log. IODDA is a
three-step algorithm following the general idea of any data analysis project
namely: pre-processing, analysis, and post-processing. The general steps of
IODDA are:

  * 1.

Step 1 (Pre-processing): For each activity discover a set of potential input
variables ($I_{d}$) and potential output variables ($O_{d}$) belonging to the
relevant object types. This step is important as it delineates the relevant
dimensions in which IODDA will have to perform a more in-depth analysis. The
pre-processing step is broadly responsible for solving research goal 1.

  * 2.

Step 2 (Analysis): Determine with a correlation metric value $C$ which
variables are used as inputs by activities that change the values of output
variables. Next, for each potential input-output combination, a prediction
model is built. In this step, IODDA builds a proxy model $L$ for
$\pi_{out}:AT\rightarrow AT$ which is supported with a sufficiently high value
of correlation metric $C$. This second step completely solves research goal 2
and for research goal 3, it builds candidate DMN models with their structure
and logic.

  * 3.

Step 3 (Post-processing): Since the previous step might discover decision
models which overlap with one another because it analyzes different objects
without always taking into account what is already discovered, this step
ensures that the information is consolidated in fewer but completer decision
models. The last step finalizes research goal 3 by creating final DMN models.

Before IODDA is explained in further detail, a key underpinning concept of
this algorithm called a shift is introduced.

######  Definition 3.

A shift is a function $\sigma^{at,a}_{o}=AT\times A\times O\to E$ capturing
all the events of an activity $a$ changing an attribute $at$ of object $o$.
e.g., $\sigma^{PublicationStatus,Decideonpublication}_{b3}=e_{13}$.

To refer to an individual shift function, the rest of the paper also refers to
them as Attribute-Activity-Object_Type shift (ATAOTSs), e.g., (Publication
Status, Decide on publication, Book,2)-shift refers to the idea that the
activity Decide on publication modified the attribute Publication Status of
object type Book for the second time.

Similarly $\sigma_{o}=O\to E$ captures all events in which object $o$ is
present. This shift concept is created the first time the IODDA algorithm goes
through a DOCEL log. This allows for an efficient analysis in the remaining of
the algorithm as otherwise IODDA would have to go through the entire object-
centric log multiple times in search of the same information. Finally, within
the context of IODDA, a discovered DRD has to be defined as follows:

######  Definition 4.

$\textit{D}RD_{disc}=(D_{drd},I_{drd},R,L,C,T_{{at}_{o}})$ where $D_{drd}$ and
$I_{drd}$ denote ATAOTS with n shifts. $R$ represents input-output edges, $L$
is the predictive model, $C$ signifies input-output correlation, and
$T_{at_{o}}$ represents relevant attribute-activity-object shifts.

###  5.1 Step 1: Discovering potential input and output variables

In the initial phase of IODDA, it identifies potential input and output
variables for each activity. These input variables are then placed into
potential decision models for further analysis if they have a potential impact
on the output variable.

In more detail, the algorithm is initialized with an empty set $DRD$ and
$\sigma^{at,a}_{o}=\emptyset$ an empty set of attribute-activity-object
shifts.

Next, in lines 4-12, all objects of all object types are analyzed with the
assumption that the first event in which an object appears also creates its
static attributes $AT^{static}_{o}$ (lines 7-9). For the dynamic attributes
$AT^{dynamic}_{o}$, the algorithm creates a shift function,
$\sigma^{at_{dynamic},a}_{o}$, returning the events for each (activity,
attribute)-combination if the currently analyzed event also changed the value
of the dynamic attribute (lines 10-12).

Once all the ATAOTSs have been identified and $\sigma^{at,a}_{o}$ is complete,
lines 13-20 identify for each activity a set of potential input and output
variables of all object types of that activity. A variable is considered a
potential input variable of an activity if it has more than one distinct
value. Next, to qualify as an output variable two conditions are checked:

  1. 1.

the variable has more than one distinct value.

  2. 2.

the variable must be shifted a minimum number of times relative to the number
of objects of a specific type across all activity executions. This minimum
shift threshold is determined by the parameter called $\underline{minShift}$.
For example, if 10 events modify a variable for 10 different objects of type
Book during an activity, and $\underline{minShift}=0.2$ then if there are a
total of 20 books, it is considered significant because more than 20% of all
Book objects were modified. However, if there are 200 books, it’s not
significant as less than 20% of the books were affected, and IODDA does not
identify it as a potential output variable for the activity.

This last criterion ensures that only attributes with sufficient value changes
($>\underline{minShift}$) are considered as output variables for an activity.
A further discussion on hyperparameter sensitivity can be found in Section 8.

Finally, lines 21-25 analyze all discovered shifts and store these together in
$T_{at_{o}}$ consisting of (activity, attribute, number of shifts). Each
ATAOTS is then proposed as a top node of a new DRD. Subsequently, the
algorithm proceeds with the recursive Find all input variables algorithm to
identify all input variables associated with the top decision. Finally, any
duplicate DRDs are eliminated, and only the unique DRDs are returned as the
output of the algorithm. The object-centric aspect in this first part is
mainly manifested by the extra loops the algorithm performs for each object
type to discover the shifts. Secondly, all the shifts are enriched with their
object type information which is necessary information later on to correctly
visualize the DRDs.

Algorithm 1 Discovering potential input and output variables

1:procedure MINE_DMN_MOD($\mathcal{L}$)

2: DRD $\leftarrow\emptyset$ $\triangleright$ DRD used as global variable
throughout algorithms

3: $\sigma^{at,a}_{o}\leftarrow\langle\rangle$, $\forall(at,a,o,e)\in(AT\times
A\times O)\to E$

4: for $ot\in OT_{\mathcal{L}}$ do $\triangleright$ All object types in the
log

5: for $o\in ot$ do

6: for $e_{t}\in\sigma_{o}$ do $\triangleright$ All events object o is
involved in

7: if $e_{t-1}=\emptyset$ then

8: for $at\in AT^{static}_{o}$ do

9: $\sigma^{at_{static}}_{o}\leftarrow e_{t}$ $\triangleright$ add all static
attributes of o to shift

10: for $at\in AT^{dynamic}_{o}$ do $\triangleright$ All dynamic variables of
object

11: if $e_{at}=e_{t}$ and $o_{at}=o$ then

12: $\sigma^{at_{dynamic},a}_{o}\leftarrow e_{t}$ $\triangleright$ add the
dynamic attributes of o to shift

13: for $ot\in OT_{\mathcal{L}}$ do

14: for $o\in ot$ do

15: for $at\in AT_{o}$ do

16: for $a\in A$ do

17: if $|\\{val_{at}(\sigma)|\sigma\in\Sigma^{at,a}_{o}|>1$ then
$\triangleright$ The variable is discriminative

18: if $|\sigma^{at,a}_{o}|>\underline{minShift}\cdot|ot|$ then
$\triangleright$ enough shifts occurred for ATAOTS

19: $O_{a}\leftarrow O_{a}\cup at$

20: $I_{a}\leftarrow I_{a}\cup at$

21: for $ot\in OT_{\mathcal{L}}$ do $\triangleright$ Find all inputs set by
other prior activities

22: for $(at,a,ot,n)\in\\{(at,a,ot,n)\in AT\times A\times
OT\times\mathbb{N}|\sigma^{at,a}_{o}\neq\emptyset\wedge
n\in[1,\underline{maxShift_{o}}]\\}$ do

23:
$T_{at_{o}}\leftarrow\\{\sigma|\sigma^{at,a}_{\sigma_{o},n}\neq\emptyset\\}$
$\triangleright$ All object traces with at least n shifts

24: $\textit{DRD}\leftarrow\textit{drd}=(D\cup
d=(at,a,ot,n),I_{drd},R,L,C,T_{v_{o}})$

25: Find input variables$(at,a,ot,n,drd)$

26: $\textit{DRD}\leftarrow$ eliminate duplicates$(\textit{DRD})$

27: return DRD

###  5.2 Step 2: Building decision models

Algorithm 2 Building decision models

1:procedure Find Input
variables($d=(at,a,ot_{i},n),drd=(D,R,L,C,T_{{at}_{o}})$)

2: $M,D_{2}\leftarrow\emptyset$

3: $\textit{ATAOTS}\leftarrow\\{(at_{2},a_{2},ot_{2})\in AT\times A\times
OT)|at_{2}\in I_{d}\wedge at_{2}\in\\{at|at\in O_{a_{2}}\\}\\}$

4: for $(at_{2},a_{2},ot_{2})\in ATAOTS$ do

5: for $d_{2}=(at_{2},a_{2},ot_{2},n_{2})\in\\{(at_{2},a_{2},ot_{2},n_{2})\in
AT\times A\times
OT\times\mathbb{N}|\sigma^{at_{2},a_{2}}_{o_{2}}\neq\emptyset\wedge
n_{2}\in[1,\underline{maxShift}]\\}$ do

6: $val_{at},val_{at_{2}},T\leftarrow\emptyset$

7: for $\sigma\in T_{{at}_{o}}$ do $\triangleright$ Loop over all object
traces of the top activity

8: if $o_{2}\in a\wedge at_{2}\in
AT_{o_{2}}\wedge\sigma^{at_{2},a_{2}}_{o_{2},n_{2}}<\sigma^{at,a}_{o,n}$ then

9: $val_{at}\leftarrow val_{at}\cup
val_{at}(\sigma^{at,a}_{o,n}),val_{{at}_{2}}\leftarrow val_{{at}_{2}}\cup
val_{{at}_{2}}(\sigma^{at_{2},a_{2}}_{o_{2},n_{2}}),T\leftarrow T\cup\sigma$

10: if $|T|>|OT_{i}|\cdot\underline{minTraceprop}\wedge
corr(val_{at},val_{{at}_{2}})>\underline{minCorr}$ then

11: $D2\leftarrow d_{2}$

12: $M\leftarrow(d_{2},T)$

13: $C(d,d_{2})\leftarrow cor(val_{at},val_{{at}_{2}})$

14: Sort(M)

15: for $(D_{2},T)\in$ Find input models(M) do

16: $L(D_{2},at)\leftarrow$ Build predictive model($D_{2},at,T$)

17: if $L(D_{2},at)>\underline{minSupport}$ then

18: for $d_{2}\in D_{2}$ do

19: $D\leftarrow d_{2}$

20: $R\leftarrow(d_{2},d)$

21: if $T=T_{{at}_{o}}$ then

22: Find input variables($o_{d_{2}},a_{d_{2}},OT_{2},n_{d_{2}},drd$)

23: else$\triangleright$ Other object trace cluster requires different model
to be built

24: re-estimate $C$ for $T$ and adjust $R$ accordingly to obtain $C_{n}$,
$R_{n}$

25: $DRD\leftarrow drd_{n}=(D,R_{n},L,C_{n},T)$

26: Find input variables$(o_{d_{2}},a_{d_{2}},OT_{2},n_{d_{2}},drd_{n})$

27: return $(D,R)$

The second part develops candidate models by recursively discovering which
candidate input variables are sufficiently correlated with their candidate
output variables across all present object types. In this part, it is
important to correctly link the involved objects of different object traces to
one another otherwise the algorithm might incorrectly link attribute values to
unrelated objects and as such discover wrong object-object relationship maybe
leading to wrong decision models later on.

In lines 2-3, the algorithm initializes three key components: the empty set of
decision models $M$, the empty set of potential input variables for the top
node namely $D_{2}$, and a set of relevant ATAOTSs. An ATAOTS is considered
relevant if the associated variable serves as an input to the top node
activity $a$ and as an output of the activity $a_{2}$ of the potential input
variable.

Lines 4-9 identify which object traces experienced shifts that subsequently
influence the variables of the top decision. By employing backward reasoning
on the top activity, the algorithm checks for each involved object in the top
decision activity whether any object input variable was created or altered
before the top activity alters the output variable. If such a case is found,
the set of values are respectively stored in $val_{at}$ and $val_{{at}_{2}}$
and the relevant object traces are stored in T. The parameter
$\underline{maxShift}$ allows to determine how many times a potential input
variable may have been changed in the past to be considered relevant for
further analysis. This allows for a more flexible analysis on various process
logs.

Proceeding to lines 10-14, the algorithm first checks if the number of object
traces in $T$ for which the potential input variable was changed or created
before the output variable exceeds a predetermined value (minTraceprop)
relative to the total number of objects of the corresponding object type to
which the output variable belongs to. This mirrors the concept of minShift in
identifying significant input variables compared to the object population.
Next, it checks if the correlation between the top decision (output variable)
and the potential input variable exceeds a set threshold (minCorr). If both
criteria are met, the potential input variable, traces, and correlation are
stored. Next, the proposed models are ranked based on decreasing number of
covered object traces. The algorithm uses mutual regression and classification
information as proxies for determining variable correlations [23]. However,
IODDA can work with any inference technique and thus also with causal machine
learning techniques such as uplift trees [27]. IODDA has a plug and play
mechanism regarding inference techniques and can serve as a basic structure
which can be further used with causal graphs. However, DMN tables do not aim
to contain causal rules. Moreover, it is not guaranteed that a certain change
can solely be attributed to an individual variable if it is part of a rule
with multiple variables. Therefore, we use the correlation metric as proxy to
extract decision rules which in turn need to be validated by experts.

Continuing to lines 15-27, the algorithm builds a predictive model L using the
corresponding potential input variables, the object traces and the top
decision. Random forests are employed in this case due to their robustness,
and performance, although alternative predictive models could be utilized such
as XGBoost or neural networks. The predictive model’s binary accuracy is
evaluated, and if it surpasses a defined threshold minSupport, the algorithm
proceeds to recursively identify further potential input variables of the
newly determined input variable $D_{2}$.

If the object traces of the input decision do not completely overlap with the
object traces of the top node, the algorithm recalculates correlations and
edges for overlapping traces of both the input and output variables before
proceeding with the recursive search for new input variables. This aspect is
especially important in an object-centric context where the total number of
objects can vary between object types. Because of this objects can participate
in the decision-making of various other objects belonging to other object
types. This makes that not all object traces are only linked to a single other
object trace, it is therefore important to know how and which objects are
related to one another otherwise certain variables might receive too much or
too little importance because of an incorrect object-object relationship
analysis. Ultimately, the algorithm returns all decisions and their associated
edges, providing a comprehensive output for further analysis.

###  5.3 Algorithm 3: Finding all overlapping models

Algorithm 3 Finding all overlapping models

1:procedure Find input models($M$) $\triangleright$ M: set of potential models

2: $models\leftarrow\emptyset$ $\triangleright$ Generated models

3: $cov\leftarrow\emptyset$ $\triangleright$ Covered object traces

4: for $((at,a,OT,n),T)\in M$ do

5: for $(D,T_{m})\in models$ do $\triangleright$ Check all possible input
models

6: if $T=T_{m}$ then $\triangleright$ If traces are the same, add to model

7: $D\leftarrow\cup(at,a,OT,n)$

8: else if $T\subset T_{m}\wedge|T|>OT\cdot\underline{minTraceprop}$ then

9: $models\leftarrow(D\cup(at,a,OT,n),T)$

10: else if $T\cup T_{m}\neq\emptyset\wedge\frac{|T\cup
T_{m}|}{|T|}>\underline{minDev}$ then

11: $models\leftarrow(D\cup(at,a,OT,n),T\setminus T_{m})$

12: $cov\leftarrow T$

13: if $T\subsetneq cov\wedge|T|>OT\cdot\underline{minTraceprop}$ then

14: $models\leftarrow((at,a,n),T)$

15: $cov\leftarrow T$

16: return $models$

IODDA’s final part ensures that the discovered models are combined
effectively, taking into account the proportional coverage of object traces
relative to the total number of relevant object traces and the compatibility
of variables. Again, this is tied to object traces influencing other types and
certain variables being vital to object types due to their relative importance
rather than sheer quantity. By examining various overlapping object trace
scenarios and applying preset thresholds, the model includes all relevant
input variables while preserving predictive power and model coherence.

The algorithm loops over all ATAOTSs that have been identified as potential
output variables or top decisions previously. The initialization of a model
occurs when enough object traces are covered proportionally to the total
number of that object type as determined by the minTraceprop parameter. Each
potential model is stored in the models set and the object traces covered by
the model are added to the cov sets, as outlined in lines 13-15.

In lines 5-12, the algorithm evaluates each potential input variable’s
compatibility with the existing model. Three scenarios are considered. First,
if the input variable’s covered object traces fully match the current overall
model, it is incorporated into the model as an input variable of the top
decision, as shown in lines 6-7. Secondly, if the covered traces of the input
variable partially overlap with its belonging output variable but cover
sufficient object traces in proportion to the object type determined by
minTraceprop, the input variable is included (lines 8-9). Lastly, if two sets
of object traces do not entirely overlap with the same objects but are similar
enough determined by minDev, meaning they can be traced back to common
objects, the input variable is still added to the combined model if it adds
enough predictive power (lines 10-12).

##  6 Artificial DOCEL log generators

Public OCEL logs lack descriptions of decision-making processes, and there are
currently no publicly available DOCEL logs detailing decisions. To support
future research in object-centric process analysis, two knowledge-intensive
object-centric DOCEL process log generators were developed. The first process
corresponds to the publication process in Section 3, while the second pertains
to the order shipping method described in the next section. Each log generator
allows customization of parameters to produce logs with varying behaviors.

###  6.1 Shipping Method Example

A second problem is introduced dealing with an order-shipping method process
inspired by the process described in [8]. The BPMN model can be found on the
GitHub page111https://github.com/Goossens496/IODDA.git and the corresponding
DMN model is shown in Figure 3.

The process contains three object types, i.e., customer, order and product
type. Depending on a variety of variables such as the order value, the
importance of a customer, and whether or not the customer has requested a
refund, a different shipping method is used. A textual description of the
process is provided below in italics.

A customer has been assigned an importance level by the company in the past.
The process starts with a customer ordering a certain amount of a product.
This is then received by the company which determines the value of the order.
Once all the shipping information has been confirmed, the shipping method is
determined based on the importance of a customer, the value of the order and
on whether the customer has asked for a refund. At the same time, the invoice
is send. Once the package has been delivered, the customer is either satisfied
or not. If the customer is satisfied, the order is filed and the process ends.
Otherwise, a refund is asked and the package is sent back with an express
courier. Once the refund has been paid and the package has been successfully
delivered, the process is finished.

Figure 3: Shipping Method DMN model

The decision logic is shown in Figure 3. The order value is determined by
multiplying the quantity with the product value. The shipping method is
determined by the Determine Shipping Method Table. In short, if a customer
requests a refund, the shipping method is Express Courrier. If a customer is
considered important or the order value $>=100$ then the shipping method is
Courrier, otherwise the shipping method is Mail.

###  6.2 Artificial Log Generators

To promote reproducibility and support the research community, the artificial
logs, DOCEL log generators, IODDA Python implementation, and complete BPMN
model figures are made available and can be found on the GitHub page. The
artificial log generators are provided as Jupyter Notebooks with global
parameters. Tables 4 and 5 show the editable parameters. The decision logic
and thresholds in both log generators can be readily adjusted, allowing
customization of event and decision outcome distribution to suit specific
research requirements. The DOCEL logs themselves are exported to a common
spreadsheet format with each sheet representing the events, object or dynamic
attributes table.

Table 4: Summary of Functionality in the Publication Process Log Generator

Tunable parameters Description of Functionality Maximum number of Authors
Enables creating new authors with a random number of published books, random
genre in which the author is specialized and a random name. Max published
books Maximum number of published books an author can have. Genre list List of
potential genres in which an author or publisher can be specialized in.
Maximum number of Publishers Enables creating new publishers with a random
company name and a specialized genre. Number of Books Determines how many
books will be written over the course of the simulation. Start Timeframe
Allows defining the start time for the process. Time interval Between Events
Allows adjusting the time interval between consecutive events. Probability of
Publisher Compliance Can be adapted to determine the likelihood of a book
meeting the initial publisher requirements. The lower the value the more
likely a book is compliant. Publication threshold Determines how many prior
publication an author should have in the decision of the quality of submitted
book.

Table 5: Summary of Functionality in the Shipping Method Log Generator

Tunable parameters Description of Functionality Product Value Allows changing
the value of the product. Number of Customers Enables creating new customers
with randomly generated names, random belgian bank accounts and randomly
assigned importance values (High or Low). Lists of People Executing Activities
Allows adapting the lists of people who execute the company’s activities.
Start Timeframe Allows defining the start time for the process. Time interval
Between Events Allows adjusting the time interval between consecutive events.
Order Value Threshold Can be changed to determine the shipping method based on
the order’s value. Number of Orders Can be changed to generate logs with
varying numbers of orders. Probability of Refund Can be adapted to determine
the likelihood of a refund, indicating customer satisfaction with the
purchase. The higher the value the more satisfied the customer is. Maximum
order quantity Influences how many product units a customer can buy in one
order.

##  7 IODDA Implementation and Demonstration

The IODDA algorithm is available in Python, along with the log generators on
the GitHub page. It has been tested on both artificial DOCEL logs with their
specific information regarding number of events, objects, average number of
objects per event and attributes described in Table 6. Given that the
algorithm is demonstrated using artificial logs, the ground truth is the logic
driving the simulation in the artificial log generators which is defined by
the user in this case. However, this does not have to be the case in a real-
world application where the logic is simply part of the object-centric log.
The main challenge of these logs, besides discovering the decisions, is to
also correctly uncover the interactions among objects within and across
events.

Given that in this study decision trees are built based on the event log these
can be considered to be complete and unique for the analyzed objects and valid
for the analyzed event log.

The discovered DRDs and decision trees are reported in the following
subsections.

Table 6: Event log information

| Publication Process | Shipping Method Process
---|---|---
#Events | 800 | 1596
#Object Types | 3 | 3
#Objects | 299 | 151
AVG(#Objects/#Events) | 2.25 | 1.86
#Attributes | 11 | 9

The Python implementation’s generated DRDs include object-centric and control
flow details. It specifies the object type associated with the decision’s
variable and the influencing activity. Next, for each relationship between
decision elements it is indicated for how many objects this relationship has
been observed. Note that the variable names are indicated with Name_shift-x.
For example Name_shift-1, indicates that IODDA is reporting the results for
the first shift of that variable caused by an activity. For visualizing
decision logic, the algorithm employs decision trees because they are widely
used and there are more models available for training them. Before
constructing the decision tree, the accuracy of the discovered random forest
model must surpass a specific threshold. Decision trees can also be converted
into decision tables later on [28].

###  7.1 Book Problem

Figure 4 illustrates the DRD discovered by IODDA for the publication process,
revealing all decisions and relevant information needed to determine the final
publication outcome. The algorithm also correctly discovers that the variable
Review Score_shift-1 is created by the Read manuscript activity and belongs to
the Books object type. It also recognizes that, although Quality belongs to
Books, the Number of published books of the Authors object type is also
relevant in determining Quality. The numbers above the arrows indicate that
the observed relations between the variables and the decisions are valid for
all 100 authors and 100 books. The discovered DRD aligns with the ground truth
of Figure 1.

Figure 4: Discovered DRD for the book publication problem

Figures 5 and 6 show the discovered decision tree for the Quality and
Publication decisions. The decision tree for book quality (Figure 5)
accurately replicates the ground truth of Figure 1. Notably, the decision tree
suggests that review score holds greater importance in determining book
quality after considering the number of published books by an author. For
Figure 6, it is important to know that the algorithm one-hot encoded the
Quality variable as follows: 0=Average, 1=Bad, 2=Excellent. The Complaint
variable retained its binary values meaning that 0=False and 1=True. The
decision tree for book publication aligns with the ground truth in Figure 1.

Figure 5: Discovered decision tree for the quality decision Figure 6:
Discovered decision tree for the book publication decision

###  7.2 Shipping Method process

The discovered DRD for the shipping method process is shown in Fig 7. It
accurately identifies that the Importance variable belongs to the Customers
object type, while the remaining variables are from the Orders object type. It
correctly identifies that Order Value is solely determined by Quantity due to
the log containing a single product type, therefore Product Value can not
influence Order Value since Product Value is a static attribute which does not
change values within the log.

Figure 7: Discovered DRD for the shipping method problem Figure 8: Discovered
decision tree for the shipping method problem

Figure 8 visualizes the decision tree for the first shift of the shipping
method in the process. Note that the algorithm binarized the Importance
variable as follows: 0=High and 1=Low. The algorithm correctly discovers that
the Order Value threshold for an order to be send by courrier equals 100
approximately. It also correctly discovers that when Order Value is below that
threshold and that Importance equals low, the shipping method equals mail.

##  8 Discussion

The algorithm’s DRDs and decision trees reflect the decisions within a log,
which can be challenging to discover when the ground truth is absent. The
discovery of correlations plays a significant role in this process. For
instance, in Figure 4 the Review_Score_shift-1 and Quality_shift-1 are
connected to the top decision based on their significant correlation, even
though the ground truth did not make this connection. Next, the algorithm is
also sensitive to hyperparameter changes, including minShift,minTraceprop,
minCorr, minDev and minSupport. Adjusting these parameters can greatly affect
which object traces and variables are considered noteworthy for further
examination. For instance, adjusting the minShift to higher values can be
interesting for long processes where attributes are changed multiple times
over the course of the process. In case there is a suspicion that a minority
of an object type follow a specific pattern of decisions, setting the
minTraceprop to a lower value might help uncover these patterns as it allows
for variable changes of less objects to also be analyzed. Lower values for the
minCorr parameters allow to further analyze more variables even if they have a
low correlation value which is relevant in case there are complex decision
rules present which are spread across multiple variables since in that case
not all variables necessarily have a strong correlation even though they also
influence the decision. Adjusting the minDev to lower values will allow IODDA
to link more loosely connected objects to one another. Lastly, the minSupport
parameter is important to determine whether the predictive power of the model
is strong enough to include the variable as an actual input variable. In
short, lower parameter values result in the discovery of relationships that
are present in a smaller amount of object traces, however finetuning the
combination of these parameters can greatly influence what is discovered.

We will illustrate the behaviour of IODDA for varying hyperparameter values
with the use of the publication problem. Figure 9 shows the discovered DRD in
case all the hyperparameters are set to 0.3. These values generate a different
DRD with less information which can be used to illustrate the effect of
changing an individual hyperparameter value given that the rest remains set at
0.3.

Figure 9: Discovered DRD for the publication problem with all hyperparameters
set to 0.3

  * 1.

minShift: will make that an attribute is only considered for further analysis
if it has undergone enough shifts relatively to the total number of objects of
that object type. Increasing the value of minShift does not change the
discovered DRD since these relationships are valid for all books. Decreasing
the value minShift will also not change the discovered DRD, but under the hood
it will consider more object traces to be analyzed given that fewer shifts
need to have occurred before being considered for further analysis.

  * 2.

minTraceprop: Is similar to minShift but is used to select variables for the
decision models. Increasing or decreasing the value does not impact the
discovered DRD given that the object traces do not meet the requirements of
the other hyperparameters. Note that this hyperparameter is closely linked to
the minShift hyperparameters. Basically, these two hyperparameters should be
considered as pairs that need to move together.

  * 3.

minCorr: By increasing the value to 0.35, the arrow between Review
Score_shift-1 is not kept anymore because the correlation between Review
Score_shift-1 and Publication_Status_shift-1 is below that value. Above 0.35,
no DRD is discovered. When decreasing the value to 0.1, Figure 4 is discovered
as smaller correlation between variables are allowed.

  * 4.

minDev: determines how different models can be linked together by deciding how
many object traces these should have in common. If the other hyperparameters
are kept to 0.3, changing this hyperparameter does not change anything to the
discovered DRD. This makes sense given that the hyperparameter values have a
pretty high value. If the other hyperparameters such as minShift and
minTraceprop were to allow smaller clusters of object traces to be analyzed,
than the minDev parameter will allow models to be build valid for a percentage
of % objects of that object cluster more than minDev.

  * 5.

minSupport: By increasing minSupport to 0.9, no sufficiently strong predictive
model is found. Reducing the value will not change the discovered models given
that the other hyperparameters already remove smaller object clusters. Given
that we evaluate on an artificial dataset, the rules apply to all object
traces in any case therefore if one wants to find rules valid for smaller
object clusters one would have to lower the values of minShift and
minTraceprop. As a general rule given that minCorr selects individual
variables based on their correlation and given that minSupport looks at the
possible combinations of all the selected variables, setting minSupport higher
than minCorr will select models with stronger predictive power and probably
also fewer variables than the ones selected with minCorr. Setting minSupport
lower than minCorr will generate other models with smaller predictive power
but might provide also with interesting insights for the process owners.

One of the key advantages of this algorithm is its procedural nature making it
more interpretable than a pure black-box model. Practically, IODDA is valuable
in uncovering the timing and nature of decisions within various object-centric
processes. It effectively constructs a timeline, revealing when decisions were
made. In case an object-centric process log is generated with a consistent
object-event mapping hence potentially generating less variation, the IODDA
algorithm draws benefit from this by analyzing by object type making inference
between object types more manageable and scalable. IODDA can be considered a
process discovery algorithm, specifically focusing on activities that
introduce or alter variables. Whenever the ground-truth of the discovered
decisions are available, it is possible to perform conformance analysis to see
whether the prescribed decision logic is in line with what is discovered in
the object-centric process log. Even when the ground truth is not available,
it can be valuable to discover which decisions are being taken within a
process and what the logic of these decisions are.

In order to disentangle the discovered decision logic, the process owner or
domain expert can further validate the results. As such, IODDA can be used by
knowledge experts to confirm what should be happening in a process or can be
used to discover decision logic that should maybe not be allowed within the
process.

Finally, in the related work section an algorithm to discover DMN models from
traditional XES event logs is mentioned [8]. Even though both algorithms
approach the DMN model discovery problem in a similar vein, IODDA approaches
it from a multi-dimensional perspective by incorporating the existence of
multiple object types within the core of its algorithm which is not the case
for the algorithm proposed in [8]. Therefore, analyzing a flattened DOCEL log
with the algorithm in [8] will provide less insights than if the DOCEL log
were to be directly analyzed with IODDA. This can mainly be attributed to the
dimension reduction taking place during the flattening process where crucial
information and relations might get lost which are simply not
(re)-discoverable in a flattened event log. For example, in Figure 7, IODDA is
able to discover that the final decision depends on attributes from two
different object types namely Customers and Orders. However if the object-
centric event log were to be flattened to a traditional event log one would
only be able to analyze the process through the lens of the Customers or the
Orders, but because of the dimension reduction not all attributes might be
correctly attributed or even kept which makes that the algorithm described in
[8] simply does not have access to all the information.

##  9 Limitations and Future Work

The algorithm currently supports DOCEL logs, with plans for future support for
OCEL logs. The main challenge regarding OCEL logs, as explained previously, is
to know which attributes belong to which object [15]. Because this object-
attribute relation is a crucial foundation of the algorithm it is not trivial
to adapt it to OCEL logs. Next, the algorithm was developed to discover
activities that execute decisions as well as the decision logic, but currently
does not discover decision points. This is because control flow information is
not explicitly taken into account, but IODDA rather implicitly has control
flow information such as XOR-splits through the analysis of decisions.
Supporting this in the future would provide an even more holistic overview of
the executed decisions and how their outcome impact the control flow of the
process. Also IODDA does not directly link the discovered DMN models to the
process models but since IODDA identifies the activities responsible for
executing decisions, this is certainly also possible. Next, despite the
algorithm being tested on two different realistic artificial logs, it would be
beneficial to test the algorithm on a real-life object-centric event log.
Unfortunately, due to a lack of publicly available object-centric logs, both
in a DOCEL and OCEL format, in which decisions take place, this was not
possible within this study. But given that OCEL logs can be converted into
DOCEL log formats, we hope that public KiP OCEL logs will be made available to
further test the algorithm on real-life object-centric logs.

Complex values such as lists or dictionaries currently form a challenge for
the algorithm. For example, imagine we have three different product types
{P1,P2,P3} with Value: {100,200,150} and a customer enters an order with the
following quantity for Quantity:{1,0,3}. The first question is then, which
Quantity and Value value refers to which product type as this is not
explicitly provided together with the log but is rather implicit information.
Secondly, even if this information is known, one would still need to decide on
a fitting correlation metric as it might be that there is no one size fits all
metric as one could give equal or different weights related to the number of
elements of the complex values however this only works if these are of equal
lengths. In short, the support of complex values requires more research. In
essence this issue can be solved by further normalizing the log but this has
not been proposed in the object centric process literature yet and would
require more investigation of its impact.

Because event logs are an enactment of processes, not all decision paths are
necessarily traversed in a sufficient amount to have sufficient (if any)
correlation. As such, the complete ground truth DMN model can not always be
discovered in full but only the paths which are executed within the log.
Following up on the previous observation, because the initial variable
selection procedure is based on the mutual information between two variables,
complex relationships involving multiple variables might not always be
discovered completely because of the fact that these two variables do not have
enough correlation between them despite them being part of a complex
relationship. Further investigation of a variable selection procedure
addressing this aspect is also planned in the future.

##  10 Conclusion

Object-centric event logs have been introduced to store business processes
with multiple object types. This development holds particular significance for
decision mining, as organizations frequently make decisions by integrating
information from various process-involved sources. Consequently, decisions can
be inherently regarded as object-centric. This paper proposes the first
Integrated Object-centric and Decision Discovery Algorithm (IODDA). IODDA is
able to discover which activities introduce relevant decision variables and
which activities execute decisions. Next to that, it is also able to relate
the variables to the correct object types. Lastly, the algorithm is also able
to discover the decision logic behind each decision. All together, a holistic
overview of the process as well as a complete DMN model, containing both the
discovered decision structure and decision logic, are discovered by the
algorithm. The algorithm is implemented on a set of data-aware object-centric
event logs which are made available to the public together with the first
DOCEL log generators. Based on the results, it can be concluded that object-
centric event logs can be used to automatically discover DMN models.

## Acknowledgements

This study was supported by the Research Foundation Flanders under grant
numbers G079519N and G039923N and Internal Funds KU Leuven under grant number
C14/23/031.

## References

  * Adams et al. [2022b] J. N. Adams, G. Park, S. Levich, D. Schuster, W. M. van der Aalst, A framework for extracting and encoding features from object-centric event data, in: Service-Oriented Computing: 20th International Conference, ICSOC 2022, Seville, Spain, November 29–December 2, 2022, Proceedings, Springer, 36–53, 2022b.
  * Adams et al. [2022a] J. N. Adams, D. Schuster, S. Schmitz, G. Schuh, W. M. van der Aalst, Defining Cases and Variants for Object-Centric Event Data, arXiv preprint arXiv:2208.03235 .
  * Adams and van der Aalst [2021] J. N. Adams, W. van der Aalst, Precision and Fitness in Object-Centric Process Mining, in: ICPM), IEEE, 128–135, 2021.
  * Bazhenova et al. [2016] E. Bazhenova, S. Bülow, M. Weske, Discovering decision models from event logs, in: International Conference on Business Information Systems, Springer, 237–251, 2016.
  * Berti [2022] A. Berti, Filtering and Sampling Object-Centric Event Logs, arXiv preprint arXiv:2205.01428 .
  * Berti and van der Aalst [2022] A. Berti, W. M. van der Aalst, OC-PM: analyzing object-centric event logs and process models, International Journal on Software Tools for Technology Transfer (2022) 1–17.
  * Biard et al. [2015] T. Biard, A. Le Mauff, M. Bigand, J.-P. Bourey, Separation of decision modeling from business process modeling using new “Decision Model and Notation”(DMN) for automating operational decision-making, in: Working Conference on Virtual Enterprises, Springer, 489–496, 2015.
  * De Smedt et al. [2019] J. De Smedt, F. Hasić, S. K. vanden Broucke, J. Vanthienen, Holistic discovery of decision models from process execution data, Knowledge-Based Systems 183 (2019) 104866.
  * Delias and Grigori [2023] P. Delias, D. Grigori, Formulating the potentials of clustering of event data over multiple entities for decision support: a network embeddings approach, Journal of Decision Systems (2023) 1–23.
  * Estrada-Torres et al. [2023] B. Estrada-Torres, A. del Río-Ortega, M. Resinas, Defining Process Performance Measures in an Object-Centric Context, in: BPM 2022 International Workshops, Münster, Germany, September 11–16, 2022, Revised Selected Papers, Springer, 210–222, 2023.
  * Galanti et al. [2023] R. Galanti, M. De Leoni, N. Navarin, A. Marazzi, Object-centric process predictive analytics, Expert Systems with Applications 213 (2023) 119173.
  * Ghahfarokhi et al. [2022] A. F. Ghahfarokhi, F. Akoochekian, F. Zandkarimi, W. M. van der Aalst, Clustering Object-Centric Event Logs, arXiv preprint arXiv:2207.12764 .
  * Ghahfarokhi et al. [2020] A. F. Ghahfarokhi, G. Park, A. Berti, W. van der Aalst, Ocel standard, Process and Data Science Group, RWTH Aachen University, techreport 1.
  * Ghilardi et al. [2022] S. Ghilardi, A. Gianola, M. Montali, A. Rivkin, Petri net-based object-centric processes with read-only data, Information Systems 107 (2022) 102011.
  * Goossens et al. [2023a] A. Goossens, J. De Smedt, J. Vanthienen, W. M. van der Aalst, Enhancing Data-Awareness of Object-Centric Event Logs, in: Process Mining Workshops: ICPM 2022 International Workshops, Bozen-Bolzano, Italy, October 23–28, 2022, Revised Selected Papers, Springer, 18–30, 2023a.
  * Goossens et al. [2023b] A. Goossens, A. Rebmann, J. De Smedt, J. Vanthienen, H. van der Aa, From OCEL to DOCEL–Datasets and Automated Transformation, arXiv preprint arXiv:2309.14092 .
  * Günther and Verbeek [2014] C. W. Günther, H. M. W. Verbeek, XES standard definition, IEEE Std .
  * Holmberg [2014] N. Holmberg, The purity of separation of concerns: The service oriented business process-a design approach for business agility, Lund University, 2014\.
  * Hull et al. [2011] R. Hull, E. Damaggio, R. De Masellis, F. Fournier, M. Gupta, F. T. Heath III, S. Hobson, M. Linehan, S. Maradugu, A. Nigam, et al., Business artifacts with guard-stage-milestone lifecycles: managing artifact interactions with conditions and events, in: Proceedings of the 5th ACM DEBS, 51–62, 2011.
  * Kleijn et al. [2012] J. Kleijn, M. Koutny, M. Pietkiewicz-Koutny, Regions of Petri nets with a/sync connections, Theoretical Computer Science 454 (2012) 189–198.
  * Leewis et al. [2020] S. Leewis, K. Smit, M. Zoet, Putting Decision Mining into Context: A Literature Study, Digital Business Transformation: Organizing, Managing and Controlling in the Information Age (2020) 31–46.
  * Li et al. [2018] G. Li, E. G. L. d. Murillas, R. M. d. Carvalho, W. van der Aalst, Extracting object-centric event logs to support process mining on databases, in: CAISE, Springer, 182–199, 2018\.
  * Manning [2009] C. D. Manning, An introduction to information retrieval, Cambridge university press, 2009\.
  * OMG [2015] OMG, OMG: Decision Model and Notation 1.0 (2015), URL https://www.omg.org/spec/DMN/1.0/, accessed: 2022-01-08, 2015.
  * Rebmann et al. [2022] A. Rebmann, J.-R. Rehse, H. Van der Aa, Uncovering object-centric data in classical event logs for the automated transformation from XES to OCEL, in: ICPM, Springer, 379–396, 2022.
  * Rozinat and van der Aalst [2006] A. Rozinat, W. M. P. van der Aalst, Decision Mining in ProM, in: Business Process Management, Lecture Notes in Computer Science, Springer, 420–425, 2006\.
  * Rzepakowski and Jaroszewicz [2010] P. Rzepakowski, S. Jaroszewicz, Decision trees for uplift modeling, in: 2010 IEEE International Conference on Data Mining, IEEE, 441–450, 2010\.
  * Strecht [2015] P. Strecht, A survey of merging decision trees data mining approaches, in: Proc. 10th Doctoral Symposium in Informatics Engineering, 36–47, 2015\.
  * van der Aalst and Berti [2020] W. van der Aalst, A. Berti, Discovering object-centric Petri nets, Fundamenta informaticae 175 (1-4) (2020) 1–40.
  * van der Aalst [2019] W. M. van der Aalst, Object-centric process mining: Dealing with divergence and convergence in event data, in: Software Engineering and Formal Methods: 17th International Conference, SEFM 2019, Oslo, Norway, September 18–20, 2019, Proceedings 17, Springer, 3–25, 2019\.
  * van der Aalst et al. [2001] W. M. van der Aalst, P. Barthelmess, C. A. Ellis, J. Wainer, Proclets: A framework for lightweight interacting workflow processes, International Journal of Cooperative Information Systems 10 (04) (2001) 443–481.
  * van der Aalst et al. [2017] W. M. van der Aalst, G. Li, M. Montali, Object-centric behavioral constraints, arXiv preprint arXiv:1703.05740 .
  * Vanthienen [2021] J. Vanthienen, Decisions, advice and explanation: an overview and research agenda, in: A Research Agenda for Knowledge Management and Analytics, Edward Elgar Publishing, 149–169, 2021\.
  * Vanthienen et al. [1998] J. Vanthienen, C. Mues, A. Aerts, An illustration of verification and validation in the modelling phase of KBS development, Data & Knowledge Engineering 27 (3) (1998) 337–352.