Multi-perspective conformance checking
for email-driven processes

Ralph Bou Nader, Ikram Garfatta, Marwa Elleuch, Walid Gaaloul, Yehia

Taher

► To cite this version:

Ralph Bou Nader, Ikram Garfatta, Marwa Elleuch, Walid Gaaloul, Yehia Taher. Multi-perspective conformance checking for email-driven processes. Web Information Systems Engineering - WISE 2024 - 25th International Conference, Dec 2024, Doha, Qatar. pp.441-457, 10.1007/978-981-96-0576-7_32 . hal-04933969

HAL Id: hal-04933969

https://hal.science/hal-04933969v1

Submitted on 27 Jan 2026

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
Multi-Perspective Conformance Checking For
Email-driven Processes

No Author Given

No Institute Given

**Abstract.** Business process conformance checking determines whether the execution of a process instance aligns with a predefined model that specifies its expected behaviour. Existing approaches are usually tailored for business processes modelled and executed through traditional Business process management systems and therefore fall short when the business processes to be checked are described or partially supported by rather unorthodox systems. Such is the case for *email-driven processes* which are generally business process fragments executed using emailing systems. In fact, one of the main limitations exhibited by existing conformance checking techniques is that they mostly only consider the behavioral, functional, and structural perspectives of a process. In the case of email-driven processes, however, it is crucial to also take into account the contextual perspective of the events obtained from the email bodies and threads. In this paper, we propose an approach for multi-perspective conformance checking of email-driven processes, taking into account both their sequential as well as their contextual perspectives.

**Keywords:** Process mining · Conformance checking · Event logs · Email-driven process.

# 1 Introduction

Process mining [15] is a set of techniques and methods used to analyze, discover, monitor, and improve business processes (BPs). Conformance checking [12] is a crucial component of process mining that compares the actual behavior of a process with its expected behavior. It enables process improvement by identifying areas where the actual process deviates from the expected behavior. This enables organizations to gain valuable insights into their operations, such as pinpointing inefficiencies and identifying opportunities for optimization.

To perform conformance checking, typically both an *event log* and a *reference process model* are required. The event log can be seen as a record of the sequence of events that have occurred in a process. The process model, on the other hand, can be seen as a representation of the expected behavior of the process, usually in the form of a workflow.

While a variety of conformance checking techniques have been developed for business processes executed in Business Process Management Systems (BPMS), these approaches are not specifically tailored for email-driven processes, which are the focus of our present work. In fact, email systems are commonly-used tools by nowadays organizations to have their employees collaboratively discuss and follow up on business tasks. These tasks can actually reflect a partial view (i.e., process fragments) on what can be seen as a bigger business process that potentially involves the execution of additional tasks using other systems. Subsequently, email logs (which
consist of exchanged email threads containing, for each email, details such as its body, sender, receivers, and timestamp) can provide supplementary BP execution traces describing BP *fragments*. Email systems can therefore be seen as complementary to BPM systems as their logs provide additional information such as the intention of the participants and their speech acts, rendering them a valuable resource for BP conformance checking.

Notably, previous works addressing these processes only focused on process discovery [10] and did not address conformance checking in this context. However, applying conformance checking to email systems can be particularly valuable for ensuring the quality of the text exchanged via email, including its accuracy and completeness. Consider a trading process where *David* initiates a request to *Joe* to review a gas trading repository by sending an email. In this process, crucial details such as *price*, *trading hours*, and the *volume of online gas trading* need to be included. However, there is a possibility that *David* unintentionally overlooks specific information essential for *Joe's* review. By applying conformance checking, any missing information can be detected, ensuring that *Joe* receives a comprehensive and accurate overview of the gas trading repository. This facilitates effective collaboration, allowing *Joe* to provide meaningful insights and strategies for the future.

To study the conformity of business processes performed through emails, it is crucial to correctly extract events from emails and understand the specificities of these events. Existing discovery algorithms have addressed activity discovery from emails. Therefore, in this study, we based our work on the most advanced algorithm available [10]. These email events can have additional attributes compared to those inferred from classical information systems. For instance, the intent of an event occurring in an email is identified not only by the explicitly mentioned activity name but also by the interlocutor's speech act. As an example, in the email depicted in Figure 1, where *Mark* informs *Joe*: "We are short 100 mw's in the Ercot Asset book for hours ending 7-22". *Mark's* speech act is an *information act* for the activity *open short position* occurring in the first sentence of *Mark's* email.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Real email retrieved from the Enron dataset for planning trading positions</figcaption></figure>

Furthermore, participants in business processes, such as *Mark*, often provide additional context by incorporating relevant email business data (BD) into their communications. Hence, the study of conformance checking for email-driven processes goes beyond merely considering the sequencing of activities. Other perspectives can be derived from the additional attributes of events that occur in emails, such as contextual perspectives (i.e., speech acts, business data, email threads, ...).

Several methods have been proposed for conformance checking [6], such as alignment-based methods [3, 4] that utilize event logs and process models to find the optimal alignment between the expected and actual behaviors. While these methods have shown promising results, they struggle to identify discrepancies that go beyond the perspective of the sequential flow of activities. To overcome this limitation, some approaches have addressed conformance checking for multi-perspective processes [8]. These approaches take into account additional perspectives, such as time, resources, and other data attributes. However, the existing methods show a significant gap in their ability to identify non-conformance in events from a complex business contextual per-
spective, such as emails. In fact, they generally make the assumption that the business context of an event is predefined based on the process to which it belongs [9]. For example, they do not account for the possibility that an event in the same process instance could deviate and be related to another process, thus referring to a different business context. This limitation becomes evident when dealing with emails or conversations, where topics often shift from one to another. As a result, a context-aware approach is necessary to effectively address the detection of event discrepancies. In an effort to address the aforementioned limitations, this paper proposes an approach for multi-perspective conformance checking in email-driven processes.

The subsequent sections of this paper are structured as follows: Section 2 discusses related work. In Section 3, Section 4 and Section 5 we present the technical details of our approach. Section 6 describes the experiment and validation of the main techniques proposed in our approach, along with a use case study, followed by the conclusion in Section 7.

## 2 Related Work

To explore the existing research relevant to our work, we approach the related literature from two points of view. We start by studies that have dealt with conformance checking of structured logs according to a process model and then we focus on studies that have addressed contextual aspects in textual representations but are unable to treat their process-specific aspects.

Traditional conformance checking methods in process mining encompass a variety of techniques aimed at comparing the observed event log with a predefined process model to identify discrepancies [9]. One popular approach is token replay [1], which involves replaying the event log on the process model to determine if each event aligns with the expected sequence of activities. Another common method is fitness measurement [2], which quantifies the degree of conformance between the event log and the process model. These methods mainly focus on detecting four types of discrepancies [6]: (i) Deviations, which are variations in the sequence of activities compared to the expected process flow, (ii) Repetitions, which occur when activities are performed multiple times when they should not be, (iii) Omissions, which happen when required activities are skipped, and (iv) Insertions, which involve including unnecessary activities. However, these methods have limitations in identifying discrepancies that go beyond the perspective of the sequential flow of activities. They may not adequately capture the complete range of complex dependencies and process variations.

Recent advancements in conformance checking for multi-perspective processes incorporate various perspectives such as time, resources, and other data attributes. Time-aware conformance checking identifies delays, timeouts, or deviations in event durations by aligning event times-tamps with the process model and applying temporal reasoning techniques like interval-based or sequence-based comparisons [13]. Resource-aware conformance checking analyzes resource allocation and utilization, highlighting inefficiencies such as underutilization, over-utilization, or improper allocation [14]. The MP-Declare approach by Burattin et al. combines temporal and control flow perspectives, utilizing Metric First-Order Linear Temporal Logic for defining constraints and employing a constraint template-based algorithmic framework for conformance checking [5]. Additionally, DCR (Dynamic Condition Response) graphs are used to represent observed execution behavior from event logs, enabling detailed comparisons with declared MP models [7]. These studies typically focus on structural and operational aspects, considering vari-ous data attributes. However, there's a notable gap in recognizing the crucial contextual perspec-tive of events. Neglecting to analyze crucial business data attributes mentioned in emails, can lead to misunderstandings and errors in understanding the intended actions or requirements. For example, in the email depicted in Figure 1, ignoring details like the source of power and specific actions needed, such as 'cut and replace', may lead to flawed decisions in energy procurement
strategies. This oversight could result in operational inefficiencies or compliance issues, especially if the power source is unreliable or unsustainable. On the other hand, some research has considered context in Natural Language Processing (NLP) techniques [11]. However, these approaches are limited for conformance checking in email-based processes as they ignore processes within these approaches. NLP methods predominantly rely on text analysis techniques and lack consideration for the process information (e.g., emails that belong to a process instance). Email processes conformance requires rich abstractions to reason about control flow, data and context perspectives. In other words, while these approaches can deal with non structured data, they are not used for conformance checking as they do not take into account its second input, namely the process model.

It is crucial to distinguish between email-driven processes and traditional ones when reasoning about conformance checking of processes. In fact, while traditional business processes have a clear temporal control flow in which one activity follows another in a well-defined sequence, email-driven processes do not exhibit this characteristic. The order of the activities involved in such processes is instead determined by their appearance within the emails and the sequencing of these emails within the threads of conversations. This order reflects how users perceive the execution of activities. Considering that email-driven processes usually represent fragments of business processes rather than complete ones, it is challenging to identify the control flow in such processes as it is not explicitly temporal but rather based on the structure of email conversations. Consequently, traditional process models are not capable of accommodating the unique characteristics of email-driven processes.

In an effort to mitigate these limitations, in this paper we propose a conformance-checking approach that not only takes into account the sequential perspective of email processes but also considers a more fine-grained contextual understanding and analysis of email events.

# 3 The Proposed Approach Overview

The approach, as depicted in Figure 2, receives as input a structured event log generated from an email log using the methodology proposed by Elleuch et al. [10], in conjunction with a *process model*. The latter is specified by a data analyst/expert and is built upon a set of constraints that pertain to both the *sequential* and *email contextual* aspects of the business process, highlighting the multi-perspective nature of our approach. Such constraints are guided by *constraint classes* that we have gleaned through the analysis of email datasets and that serve as templates for the analysts/experts to define their specific constraints. Using the constraints defined by the experts, we proposed a process model, the *Email Process Model*, which we use for conformance checking of events within the same email or thread. Consequently, the conformance checking algorithm proposed in our approach involves comparing the execution of a process instance (i.e., an event log instance) with the process model. This comparison helps identify two sets of events termed *fulfilling* and *violating* events. The former refers to events that occur within a process instance and align with the expected behaviors, while the latter refers to events that violate *sequential* and/or *email contextual* constraints. In addition, the conformity-checking algorithm is able to identify missing topics, highlighting deviations or inconsistencies in the context.

# 4 The Email Process Model

In the context of conformance checking techniques, a reference model is a representation of the expected behaviour of the running process. It serves as the standard against which actual process executions are compared to assess their adherence to predefined expectations. The representation of such a model can take several forms including imperative and declarative representations. In
<figure><img src="image_3.png" /><figcaption>Fig. 2. Approach overview</figcaption></figure>

this work, we propose a declarative approach that gives the designer the possibility to define a
reference model that we call *Email Process Model* by means of expressing constraints on the
activities involved in the email process. Such a declarative approach prioritizes the definitions
of desired outcomes over the explicit specification of the steps to achieve them. In order to ex-
press the constraints, our approach provides the designer with a set of *constraint classes* that
we have extracted and defined following an analysis of email datasets. These constraint classes
would serve as templates for the designer to express the actual constraints and they cover both
the sequential and contextual perspectives of email-driven processes, and therefore provide a par-
tial view on their respective BPs. In the following, we start by providing essential email-related
definitions in section 4.1, followed by our proposed constraint classes in section 4.3.

**4.1 Email-Related Concepts**

An email log can be viewed as a set of *emails*, each characterized by a set of attributes as outlined in Definition 1.

**Definition 1 (Email).** Let $\mathcal{EM}$ be the set of all *emails*. An *email* $em \in \mathcal{EM}$ is a tuple $\langle ID, timestamp, from, to, sbj, body \rangle$ where: $ID$ refers to its unique identifier, $timestamp$ refers to its sending time, $from$ refers to its expediter, $to$ refers to the list of its receivers, $sbj$ refers to its subject, and $body$ refers to its textual content

This definition reflects what an email is from the point of view of users. It is however worth
noting that in our work, *emails* are seen as a representation of the execution of a process.

Emails in an email log can be linked through *reply* and *forward* relations. More precisely, an
email *em*<sub>j</sub> can be a response (in the form of *reply* or *forward*) to at most another anterior email
*em*<sub>i</sub> (and we note *em*<sub>i</sub> R *em*<sub>j</sub>) and/or be replied to or forwarded in zero or more posterior emails.
These relations evoke the notion of *conversations*. An email conversation can therefore be defined
as follows:

**Definition 2 (Email Conversation).** Let $\mathcal{CV}$ be the set of all email conversations. An email conversation $conv \in \mathcal{CV}$ is a set of $l$ emails $\{em_i | \forall i \in [1, l], em_i \in \mathcal{EM}\}$ such that, if $l > 1$ then $\forall em_i \in conv, \exists em_j \in conv \setminus \{em_i\}$ such that $(em_i R em_j) \lor (em_j R em_i)$.

In other words, an email conversation is a set of *emails* pairwise linked by a response (i.e., *reply* or
*forward*) relation. For instance, in Fig. 3, [*email*<sub>1</sub>, *email*<sub>2</sub>] and [*email*<sub>3</sub>, *email*<sub>4</sub>] form two different
conversations respectively.
<figure><img src="image_4.png" /></figure>

<figure><img src="image_5.png" /></figure>

<figure><img src="image_6.png" /></figure>

<figure><img src="image_7.png" /><figcaption>Fig. 3. Emails retrieved from Enron data-set</figcaption></figure>

## 4.2 Email-based Process

Emails pertaining to an email-driven process would express the occurrence of *activities* that are likely to belong to a BP. An activity is formally defined as follows (Definition 3):

**Definition 3 (Activity).** Let $\mathcal{A}$ be the set of all activities and $\mathcal{BD}$ the set of all business data. An activity $act \in \mathcal{A}$ is defined as a tuple $(AN, BD)$ such that: AN is the name of the activity that reflects its main goal; and $BD \subseteq \mathcal{BD}$ is a set of business data used and generated during activity execution.

An activity is defined as a composition of two components (activity name and business data). Taking the example of the activity creating trading deals; (1) the activity name (AN) is 'create deal' and (2) the set {'deal price', 'deal identifier'} is included in its business data (BD).

Speech acts are used to further express the reason of inclusion of an activity in an email, and is defined as follows:

**Definition 4.** Let $SA = \{Request, Intention, Information, Request for information\}$ be the set of considered speech acts. Hence, a speech act $SA \in SA$ can be a:

- Request act: the sender requests that the recipient(s) carry out an activity.

- Intention act: the sender expresses a desire for future participation in the activity (by themselves or others).

- Information act: the sender uses the email to provide information about activity execution status (whether it has been executed or not or is currently being executed).

For example, the activity that would be deduced from "I would like to request an interview with the candidate to further discuss their qualifications and
suitability for the position" would be associated a speech act Request. Whereas the speech act in "Kate, my assistant, will participate in the telephone interview" would be Intention. The example "The telephone interview has been scheduled for tomorrow at 10 AM" provides information regarding the scheduled time for the activity conducting an interview and therefore would have a speech act Information.

To be able to represent an email-driven process model, just like for traditional process models, designers would have to identify the set of activities involved in their models. In our case, these activities would be present in the emails which represent the execution traces of email-driven process model. We also note that an email can involve multiple activities of the model and that an activity can appear in multiple emails. In fact, when an activity occurs in an email we talk about an activity instance and we define it as follows:

**Definition 5 (Activity Instance).** Let $O_{act}$ be the set of occurrences of an activity act = $\langle AN, BD \rangle \in \mathcal{A}$. An activity instance $act_{occ} \in O_{act}$ is a tuple $\langle AN_{occ}, BD_{occ}, em \rangle$ such that:

- $AN_{occ} = AN$, is the name of the activity corresponding to the occurrence.

- $BD_{occ} \subseteq O_{BD}$, is the set of business data occurrences related to the activity instance.

- $em \in EM$, is the email in which the activity instance occurs.

- $th \in TH$, is the email thread in which the activity instance occurs (see Definition 6 for threads).

In a traditional business model, the notion of activity instance is directly linked to a process instance. However, in the case of an email-driven process, the notion of process instance is not explicitly apparent, but is rather expressed through the basic structures of an emailing system, namely the emails and email threads. In fact, conversations in an email log can be grouped into threads based on their common relevant information values (such as specific BD) and email addresses, in order to approximate the concept of a trace (in an event log). In fact, the relevant information values that group conversations into threads approximate BP instance identifiers. These instance identifiers act as links between various events and the sequences of a particular BP execution. An email thread is therefore a set of email conversations that must have in common at least one relevant information value (i.e., BD) and one interlocutor.

In the following, we denote by $\mathcal{AD}$ the set of possible values for an email address, by $\mathcal{TO}$ the set of possible values for an email receiver addresses and by $O_{bd}$ the set of possible values of a business data $bd \in \mathcal{BD}$.

Let $f_{RI}: CV \rightarrow 2^{O_{BD}}$ be a function that returns the relevant information values related to a conversation, and let $f_{interloc}: CV \rightarrow 2^{\mathcal{AD}}$ be a function that returns the set of interlocutors in a conversation.

**Definition 6 (Email Thread).** Let $\mathcal{TH}$ be the set of all email threads. An email thread $th \in \mathcal{TH}$ is a set of $n$ conversations $\{cv_i | \forall i \in [1,n], cv_i \in CV\}$ such that: $(\bigcap_{i \in [1,n]} f_{RI}(cv_i)) \neq \emptyset \wedge (\bigcap_{i \in [1,n]} f_{interloc}(cv_i)) \neq \emptyset$

Figure 3 illustrates a real example of an email thread retrieved from the Enron dataset. The thread is composed of four emails belonging to two conversations. It reports interactions between employees in the context of a trading gas instance. This instance is identified by the relevant information value '454057' of the associated deal number.

## 4.3 Definition of Constraint Classes

Constraint classes can be seen as *relations* between different elements of an email where the *domains* and *ranges* can vary depending on the constraint class. In other words, each constraint
class $C_i$ can be defined as a relation: $C_i \subseteq X \times Y$ where X and Y will be later precised for each $C_i$. We will be using the notation $(ref \stackrel{C_i}{\rightarrow} targ)$ to denote that the element *ref* is in relation to the element *targ* according to the constraint class $C_i$.

**Sequential constraints** These constraints establish a structured and organized flow of activities, enabling effective communication. The following provides an overview of the established sequential constraint classes that we incorporate into the definition of our process model. We note that for these constraint classes the relations are defined as: $C_i \subseteq \mathcal{A} \times \mathcal{A}$ ($i \in 1, 2$).

- **C1: Activity Sequencing Constraints in Emails** This constraint class expresses restrictions on the order of activities within the same email, focusing on the position of their occurrences and their associated speech acts, which enhances communication efficiency and comprehension among recipients. This class is defined as follows:
Let $\mathcal{A}_{em}$ denote the set of activities in an email *em*. The notation $(act_i \rightarrow act_j)$ where $act_i, act_j \in \mathcal{A}_{em}$ signifies that the activity $act_i$ precedes the activity $act_j$ within the email *em*. The constraint $C_1$ is therefore formulated as follows: $(act_i \xrightarrow{C_1} act_j)$. For example, the designer can define a constraint $(flow \ gas \xrightarrow{C_1} extend \ deal)$ to express that an activity *flow gas* in an email *g* precedes an activity *extend deal* within the same email. This can be highlighted in Email 1, as shown in Figure 3.

- **C2: Activity Sequencing Constraints in Threads** These constraints indicate which activities could be mentioned in subsequent emails of a thread as a response, either as activities to be performed in the future or as activities that have already been performed. Such constraints facilitate coherent and contextually relevant responses, streamlining communication and fostering a more organized exchange. Let $\mathcal{A}_{th}$ be the set of activities in the thread $th$, and let $\mathcal{A}_{th/cv}$ be the set of activities of this thread in the conversation $cv \in th$. The constraint $C_2$ is therefore defined as follows:
$(act_1 \xrightarrow{C_2} act_2)$ with $act_1, act_2 \in \mathcal{A}_{th}$ such that $\exists em_1, em_2$ such that $act_1 \in \mathcal{A}_{em_1} \land act_2 \in \mathcal{A}_{em_2} \land (em_1 \in \mathcal{R}em_2)$. Given the definition of $C_2$, a designer might establish that the activity *create deal* is followed by the activity *extend deal*, i.e., $(create \ deal \xrightarrow{C_2} extend \ deal)$. These activities belong to two different emails within the same thread, as exemplified in Email 1 and Email 2 shown in Figure 3.

**Contextual constraints** The importance of contextual constraints in conformance checking, especially in the context of emails, cannot be overstated. These constraints play a crucial role in ensuring adherence to the intended purpose of the conversation. In the following, we will define a set of contextual constraint classes that will be utilized in the construction of the process model. These classes will be of varying formats that will be precised for each one.

- **C3: Activity & BD relationship constraints** These constraints represent the relationship between the activities and their associated BD within threads. They facilitate the identification of incomplete information by delineating the interdependencies between activities and their corresponding business data within threads, ensuring a comprehensive overview of the ongoing processes. This constraints class is defined as a relation $C_3 \subseteq \mathcal{A} \times 2^{BD}$ and we note $(act \xrightarrow{C_3} FB)$ where $act = \langle AN, BD \rangle$ and $FB \subseteq BD$. As an example, the designer might define the following the constraint: $(create \ deal \xrightarrow{C_3} \{revenue, create, deal, ...\})$. In other words, the constraint specifies that the activity *create deal* is always used with a subset of the BD specified in the constraint.
- C4: **Activity & BD Topic Relationship Constraints** BD can be interconnected, forming a cluster of words representing a subject, commonly referred to as a topic. The constraints class that we present here represents the correlation between the activities and their most significant BD topics within threads, offering a clearer understanding of their primary focus, thereby reducing deviation from the main discussion thread. Let $\mathcal{TP}$ be the set of all possible topics. This constraint class is therefore defined as a relation $C_4 \subseteq \mathcal{A} \times 2^{\mathcal{TP} \times \mathbb{R}}$ and expressed using the format: $(act \xrightarrow{C_4} TP)$ where $act \in \mathcal{A}$ and $TP \in 2^{\mathcal{TP} \times \mathbb{R}}$ to denote that an activity act is linked to a set of topics with their respective probability score (or ranking) according to constraint $C_4$. For example, the designer might define the following constraint: $(extend \ deal \xrightarrow{C_4} \{(Business Growth, 0.8)\})$. This means that the activity "extend deal" should always be accompanied by a business data related to the topic Business Growth with a score of 0.8. Here, the score reflects the probability of the relevance of the business data to the topic of Business Growth, with a score of 0.8 indicating a high likelihood of correlation.

- C5: **Activity & BD frequency relationship Constraints** These constraints represent the correlation between an activity mentioned in an email and the presence of its related BD. This constraint class is therefore defined as a relation $C_5 \subseteq \mathcal{A} \times 2^{\mathcal{BD} \times \mathbb{R}}$ and expressed using the format: $(act \xrightarrow{C_5} BDF)$ where $act \in \mathcal{A}$ and $BDF \in 2^{\mathcal{BD} \times \mathbb{R}}$. For example, the designer might define the following constraint: $(flow \ gas \xrightarrow{C_5} \{(\textit{flow}^\prime, 0.84), (\textit{meter}^\prime, 0.71)\})$.

- C6: **Activity & BD Pairs Relation Constraints** These constraints represent connections between activities and business data within threads. This constraint class is defined as a relation $C_6 \subseteq \mathcal{A}^2 \times 2^{\mathcal{BD}}$ and expressed using the format: $((act_1, act_2) \xrightarrow{C_6} FD)$ where $act_1 = (AN_1, BD_1)$, $act_2 = (AN_2, BD_2)$ such that $(act_1, act_2) \in C_1 \cup C_2$ and $FD \subseteq BD_1 \cup BD_2$. As an example, the designer might define the following constraint: $((flow \ deal, extend \ deal) \xrightarrow{C_6} FD)$ where $FD = flow \ deal.BD \cup extend \ deal.BD$. In this example, the constraint captures a semantic relationship between the activities *flow deal* and *extend deal*, indicating that they are expected to be closely associated in terms of business data content. The specific terms in the example, such as *gas*, *system*, *price* serve as illustrative examples of the kind of business data that might be expected in the associated sets. The constraint is generic and implies a high likelihood of co-occurrence of specific business data when these two activities are observed in sequence.

Having defined both the sequential and contextual constraints classes, we can now represent the process model to be fed to the conformance checking algorithm. The process model is represented as directed graph to accurately capture the process behavior from two perspectives. In the graph representation, each directed edge connecting a parent and a child node corresponds to a reference event and a target event with the same sequential and contextual constraint. This approach ensures activities that can be taken as responses to a specific event are linked to the same reference/parent node. It allows us to establish the expected order, dependencies, and context between activities based on their sequential and contextual constraints. In the following definition, we denote by $\mathcal{A}_C$ the set of all activities used in the user-defined constraints.

**Definition 7 (Email Process Model).** A Email Process Model is a directed graph EPM = $(V, E)$ where $V \subseteq (\mathcal{A} \times 2^{\mathcal{BD}} \times 2^{\mathcal{TP}})$ and $E \subseteq (V \times V)$:

- $V = \{v_{act} | v_{act} = (act, BD, TP) \forall act \in \mathcal{A}_C\}$ with:

- $BD = (\bigcap_{act_t \in \mathcal{A}_C} C_6((act, act_t)) \cap C_3PERT))$

- $TP = \{tp | \exists r \in \mathbb{R} \wedge (tp, r) \in C_4PERT)\}$

- $E = \{e_i | e_i = (v_{act_1}, v_{act_2}), \forall v_{act_1}, v_{act_2} \in V \text{ such that } (act_1, act_2) \in C_1 \cup C_2\}$
<figure><img src="image_8.png" /><figcaption>**Fig. 4.** A partial view of the Email Process model</figcaption></figure>

Figure 4 depicts a partial view of the *Email Process Model*’s directed graph. This partial view focuses on activities related to managing gas deals, such as creating or receiving a deal. In the provided Email Process Model fragment, the node labeled N10 highlights the defined constraints as follows: the activity **create deal** represents *act* in bold, the business data [*create, numeric deal...*] corresponds to *BD*, and the topic name *Deal Creation* corresponds to *TP*. These elements form the $v_{act} = (act, BD, TP)$. An edge example is the directed connection from N10 (**create deal**) to N11 (**wrap, roll deal numeric**), representing $e_i = (v_{act1}, v_{act2})$, where $(act_1, act_2) \in C_1 \cup C_2$. This edge indicates a relationship between the activities based on conditions specified in the definition.

## 4.4 Email-based Process Log

Now that we have presented our proposed Email Process Model, we shift our focus onto the second input of our conformance checking approach, namely the structured event log. The latter will be used to compare against the defined process model, enabling the algorithm to identify deviations and ensure that the processes adhere to expected standards and workflows. Elements such as activities and business data, previously defined, can be found as attributes within an event in the event log. This structured event log can be obtained using the work of Elleuch et al. [10] and defined as in Definition 8. We note that this definition for a structured event log could easily be integrated into existing standards, such as Object-centric event logs (OCEL) [?], as an extension that would allow the representation of additional email-specific concepts included in our definition.
**Definition 8 (Event Log).** Let $\mathcal{E}$ be the set of all events. An event log is a set of events: $Log = \{Ev_i, \forall i \in [1,n]\}$ where each event $Ev_i$ is characterized by the tuple $\langle Act_o, SA, At_{ind}, I_{values}, em, Th_{id} \rangle$, where:

- $EVID$ is the event's unique identifier.

- $Act_o \in O_A$ is the occurred activity.

- $SA \in SA$ is the speech act of $Act_o$.

- $At_{ind}$ is the set of textual indices concerning the performers of $Act_o$.

- $I_{values} \subset Act_o.BD_{occ}$ is the set of related relevant information values.

- $em \in EM$ is the email where the activity occurred.

- $Th_{id}$ is the set of thread IDs to which the event belongs.

<table><caption>**Fig. 5.** Example of an Event Log Extract</caption><thead><tr><th>Event</th><th>Act<sub>o</sub></th><th>SA</th><th>At<sub>ind</sub></th><th>I<sub>values</sub></th><th>em</th><th>Sender</th><th>Recipients</th><th>Con<sub>vIDs</sub></th></tr></thead><tbody><tr><td>Ev_ID</td><td>AN<sub>acc</sub></td><td></td><td></td><td></td><td>ID</td><td>times tamp</td><td></td><td></td></tr><tr><td>e<sub>1</sub></td><td>["flow deal", ["flowed", 'deal'], [7,4]]</td><td></td><td></td><td></td><td>'155258<br>9.107585<br>3972330<br>JavaMail<br>evans@thyme&gt;'</td><td>'tri, 10<br>Nov<br>2000<br>06:17:<br>00<br>0800<br>(PST)'</td><td>'aimee.la<br>nnou@enr<br>ron.com'</td><td>'daren.farmer@enron.com'</td></tr><tr><td>e<sub>2</sub></td><td>["flow deal", ["flowed", 'deal'], [1,4,1]]</td><td></td><td></td><td></td><td>'45057', 'meter numeric_deal [5192]'</td><td></td><td></td><td>'C1'</td></tr><tr><td>e<sub>3</sub></td><td>["roll deal", ["rolled", 'deal'], [2,3]]</td><td></td><td></td><td></td><td>'297175<br>36.10758<br>5415038<br>8.laevans<br>all evans<br>@thyme&gt;'</td><td>'Wed, 15 Nov<br>2000<br>02:24:<br>00<br>0800<br>(PST)'</td><td>'daren.farmer@enron.com'</td><td>'aimee.lanno@enron.com'</td></tr><tr><td>e<sub>4</sub></td><td>["cover flow", ["cover", 'flow'], [3,4]]</td><td></td><td></td><td></td><td>'45057', 'meter numeric_metr [5192]'</td><td></td><td></td><td>'C1'</td></tr></tbody></table>

Figure 5 depicts an excerpt of the event log that would be generated from an email log including *email*₁ and *email*₂ shown in Figure 3. In the work of Elleuch et al. [?] the authors utilized unsupervised learning techniques to discover activities within email bodies. The approach involved identifying frequent patterns of words shared by activity expressions, even when variations such as synonymous words (e.g., the expressions 'change deal' and 'convert deal' refer to the same activity while using the synonymous words: 'change' and 'convert') or different word orders (e.g., the positions of appearance of the words 'extend' and 'deal' are switched in these expressions 'the deal was extended' and 'I extended the gas deal'. Additionally, the two words are nearly successive in the first expression while separated by the word 'gas' in the second expression) are present. By analyzing emails on a per-employee basis, common patterns related to activity components are captured. Subsequently, similar activities across different employees are grouped together based on measures of word synonymity and activity context.

# 5 The Conformance Checking Algorithm

In this section, we focus on the algorithm designed to ensure smooth alignment between the execution of a process instance and the process model. This algorithm is crucial in evaluating the degree to which events conform to the anticipated behavior within threads or emails. In our case, the execution of a process instance can be seen as a trace from the event log, which is a sequence of events.

The algorithm shown in Algorithm 5 takes as inputs a sequence of events and the *email process model* (EPM), returning a comprehensive list of fulfilling and/or violating events. Additionally, it provides information on any missing topics for each event, if applicable. The algorithm
<caption>**Algorithm 1 Conformance Checking with Event Type Detection**</caption>

INPUT: *S*, *EPM*
OUTPUT: *fulfilling_events* ← *Ø*, *violating_events* ← *Ø*, *missingTopics_list*
1: *current_node* ← *findStartingPoint(EPM, S[0].Acto*)
2: *fulfilling_events* ← []
3: *violating_events* ← []
4: *missingTopics_list* ← []
5: **for** *i* ← 0 **to** *len(S)* − 1 **do**
6: &nbsp;&nbsp;&nbsp;&nbsp;*next_nodes* ← *successors(current_node)*
7: &nbsp;&nbsp;&nbsp;&nbsp;**if** *i* + 1 < *len(S)* **then**
8: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*next_activity* ← *findOccurrences(S[i + 1].Acto, next_nodes)*
9: &nbsp;&nbsp;&nbsp;&nbsp;**else**
10: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*next_activity* ← *null*
11: &nbsp;&nbsp;&nbsp;&nbsp;*similarity* ← *CosineSimilarity(BD(current_node], BD(event])*
12: &nbsp;&nbsp;&nbsp;&nbsp;*missingTopics* ← *BD.topics(current_node) − BD.topics(event)*
13: &nbsp;&nbsp;&nbsp;&nbsp;**if** *next_activity* ≠ *null* and *similarity* > *threshold* **then**
14: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*event_type* ← 'fulfilling'
15: &nbsp;&nbsp;&nbsp;&nbsp;**else**
16: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**if** *next_activity* = *null* **then**
17: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*event_type* ← 'Sequential Flow Issue'
18: &nbsp;&nbsp;&nbsp;&nbsp;**else if** *missingTopics* ≠ *Ø* **then**
19: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*event_type* ← 'Deviation from the Main Topic'
20: &nbsp;&nbsp;&nbsp;&nbsp;**else**
21: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*event_type* ← 'Incomplete/Incorrect Information'
22: &nbsp;&nbsp;&nbsp;&nbsp;**if** *event_type* = 'fulfilling' **then**
23: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Append *event* to *fulfilling_events*
24: &nbsp;&nbsp;&nbsp;&nbsp;**else**
25: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Append (*event*, *event_type*) to *violating_events*
26: &nbsp;&nbsp;&nbsp;&nbsp;*detected.topics* ← *detect.topics(event)*
27: &nbsp;&nbsp;&nbsp;&nbsp;*missing.topics* ← *expected.topics* \ *detected.topics*
28: &nbsp;&nbsp;&nbsp;&nbsp;Append (*event*, *missing.topics*) to *missing.topics.list*
29: &nbsp;&nbsp;&nbsp;&nbsp;*current.node* ← *next.activity*
30: **return** *fulfilling_events*, *violating_events*, *missing.topics.list*

begins by setting up a current node based on the starting point of the event sequence (line 1). It
then visits each event in the sequence, evaluating the similarity between the BD of the current
node in the EPM and its occurrence in the event of the sequence by employing cosine similarity
(line 11). Upon calculating the similarity and identifying a match between the next activity in
the sequence of events and one of the activities of the next nodes in the email process model,
the algorithm determines the type of the event by calling the detect_event_type function (line
12). The detect_event_type function takes the next activity, similarity, current node, and event as
inputs, and it returns the event type and any missing topics. If the similarity score is above a
specified threshold and the next activity is valid, the event is classified as fulfilling and appended
to a set of fulfilling events. Conversely, if the similarity score is below the threshold or there is
no match found for the next activity, the event is added to a set of violating events. We have
identified three types of violating events that warrant our attention to enhance communication
effectiveness. The first type is Sequential Flow Issues, detected when the algorithm identifies a
mismatch between the expected and actual subsequent activities in the sequence of events (line
17 in detect_event_type). The second type is Deviation from the Main Topic, aiming to identify
instances where the conversation veers off course, potentially leading to miscommunication (line
19 in detect_event_type). The third type is Incomplete/Incorrect Information, where the algorithm
detects instances in which essential details are missing or incorrect (line 21 in detect_event_type).
Additionally, the Algorithm 5 identifies missing topics by comparing the detected topics of the
current event with the expected topics in the current node from the email process model (line 26
→ 28).
# 6 Experiments and Validation

Introducing a novel contribution that has remained unexplored until now presents a challenge in comparing our work to existing related research. This challenge primarily arises due to the distinctive structure of the email event log in our case, which deviates from the conventional format commonly studied in the literature.

To address this challenge and provide a comprehensive assessment, we present in Section 6.1 a detailed analysis of our approach's capability to detect non-conformance within email-driven processes. In Section 6.2, we demonstrate the practical application and benefits of our proposed approach with a use case involving the utilization of RESTful API endpoints. The approach, developed in Python, is readily available on GitHub <fnref n="1" />, where some of the experimental results can also be found.

## 6.1 Detection of Non-Conformance in Enron Email Logs

In typical conformance checking, algorithms handle conventional processes with nearly 100% accuracy. However, when dealing with email-based processes, the results can vary due to the unstructured nature of emails. To address this challenge, we conducted an experiment using two event logs extracted from the Enron dataset, which consists of internal emails related to the company's business operations. The first event log focuses on financial transactions, budgets, and forecasts, while the second log centers around discussions related to the energy industry and market trends. We first applied our proposed algorithm to identify violating and fulfilling event types within emails or threads in each log. Subsequently, we asked experts to classify the events manually. We then compared the non-conformance types detected by our approach with those identified by the experts to assess the accuracy and reliability of our method. This comparison is crucial for validating our algorithm's effectiveness in handling email-based processes. The results of our algorithm's classifications and the expert assessments are presented in Table 1. Additionally, Table 2 presents the calculated precision and recall for each type of non-conformance detected, based on the combined results from the two event logs extracted from the Enron dataset.

<table><caption>**Table 1.** Overview of the results</caption><thead><tr><th rowspan="2">Non-Conformity Type</th><th colspan="2">Approach Classification</th><th colspan="2">Expert Classification</th></tr><tr><th>First Log</th><th>Second Log</th><th>First Log</th><th>Second Log</th></tr></thead><tbody><tr><td>Sequential Flow Issue</td><td>40 Events</td><td>39 Events</td><td>50 Events</td><td>45 Events</td></tr><tr><td>Incomplete Information</td><td>70 Events</td><td>58 Events</td><td>75 Events</td><td>65 Events</td></tr><tr><td>Deviation from Main Topic</td><td>55 Events</td><td>38 Events</td><td>60 Events</td><td>45 Events</td></tr></tbody></table>

<table><caption>**Table 2.** Precision and Recall Metrics for Non-Conformance Types Detected in Enron Event Logs</caption><thead><tr><th>Non-Conformance Type</th><th>Precision</th><th>Recall</th></tr></thead><tbody><tr><td>Sequential Flow Issues</td><td>0.88</td><td>0.92</td></tr><tr><td>Incomplete Information</td><td>0.91</td><td>0.87</td></tr><tr><td>Deviations from Main Topic</td><td>0.83</td><td>0.81</td></tr></tbody></table>

In terms of Sequential Flow Issues, the expert classifications identified 50 events in the first log and 45 events in the second log, while the algorithm detected 40 events in the first log and 39

<footnote n="1">¹ https://anonymous.4open.science/r/Multi-Perspective-Conformance-Checking-For-Email-driven-Processes-ECF8</footnote>
in the second log, highlighting the algorithm's proficiency in handling sequencing challenges with a precision of 0.88 and a recall of 0.92, indicating its effectiveness in ensuring the correct order of events, crucial for maintaining the logical flow of communication. For Incomplete Information, experts classified 75 events in the first log and 65 events in the second log, while the algorithm identified 70 and 58 events, respectively, demonstrating its capability to detect missing details that could hinder effective communication; the precision of 0.91 and recall of 0.87 underscore the algorithm's ability to identify and address gaps in information, enhancing the completeness and clarity of communications. Regarding Deviation from Main Topic, expert classifications recorded 60 events in the first log and 45 in the second log, while the algorithm found 55 events in the first log and 38 in the second log, suggesting the algorithm's effectiveness in identifying when conversations stray from the main topic, as reflected by a precision of 0.83 and recall of 0.81, thus helping to maintain focus and relevance in the communication.

Overall, the results suggest that the proposed algorithm adeptly identifies non-conformities within both event logs, closely aligning with expert classifications. This alignment underscores the algorithm's potential to enhance communication effectiveness by systematically addressing specific non-conformance types, thereby contributing to the overall quality and coherence of communication within the Enron dataset's email event logs.

## 6.2 Use Case Study

The objective of this use case is to demonstrate and assess the practical application of a proposed approach to detect non-conformities in written emails. The approach utilizes a RESTful API endpoint specifically designed for this purpose. This endpoint uses HTTP POST requests to ensure secure data exchange and JSON for its lightweight, human-readable format. Through the `/email-compliance-verification` endpoint, users submit emails for logical coherence verification, with the API providing feedback on the logical flow of ideas. Thirty-three participants from diverse backgrounds, including data scientists and developers, were involved. They manually composed email replies from given samples and used the endpoint to validate their drafts. On average, the API flagged 3.5 issues per email, such as abrupt topic transitions and vague argumentation lines, enabling participants to make swift revisions within an average of 3 minutes. The efficiency gain, calculated using the formula $%EG = \frac{R_{manual} - R_{API}}{R_{manual}} \times 100$, indicates that the API-assisted revisions were significantly faster than manual revisions. As shown in Table 1, the efficiency gain, calculated at 15%, underscores the time-saving benefits of using the API. Overall, the endpoint effectively enhances the quality and efficiency of email composition by providing precise, actionable feedback.

<table><caption>**Table 3.** Impact of API-Aided Revisions on Email Draft Quality and Efficiency</caption><thead><tr><td>Participants</td><td>Number of Issues Identified (I<sub>avg</sub>)</td><td>Average Revision Time (min)</td><td>Efficiency Gain (%EG)</td></tr></thead><tbody><tr><td>33</td><td>3.5</td><td>3</td><td>15%</td></tr></tbody></table>

## 7 Conclusions

In conclusion, we have proposed an approach for multi-perspective conformance checking in the context of emails. We identified sequential and contextual constraints from the event log, and process models were constructed to represent the expected behaviors of events within an email and a thread. The introduced conformance checking algorithms identifies events as either *violating events* or *fulfilling events*, and the experiments underscore the utility of the developed algorithms in improving the quality of manually composed emails.
Moving forward, future work can focus on integrating the algorithms into an email system for real-time monitoring. Alerting mechanisms can enable proactive detection of conformance issues, ensuring that the meaning and purpose of the emails align with the ongoing discussion in the email conversation. We also intend to explore the possibility of leveraging GPT-4 to address the same conformance checking perspectives as in our present work. However, considering that GPT-4 operates more as a black box, it may disregard the underlying process involved in the email exchange and may be less domain-specific compared to our approach, which is centered on email-driven processes.

## References

1. Van der Aalst, W., Adriansyah, A., Van Dongen, B.: Replaying history on process models for conformance checking and performance analysis. Wiley Interdiscip. Rev.: Data Min. Knowl. Discov. 2(2), 182–192 (2012)

2. Adriansyah, A., van Dongen, B.F., van der Aalst, W.M.: Conformance checking using cost-based fitness analysis. In: EDOC 2011. pp. 55–64. IEEE (2011)

3. Berti, A., van der Aalst, W.M.: Reviving token-based replay: Increasing speed while improving diagnostics. ATAED@ Petri Nets/ACSD 2371, 87–103 (2019)

4. Berti, A., van der Aalst, W.M.: A novel token-based replay technique to speed up conformance checking and process enhancement. In: Trans. Petri Nets and Other Models of Concurrency XV, pp. 1–26. Springer (2021)

5. Burattin, A., Maggi, F.M., Sperduti, A.: Conformance checking based on multi-perspective declarative process models. Expert Syst. Appl. 65, 194–211 (2016)

6. Carmona, J., van Dongen, B., Solti, A., Weidlich, M.: Conformance checking. Springer 56 (2018)

7. Christfort, A.K.F., Slaats, T.: Efficient optimal alignment between dynamic condition response graphs and traces. In: International Conference on Business Process Management. pp. 3–19. Springer (2023)

8. De Leoni, M., Van Der Aalst, W.M.: Aligning event logs and process models for multi-perspective conformance checking: An approach based on ilp. In: BPM 2013. pp. 113–129. Springer (2013)

9. Dunzer, S., Stierle, M., Matzner, M., Baier, S.: Conformance checking: a state-of-the-art literature review. In: Proc. 11th Int. Conf. on Subject-Oriented Business Process Management. pp. 1–10 (2019)

10. Elleuch, M., Laga, N., Ismaili, O.A., Gaaloul, W.: Multi-perspective business process discovery from messaging systems: State-of-the art. Concurr. Comput. Pract. Exp. 35(11) (2023). https://doi.org/10.1002/cpe.6642, https://doi.org/10.1002/cpe.6642

11. Rabbi, M.F., Champa, A.I., Zibran, M.F.: Phishy? detecting phishing emails using ML and NLP. In: 21st IEEE/ACIS Int. Conf. on Software Engineering Research, Management and Applications, SERA 2023, Orlando, FL, USA, May 23-25, 2023. pp. 77–83. IEEE (2023)

12. Rozinat, A., Van der Aalst, W.M.: Conformance checking of processes based on monitoring real behavior. Inf. Syst. 33(1), 64–95 (2008)

13. Stertz, F., Mangler, J., Rinderle-Ma, S.: The role of time and data: online conformance checking in the manufacturing domain. arXiv:2105.01454 (2021)

14. Taghiabadi, E.R., Gromov, V., Fahland, D., van der Aalst, W.P.: Compliance checking of data-aware and resource-aware compliance requirements. In: OTM 2014 Conferences. pp. 237–257. Springer (2014)

15. Van Der Aalst, W.: Process mining: Overview and opportunities. ACM TMIS 3(2), 1–17 (2012)