Intelligent Systems for Process Mining

09/09/2022 - KES 2022, Verona, Italy
Intelligent systems
for process mining
Marco Montali
Free University of Bozen-Bolzano, Italy

What do we do
We develop novel, foundational and applied
techniques
grounded in arti
fi
cial intelligence, logics, and
formal methods,

to create intelligent agents and information
systems that combine

processes and data.

How to attack these challenges?
Arti
fi
cial
Intelligence
Knowledge representation

Automated reasoning

Computational logics
Information
Systems
Business process
management

Data management

Decision management
Formal
Methods
In
fi
nite-state systems

Veri
fi
cation

Petri nets
Data
Science
Process mining

Data access
and integration

models data
process event
process mining

Outline
process mining
using

intelligent systems
!
Tiny part of the map:
one relevant task, with
focus on KRR

Outline
process mining
using

intelligent systems
declarative

processes
monitoring

(runtime conformance)

Outline
process mining
using

intelligent systems
declarative

processes
challenges
monitoring

(runtime conformance)

Work process
A set of logically related tasks performed to achieve a de
fi
ned business
outcome for a particular customer or market.

(Davenport, 1992)

A collection of activities that take one or more kinds of input and create an
output that is of value to the customer.

(Hammer & Champy, 1993)

A set of activities performed in coordination in an organizational and technical
environment. These activities jointly realize a business goal.

(Weske, 2011)

Why “work process” and not “business process”?
Steady transition from business process management to process
management in the large
• Production processes

• Normative processes

• Manufacturing processes

• Systems with humans in the loop (knowledge-intensive processes)

• Automated systems (autonomous processes with little human
intervention)

Process mining applicable on any dynamic systems with exogenous
events and endogenous activities (“work” to be carried out)

The two realities within organisations
managers &
analysts
knowledge
workers
• de
fi
nition of business
goals

• de
fi
nition of operational
processes

• strategic decision making

• resource planning

• …
• day-by-day realization of
goals

• execution of operational
processes

• runtime decision making

• resource allocation

• …
produce

models
generate

data

data
models
REALITY
managers/
analysts
enact/
monitor
process
discovery
con
fi
gure/
deploy
(re)
design
IT support
ORGANISATION
knowledge
workers

REALITY
managers/
analysts
enact/
monitor
process
discovery
con
fi
gure/
deploy
(re)
design
IT support
ORGANISATION
knowledge
workers
data
models
process models
event logs

How to drive
organisations
based on reality?
How to link
workforce and
management?

data
models
REALITY
managers/
analysts
con
fi
gure/
deploy
(re)
design
IT support
knowledge
workers
ORGANISATION
enact/
monitor
process
discovery

data
models
REALITY
managers/
analysts
con
fi
gure/
deploy
(re)
design
IT support
knowledge
workers
ORGANISATION
enact/
monitor
process
discovery
Not based on facts,
but on an indirect
perception of reality

REALITY
managers/
analysts
enact/
monitor
process
discovery
con
fi
gure/
deploy
(re)
design
IT support
knowledge
workers
ORGANISATION
?
data
models

REALITY
managers/
analysts
enact/
monitor
process
discovery
con
fi
gure/
deploy
(re)
design
IT support
knowledge
workers
ORGANISATION
?
data
models
Process
mining

Process mining: “data science in action”
https://www.tf-pm.org

The process mining framework
Original picture by Wil van der Aalst
1.3 Process Mining 9

Process mining streams
Replay: Connecting events to mod
elements is essential for process m
event log process model
Play-In
event log
process model
Play-Out
Replay
• extended model
elements is essential for process m
Play-In
event log
process model
Play-Out
Replay
• extended model
showing times,
frequencies, etc.
Play-In
event log
process model
Play-Out
Replay
• extended model
showing times,
frequencies, etc.
• diagnostics
• predictions
• recommendations
Play in
Play out
Replay

Event data
5.2 Event Logs 129
Table 5.1 A fragment of some event log: each line corresponds to an event
Case id Event id Properties
Timestamp Activity Resource Cost ...
1 35654423 30-12-2010:11.02 register request Pete 50 ...
35654424 31-12-2010:10.06 examine thoroughly Sue 400 ...
35654425 05-01-2011:15.12 check ticket Mike 100 ...
35654426 06-01-2011:11.18 decide Sara 200 ...
35654427 07-01-2011:14.24 reject request Pete 200 ...
2 35654483 30-12-2010:11.32 register request Mike 50 ...
35654487 30-12-2010:14.16 examine casually Pete 400 ...
35654488 05-01-2011:11.22 decide Sara 200 ...
35654489 08-01-2011:12.05 pay compensation Ellen 200 ...
35654522 30-12-2010:15.06 examine casually Mike 400 ...
35654524 30-12-2010:16.34 check ticket Ellen 100 ...
35654525 06-01-2011:09.18 decide Sara 200 ...

Event data
5.2 Event Logs 129
35654426 06-01-2011:11.18 decide Sara 200 ...
35654488 05-01-2011:11.22 decide Sara 200 ...
35654525 06-01-2011:09.18 decide Sara 200 ...
130 5 Getting the Data

Event data
5.2 Event Logs 129
35654426 06-01-2011:11.18 decide Sara 200 ...
35654488 05-01-2011:11.22 decide Sara 200 ...
35654525 06-01-2011:09.18 decide Sara 200 ...
130 5 Getting the Data
<log xes.version="1.0"

xes.features="nested-attributes"

openxes.version="1.0RC7">

<extension name="Time"

prefix="time"

uri="http://www.xes-standard.org/time.xesext"/>

<classifier name="Event Name" keys="concept:name"/>

<string key="concept:name" value="XES Event Log"/>

...

<trace>

<string key="concept:name" value="1"/>

<event>

<string key="User" value="Pete"/>

<string key="concept:name" value="create paper"/>

<int key="Event ID" value="35654424"/>

...

</event>

<event>

...

<string key="concept:name" value="submit paper"/>

...

</event>

attKey: String
attType: String
Attribute
extName: String
extPrefix: String
extUri: String
Extension
attValue: String
ElementaryAttribute CompositeAttribute
{disjoint}
ca-contains-a
*
*
logFeatures: String
logVersion: String
Log Trace Event
GlobalAttribute
GlobalEventAttribute
GlobalTraceAttribute
EventClassifier
TraceClassifier
name: String
Classifier
a-contains-a
*
*
*
* e-usedBy-a
e-usedBy-l
*
*
l-contains-t t-contains-e
* *
*
1..*
l-contains-e
*
*
* * *
*
*
*
l-has-a
t-has-a
e-has-a
l-has-gea *
1..*
l-contains-ec
1..*
*
1..*
l-contains-tc
*
ec-definedBy-gea
1..*
*
1..*
1..*
* tc-definedBy-gea
l-has-gta
*
{disjoint}
{disjoint}
Fig. 14: A more comprehensive event schema, capturing all main abstractions of the
XES standard
IEEE standard

Play in: discovery
register travel
request (a)
get detailed
motivation
letter (c)
get support
from local
manager (b)
check budget
by finance (d)
decide (e)
accept
request (g)
reject
request (h)
reinitiate
request (f)
start end
Case Activity Timestamp Resource
432 register travel request (a) 18-3-2014:9.15 John
432 get support from local manager (b) 18-3-2014:9.25 Mary
432 check budget by finance (d) 19-3-2014:8.55 John
432 decide (e) 19-3-2014:9.36 Sue
432 accept request (g) 19-3-2014:9.48 Mary
…

Replay: conformance checking
256 8 Conformance Checking

Extended framework information system(s)
current
data
“world”
people
machines
organizations
business
processes documents
historic
data
resources/
organization
data/rules
control-flow
de jure models
resources/
organization
data/rules
control-flow
de facto models
provenance
explore
predict
recommend
detect
check
compare
promote
discover
enhance
diagnose
cartography
navigation auditing
event logs
models
“pre
mortem”
“post
mortem”
From post-mortem
event data to runtime
operational support

Large industry uptake
• In the last 15 years: from few attempts to a
fl
ourishing market of 30+
process mining vendors
• Many success stories (e.g., from startups to large companies in 10 years,
large acquisitions of process mining solutions, …)

• Growing market:  
see 2021 Gartner’s  
Market guide for 
process mining

Intelligent
systems
for process
mining

Opportunity #1: solidity
In terms of correctness, formal guarantees, performance
Replay: Connecting events to model
elements is essential for process mining
ay-In
event log
process model
y-Out
play
• extended model
showing times,
frequencies, etc.
• diagnostics
• predictions
PAGE 3
lay-In
event log
process model
ay-Out
eplay
• extended model
showing times,
frequencies, etc.
• diagnostics
• predictions
• recommendations
PAGE 3
Play-In
event log
process model
lay-Out
Replay
• extended model
showing times,
frequencies, etc.
• diagnostics
• predictions
• recommendations
SAT

solvers
SMT/OMT
solvers
Planners
Automated
reasoners
Automata
Neural

networks
Constraint
solvers
Neurosymbolic
reasoners
Model

checkers
Encoding
Extension
…

On control and flexibility
complexity ->
predictability <-
repetitiveness <-

complexity ->
predictability <-
repetitiveness <-
Control

degree to which a
central
orchestrator
decides how to
execute the
process

complexity ->
predictability <-
repetitiveness <-
Control

degree to which a
central
orchestrator
decides how to
execute the
process
Flexibility

degree to which
process
stakeholders
locally decide how
to execute the
process

Which Italian food do you like best?
complexity ->
predictability <-
repetitiveness <-
Control

degree to which a
central
orchestrator
decides how to
execute the
process
Flexibility

degree to which
process
stakeholders
locally decide how
to execute the
process
Lasagna
processes Spaghetti
processes

Reality is often more flexible than it seems…

Opportunity #2: reasoning support
Taming spaghetti processes calls for “intelligent”
fi
ltering,
querying, analysis, inference, abstraction, classi
fi
cation, …

• All in all: automated reasoning

Cognitive dimensions of notations (by Green): high
abstraction gradient and presence of hidden
dependencies call for underlying support

• Intelligent systems at the service of process mining

What is a process?
A possibly in
fi
nite set of
fi
nite traces
Σ*

Flexibility and control as contrasting forces
Σ*
control
fl
exibility

The issue of flexibility is widely known
Different ways to address
fl
exibility in processes
We are interested here in

fl
exibility by design

Two process modelling paradigms
Imperative models

• Repetitive, predictable processes

• Metaphor:
fl
owchart
speci
fi
cations

• Highly-variable processes

• Metaphor: rules/constraints
Dec t i
lar
a
e
v

Imperative modelling
Focus: how things must be done

• Explicit description of the process control-
fl
ow

Closed modelling

• All that is not explicitly modelled is forbidden

• Exceptions/uncommon behaviours: explicitly enumerated
at design time

The effect of imperative modelling
Receive
order
Check
availability
Article available?
Ship article
Financial
settlement
yes
Procurement
no
Payment
received
Inform
customer
Late delivery
Undeliverable
Customer
informed
Inform
customer
Article
removed
Remove
article from
catalogue

Receive
order
Check
availability
Article available?
Ship article
Financial
settlement
yes
Procurement
no
Payment
received
Inform
customer
Late delivery
Undeliverable
Customer
informed
Inform
customer
Article
removed
Remove
article from
catalogue
Input Output

Receive
order
Check
availability
Article available?
Ship article
Financial
settlement
yes
Procurement
no
Payment
received
Inform
customer
Late delivery
Undeliverable
Customer
informed
Inform
customer
Article
removed
Remove
article from
catalogue
Input Output
Receive
order
Check
availability
Article available?
Ship article
Financial
settlement
yes
Procurement
no
Payment
received
Inform
customer
Late delivery
Undeliverable
Customer
informed
Inform
customer
Article
removed
Remove
article from
catalogue

… and an imperative model of it
Σ*

Example
Flexible shopping (without considering data)
• Tasks: = {pick item, close order, pay}

• A customer may pick items, close several orders, and pay one or
more orders at once

• She may even close an empty order and pay for it, or pay multiple
times (whole orders or order parts; a no-op if nothing is left to pay)

• Process constraint: whenever you close an order, you have to
pay later at least once
Σ

Quiz: which traces belong to the process?
“Whenever you close an order, you have to pay later at least once”
1.<> (empty trace)

2.<i,i,i>

3.<i,i,i,c,p>

4.<i,i,i,c,p,p>

5.<i,i,i,p,c>

6.<i,c,p,i,i,c,p>

Quiz: How to model the process with BPMN?
First attempt:
1. <> (empty trace)

2. <i,i,i>

3. <i,i,i,c,p>

4. <i,i,i,c,p,p>

5. <i,i,i,p,c>

6. <i,c,p,i,i,c,p>
pick
item
close
order
pay
quit
order paid

First attempt:
1. <> (empty trace)

2. <i,i,i>

3. <i,i,i,c,p>

4. <i,i,i,c,p,p>

5. <i,i,i,p,c>

6. <i,c,p,i,i,c,p>
pick
item
close
order
pay
quit
order paid
Simple, correct, but not general enough

Most liberal attempt:
1. <> (empty trace)

2. <i,i,i>

3. <i,i,i,c,p>

4. <i,i,i,c,p,p>

5. <i,i,i,p,c>

6. <i,c,p,i,i,c,p>
pick
item
close
order
pay
pick
item
pay

Most liberal attempt:
1. <> (empty trace)

2. <i,i,i>

3. <i,i,i,c,p>

4. <i,i,i,c,p,p>

5. <i,i,i,p,c>

6. <i,c,p,i,i,c,p>
Correct, general (captures the rule in a maximal way), but unreadable
pick
item
close
order
pay
pick
item
pay

68
Declarative process
specifications

!
Simplicity
cannot be
obtained by
sweeping
complexity
under the
carpet

Our goal
Compact
speci
fi
cation
Reality
represents

Our goal
Compact
speci
fi
cation
Reality
represents
The class of “regular”
spaghetti processes
(not all)

Idea
Focus: what has to be accomplished

• Explicit description of the relevant process constraints

• Control-
fl
ow left implicit

Open modelling

• All behaviors are possible as long as all constraints are
satis
fi
ed

Declarative specifications as constraints
Process Imperative
model
Declarative
speci
fi
cation

Constraint-based specifications of behaviour
• Multiagent systems: declarative agent programs [Fisher,JSC1996]
and interaction protocols [Singh,AAMAS2003]

• Data management: cascaded transactional updates
[DavulcuEtAl,PODS1998]

• BPM (1st wave): loosely-coupled subprocesses [SadiqEtAl,ER2001]

• BPM (2nd wave): process constraints

• DECLARE [PesicEtAl,EDOC2007]

• Dynamic Condition-Response (DCR) Graphs
[HildebrandtEtAl,PLACES2010]

Origin of Declare…
Language, formalisation, reasoning, enactment

Constraint templates
Constraint types de
fi
ned on activity placeholders, each with a speci
fi
c
meaning

• … then instantiated on actual activities (by grounding)

Dimensions
• Activities: how many are involved

• Time: temporal orientation (past, future, either) and strength (when)

• Expectation: negative vs positive

Much richer than the precedence
fl
ow relation of imperative languages

Playing with the three dimensions…
Unary templates (over a single activity A)

• Existence: you should/cannot do A (for a certain number of times)

Binary templates (apply to two - or more - tasks)

• Choice: do A (x-)or B

• Relation: if A occurs, then B must also occur (when?)

• Negation: if A then B cannot occur (when?)

Once instantiated, binary constraints may branch to represent potential
alternatives

Declare specification
A set of constraints (templates grounded on the
activities of interest)

• Constraints have to be all satis
fi
ed globally over
each, complete trace

• Compositional approach by conjunction

Flexible shopper in Declare
1. <> (empty trace)

2. <i,i,i>

3. <i,i,i,c,p>

4. <i,i,i,c,p,p>

5. <i,i,i,p,c>

6. <i,c,p,i,i,c,p>
Pick

item
Close
order
Pay
Accepts all {i, c, p}*

Flexible shopper in Declare
1. <> (empty trace)

2. <i,i,i>

3. <i,i,i,c,p>

4. <i,i,i,c,p,p>

5. <i,i,i,p,c>

6. <i,c,p,i,i,c,p>
Pick

item
Close
order
Pay
response

Interaction among constraints
Aka hidden dependencies [____,TWEB2010]
Cancel
order
Close
order
Pay
If you cancel the order,
you cannot pay for it
If you close the order,
you must pay for it
Pick

item
To close an order, you
must
fi
rst pick an item

Cancel
order
Close
order
Pay
you must pay for it
Pick

item
must
fi
rst pick an item
Implied: cannot
cancel and
con
fi
rm!

Cancel
order
Close
order
Pay
you must pay for it
Pick

item
must
fi
rst pick an item
Implied: cannot
cancel and
con
fi
rm!
Key questions
1. How to
characterise the
language of a
Declare
speci
fi
cation?

2. How to
understand
whether a
speci
fi
cation is
correct?

Back to the roots
Patterns in Linear
Temporal Logic
(LTL)

LTL: a logic for infinite traces
Logic interpreted over in
fi
nite traces
' ::= A | ¬' | '1 ^ '2 | ' | '1U'2
Atomic propositions
Boolean connectives
At next step φ holds
At some point φ2 holds, and φ1 holds until φ2 does
φ eventually holds
φ always holds
φ1 holds forever or until φ2 does
' ::= A | ¬' | '1 ^ '2 | ' | '1U'2
::= A | ¬' | '1 ^ '2 | ' | '1U'2
'1 ^ '2 | ' | '1U'2
| ' | '1U'2
⌃' ⌘ true U'
⇤' ⌘ ¬⌃¬'
'1W'2 = '1U'2 _ ⇤'1
⇤' ⌘ ¬⌃¬'
…
Each state indicates which
propositions hold

fi
nite traces
' ::= A | ¬' | '1 ^ '2 | ' | '1U'2
Atomic propositions
Boolean connectives
φ eventually holds
φ always holds
' ::= A | ¬' | '1 ^ '2 | ' | '1U'2
::= A | ¬' | '1 ^ '2 | ' | '1U'2
'1 ^ '2 | ' | '1U'2
| ' | '1U'2
⌃' ⌘ true U'
⇤' ⌘ ¬⌃¬'
'1W'2 = '1U'2 _ ⇤'1
⇤' ⌘ ¬⌃¬'
…
propositions hold
Can be
seamlessly
extended
with past-
tense
operators

fi
nite traces
' ::= A | ¬' | '1 ^ '2 | ' | '1U'2
Atomic propositions
Boolean connectives
φ eventually holds
φ always holds
' ::= A | ¬' | '1 ^ '2 | ' | '1U'2
::= A | ¬' | '1 ^ '2 | ' | '1U'2
'1 ^ '2 | ' | '1U'2
| ' | '1U'2
⌃' ⌘ true U'
⇤' ⌘ ¬⌃¬'
'1W'2 = '1U'2 _ ⇤'1
⇤' ⌘ ¬⌃¬'
…
propositions hold
Can be
seamlessly
extended
with past-
tense
operators
Trace t satis
fi
es a
formula is now
formally de
fi
ned:

φ
t ⊧ φ

Semantics of Declare via LTL
Atomic propositions are activities

Each constraint is an LTL formula (built from template formulae)

…
Each state contains

a single activity
delete
order
close
order
pay
pick

item

delete

order
pick

item

Each constraint is an LTL formula (built from template formulae)

…
Each state contains

a single activity
close
order
pay
□ (
𝚌
𝚕
𝚘
𝚜
𝚎
→ ◊
𝚙
𝚊
𝚢
)


A Declare speci
fi
cation is the conjunction of its constraint formulae

…
Each state contains

a single activity
delete
order
pick

item
close
order
pay
□ (
𝚌
𝚕
𝚘
𝚜
𝚎
→ ◊
𝚙
𝚊
𝚢
)
∧ □ (
𝚌
𝚕
𝚘
𝚜
𝚎
→ ◊
𝚒
𝚝
𝚎
𝚖
)
∧ □ (
𝚌
𝚊
𝚗
𝚌
𝚎
𝚕
→ ¬ □
𝚙
𝚊
𝚢
)

An unconventional use of logics!
From …

Temporal logics for specifying (un)desired properties of
a dynamic system

… to …

Temporal logics for specifying the dynamic system itself

Wait a moment…
Close
order
Pay
□ (
𝚌
𝚕
𝚘
𝚜
𝚎
→ ◊
𝚙
𝚊
𝚢
)

Wait a moment…
Close
order
Pay
□ (
𝚌
𝚕
𝚘
𝚜
𝚎
→ ◊
𝚙
𝚊
𝚢
)
Just what we needed!

But recall: each process
instance should complete
 
in a
fi
nite number of steps!

LTLf: LTL over finite traces
[DeGiacomoVardi,IJCAI2013]
LTL interpreted over
fi
nite traces
' ::= A | ¬' | '1 ^ '2 | ' | '1U'2
No successor!
Same syntax of LTL
In LTL, there is always a next moment… in LTLf, the contrary!
φ always holds from current to the last instant
The next step exists and at next step φ holds
(weak next) If the next step exists, then at next step φ holds
last instant in the trace
' | '1 ^ '2 | ' | '1U'2
⇤'
Last ⌘ ¬ true
' ⌘ ¬ ¬'

Look the same, but they are not the same
Many researchers: misled by moving from in
fi
nite to
fi
nite traces

In [____,AAAI14], we studied why!

• People typically focus on “patterns”, not on the entire logic

• Many of such patterns in BPM, reasoning about actions, planning, etc. are
“insensitive to in
fi
nity”

Quiz: does this specification accept traces?
b c
0..1
1..*
a d

a b

a b
Only the empty trace <>,
due to
fi
nite-trace
semantics

How to do this, systematically?
Declare speci
fi
cation: encoded in LTLf

LTLf: the star-free fragment of regular expressions

Regular expressions: intimately connected to
fi
nite-state
automata

• No exotic automata models over in
fi
nite structures!

• Just the good-old deterministic
fi
nite-state automata
(DFAs) you know from a typical course in programming
languages and compilers

From Declare to automata
LTLf NFA 
nondeterministic
DFA 
deterministic
LTLf2aut determin.
'
nt
lf formulas can be translated into equivalent nfa:
t |= Ï iff t œ L(AÏ)
/ldlf to nfa (exponential)
to dfa (exponential)
often nfa/dfa corresponding to ltlf /ldlf are in fact small!
ompile reasoning into automata based procedures!
Process engine!
[____,TOSEM2022]

Vision realised!
LTLf NFA 
nondeterministic
DFA 
deterministic
LTLf2aut determin.
'
nt
lf formulas can be translated into equivalent nfa:
t |= Ï iff t œ L(AÏ)
/ldlf to nfa (exponential)
to dfa (exponential)
often nfa/dfa corresponding to ltlf /ldlf are in fact small!
ompile reasoning into automata based procedures!
Process engine!
[____,TOSEM2022]

Few lines of code
[____,TOSEM2022] 0:8 G. De Giacomo et al.
(tt, ⇧) = true
(↵ , ⇧) = false
( , ⇧) = (h itt, ⇧) ( prop.)
('1 ^ '2, ⇧) = ('1, ⇧) ^ ('2, ⇧)
('1 _ '2, ⇧) = ('1, ⇧) _ ('2, ⇧)
(h i', ⇧) =
⇢
E (') if ⇧ |= ( prop.)
false if ⇧ 6|=
(h ?i', ⇧) = ( , ⇧) ^ (', ⇧)
(h⇢1 + ⇢2i', ⇧) = (h⇢1i', ⇧) _ (h⇢2i', ⇧)
(h⇢1; ⇢2i', ⇧) = (h⇢1ih⇢2i', ⇧)
(h⇢⇤
i', ⇧) = (', ⇧) _ (h⇢iF h⇢⇤i', ⇧)
([ ]', ⇧) =
⇢
E (') if ⇧ |= ( prop.)
true if ⇧ 6|=
([ ?]', ⇧) = (nnf (¬ ), ⇧) _ (', ⇧)
([⇢1 + ⇢2]', ⇧) = ([⇢1]', ⇧) ^ ([⇢2]', ⇧)
([⇢1; ⇢2]', ⇧) = ([⇢1][⇢2]', ⇧)
([⇢⇤
]', ⇧) = (', ⇧) ^ ([⇢]T [⇢⇤]', ⇧)
(F , ⇧) = false
(T , ⇧) = true
Fig. 1: Definition of , where E (') recursively replaces in ' all occurrences of atoms of
the form T and F by .
1: algorithm LDLf 2NFA
2: input LDLf formula '
3: output NFA A(') = (2P
, S, s0, %, Sf )
4: s0 {'} . set the initial state
5: Sf {;} . set final states
6: if ( (', ✏) = true) then . check if initial state is also final
7: Sf Sf [ {s0}
8: S {s0, ;}, % ;
9: while (S or % change) do
10: for (s 2 S) do
11: if (s0
|=
V
( 2s) ( , ⇧) then . add new state and transition
12: S S [ {s0
}
13: % % [ {(s, ⇧, s0
)}
14: if (
V
( 2s0) ( , ✏) = true) then . check if new state is also final
15: Sf Sf [ {s0
}
Fig. 2: NFA construction.
' NFA

Few lines of code
[____,TOSEM2022] 0:8 G. De Giacomo et al.
(tt, ⇧) = true
(↵ , ⇧) = false
( , ⇧) = (h itt, ⇧) ( prop.)
('1 ^ '2, ⇧) = ('1, ⇧) ^ ('2, ⇧)
('1 _ '2, ⇧) = ('1, ⇧) _ ('2, ⇧)
(h i', ⇧) =
⇢
E (') if ⇧ |= ( prop.)
false if ⇧ 6|=
(h ?i', ⇧) = ( , ⇧) ^ (', ⇧)
(h⇢1 + ⇢2i', ⇧) = (h⇢1i', ⇧) _ (h⇢2i', ⇧)
(h⇢1; ⇢2i', ⇧) = (h⇢1ih⇢2i', ⇧)
(h⇢⇤
i', ⇧) = (', ⇧) _ (h⇢iF h⇢⇤i', ⇧)
([ ]', ⇧) =
⇢
E (') if ⇧ |= ( prop.)
true if ⇧ 6|=
([ ?]', ⇧) = (nnf (¬ ), ⇧) _ (', ⇧)
([⇢1 + ⇢2]', ⇧) = ([⇢1]', ⇧) ^ ([⇢2]', ⇧)
([⇢1; ⇢2]', ⇧) = ([⇢1][⇢2]', ⇧)
([⇢⇤
]', ⇧) = (', ⇧) ^ ([⇢]T [⇢⇤]', ⇧)
(F , ⇧) = false
(T , ⇧) = true
Fig. 1: Definition of , where E (') recursively replaces in ' all occurrences of atoms of
the form T and F by .
1: algorithm LDLf 2NFA
2: input LDLf formula '
3: output NFA A(') = (2P
, S, s0, %, Sf )
4: s0 {'} . set the initial state
5: Sf {;} . set final states
6: if ( (', ✏) = true) then . check if initial state is also final
7: Sf Sf [ {s0}
8: S {s0, ;}, % ;
9: while (S or % change) do
10: for (s 2 S) do
11: if (s0
|=
V
( 2s) ( , ⇧) then . add new state and transition
12: S S [ {s0
}
13: % % [ {(s, ⇧, s0
)}
14: if (
V
( 2s0) ( , ✏) = true) then . check if new state is also final
15: Sf Sf [ {s0
}
Fig. 2: NFA construction.
' NFA
Automata manipulations
much easier to handle
than in the in
fi
nite case,
with huge performance
improvements

[ZhuEtAl,
IJ
CAI17]
[Westergaard,BPM11]

Constraint automata
Template: pre-compiled into a DFA

Constraint: grounds the template DFA on speci
fi
c activities
close
order
delete
order
pay
pick

item
close
order
pay
0 1
2
i
Σ
{i,c}
Σ∖ Σ
c
1
1
{c}
Σ∖
c
{p}
Σ∖
p
0 1
2
p
Σ
{d}
Σ∖
d
{p}
Σ∖

Combining constraints
responded existence(a,b) response(a,c)

AND

AND
X

From local automata to global automaton
Entire speci
fi
cation: product automaton of all local
automata

• Corresponds to the automaton of the conjunction of
all formulae

• Many optimisations available
Declare speci
fi
cation consistent if and only if its
global automaton is non-empty

(Anticipatory) monitoring
t
Evolving trace
Declare speci
fi
cation
Monitor
Continuous feedback
Track a running process execution to check conformance to a reference process
model

• Goal: Detect and report
fi
ne-grained feedback and deviations as early as possible

One of the main operational support tasks

• Complementary to predictive monitoring!

(Anticipatory) monitoring
Track a running process execution to check conformance to a reference process
model

• Goal: Detect and report
fi
ne-grained feedback and deviations as early as possible

One of the main operational support tasks

• Complementary to predictive monitoring!
…
…
t
…
…
…
Declare speci
fi
cation
Monitor
Continuous feedback
Evolving trace

Fine-grained feedback
Re
fi
ned analysis of the “truth value”
of a constraint, looking into (all)
possible futures
Consider a partial trace t, and a
constraint C...
…
…
…
t
C
satis
fi
ed?
…
…
C
satis
fi
ed?

RV-LTL truth values
[BauerEtAl,InfCom2010]
C is permanently satis
fi
ed if t
satis
fi
es C and no matter how t is
extended, C will stay satis
fi
ed

C is currently satis
fi
ed if t satis
fi
es C
but there is a continuation of t that
violates C
…
…
t
…
…
…
t

RV-LTL truth values
C is currently violated if t violates C
but there is a continuation that leads
to satisfy C

C is permanently violated if t violates
C and no matter how t is extended, C
will stay violated
t
…
…
…
…
…
[BauerEtAl,InfCom2010]

RV-LTL on finite traces
[____,BPM2011] [____,BPM2014] [____,TOSEM2022]
close
order
delete
order
pay
pick

item
close
order
pay
0 1
2
i
Σ
{i,c}
Σ∖ Σ
c
1
1
{c}
Σ∖
c
{p}
Σ∖
p
0 1
2
p
Σ
{d}
Σ∖
d
{p}
Σ∖
Su
ffi
xes of the current trace: each with unbounded,
fi
nite length
• Again standard DFAs -> all formulae of LTLf are monitorable
Each state of the DFA: colored with an RV-LTL value via simple reachability checks

RV-LTL on finite traces
[____,BPM2011] [____,BPM2014] [____,TOSEM2022]
Su
ffi
xes of the current trace: each with unbounded,
fi
nite length
• Again standard DFAs -> all formulae of LTLf are monitorable
Each state of the DFA: colored with an RV-LTL value via simple reachability checks
Σ
Σ
Σ
0

[cs]
1

[ps]
2

[pv]
1

[cv]
0

[cs]
0

[cs]
1

[cs]
2

[pv]
c
{i,c}
Σ∖
i
{c}
Σ∖
c
{p}
Σ∖
p
p
{d}
Σ∖
d
{p}
Σ∖
close
order
delete
order
pay
pick

item
close
order
pay

Monitor in action
close
order
delete
order
pay
pick

item
close
order
pay
cs
cs
cs

Monitor in action
close
order
delete
order
pay
pick

item
close
order
pay
cs
pick

item
cs
ps
cs

Monitor in action
close
order
delete
order
pay
pick

item
close
order
pay
cs
pick

item
cs
ps
cs
delete

order

close

order
Monitor in action
close
order
delete
order
pay
pick

item
close
order
pay
cs
pick

item
cs
ps
cs
delete

order
cv

pay

close

order
Monitor in action
close
order
delete
order
pay
pick

item
close
order
pay
cs
pick

item
cs
ps
cs
delete

order
cv cs
pv

pay

close

order
Monitor in action
close
order
delete
order
pay
pick

item
close
order
pay
cs
pick

item
cs
ps
cs
delete

order
cv cs
pv
Quiz: is this the earliest istant for
detecting a violation?

pay

close

order
Monitor in action
close
order
delete
order
pay
pick

item
close
order
pay
cs
pick

item
cs
ps
cs
delete

order
cv cs
pv
To satisfy: pay
To keep satis
fi
ed: don’t pay

pay

close

order
Monitor in action
close
order
delete
order
pay
pick

item
close
order
pay
cs
pick

item
cs
ps
cs
delete

order
cv cs
pv
cs pv
global monitor

002

[cs,cs,pv]
111

[ps,cv,cs]
112

[ps,cv,pv]
200

[pv,cs,cs]
102

[pv,cs,cs]
211

[pv,cv,cs]
202

[pv,cs,pv]
{i,c,d}
Σ∖
{i,c,p}
Σ∖
{i,c}
Σ∖
{c,d}
Σ∖
{c,p}
Σ∖
{d,p}
Σ∖
{p}
Σ∖
100

[ps,cs,cs]
101

[ps,cs,cs]
000

[cs,cs,cs]
001

[cs,cs,cs]
{c}
Σ∖
{c,d}
Σ∖
d
c c
i
p
c
i d
110

[ps,cv,cs]
c
p p
d
p
210

[pv,cv,cs]
c
{p,d}
Σ∖
p
d
{p}
Σ∖ p
{c}
Σ∖
i
c
p
{p}
Σ∖
c
212

[pv,cv,pv]
{p}
Σ∖
p
c
Global monitor

002

[cs,cs,pv]
111

[ps,cv,cs]
112

[ps,cv,pv]
200

[pv,cs,cs]
102

[pv,cs,cs]
211

[pv,cv,cs]
202

[pv,cs,pv]
{i,c,d}
Σ∖
{i,c,p}
Σ∖
{i,c}
Σ∖
{c,d}
Σ∖
{c,p}
Σ∖
{d,p}
Σ∖
{p}
Σ∖
100

[ps,cs,cs]
101

[ps,cs,cs]
000

[cs,cs,cs]
001

[cs,cs,cs]
{c}
Σ∖
{c,d}
Σ∖
d
c c
i
p
c
i d
110

[ps,cv,cs]
c
p p
d
p
210

[pv,cv,cs]
c
{p,d}
Σ∖
p
d
{p}
Σ∖ p
{c}
Σ∖
i
c
p
{p}
Σ∖
c
212

[pv,cv,pv]
{p}
Σ∖
p
c
Global monitor Anticipatory
violation detection

Can we do more?
LTLf
FOL

over

fi
nite traces
Star-free
regular
expressions
Finite-state
automata

MSOL over
fi
nite traces
Regular
expressions
Can we do more?
LTLf
FOL

over

fi
nite traces
Star-free
regular
expressions
Finite-state
automata

LDLf

linear dynamic logic
over
fi
nite traces

[DeGiacomoVardi,
IJ
CAI2013]
MSOL over
fi
nite traces
Regular
expressions
Can we do more?
LTLf
FOL

over

fi
nite traces
Star-free
regular
expressions
Finite-state
automata

LDLf

linear dynamic logic
over
fi
nite traces

[DeGiacomoVardi,
IJ
CAI2013]
MSOL over
fi
nite traces
Regular
expressions
Can we do more?
[____,BPM2014] [____,TOSEM2022]
LTLf
FOL

over

fi
nite traces
Star-free
regular
expressions
Finite-state
automata

From constraints to metaconstraints
[____,BPM2014] [____,TOSEM2022]
LDLf expresses RV-LTL monitoring states of LDLf constraints
• Support for metaconstraints predicating over the monitoring status of
other constraints

Example: a form of “contrary-to-duty” process constraint
• If constraint C1 gets permanently violated, eventually satisfy a
compensation constraint C2

Interesting open problem: relationship with normative frameworks and
defeasible reasoning
• [Governatori,EDOC2015] -> LTL cannot express normative notions

• [AlechinaEtAl,FLAP2018]-> not true!

Tooling
0:28 G. De Giacomo et al.
Fig. 10: Screenshot of one of the LDL MONITOR clients.
adopted by the IEEE task force on process mining. The response produced by the LDL
MONITOR provider is composed of two parts. The first part contains the temporal infor-
Fully implemented as part
of the RuM toolkit

(rulemining.org)

And the story continues…
Probabilistic constraints dealing with quanti
fi
ed
uncertainty for constraints which may or not hold.
Combination of probabilistic and logical reasoning.
Mixed-paradigm speci
fi
cations dealing with the interplay
of declarative and imperative processes in a loose or
tightly integrated fashion.
Data-aware speci
fi
cations dealing with case/event data
and conditisions, and with multiple co-evolving objects.
Undecidability issues, data-abstraction techniques
needed.
see lecture on
process mining
over multiple
behavioral
dimensions

Integration of prescriptive and predictive monitoring
…
…
t
…
…
…
Evolving trace
…
…

…
…
t
…
…
…
Evolving trace
…
…
predictive

monitor

t
Evolving trace
prescriptive

monitor

ERP systems: where are events?

Process mining and the classical 80/20 rule
80% 20%
time-consuming,

manual, ad-hoc, error-prone, undocumented

data curation
case
identi
fi
cation event

log
process

mining
Data preparation

Processes are not flat
Package
1
p1
p2 p3
Figure 1: Structure of order, item, and package data objects in an order-to-delivery sce-
nario whereuv items from di↵erent orders are carried in several packages
event log for orders
timestamp overall log order o1 order o2 order o3
2019-09-22 10:00:00 create order o1 create order
2019-09-22 10:01:00 add item i1,1 to order o1 add item
2019-09-23 12:27:00 pay order o3 pay order
2019-09-23 14:34:00 load item i1,1 into package p1 load item
2019-09-23 17:01:00 send package p1 send package send package
2019-09-24 08:46:00 send package p3 send package
2019-09-24 16:21:00 deliver package p1 deliver package deliver package
2019-09-24 18:52:00 deliver package p3 deliver package
2019-09-24 18:57:00 accept delivery p3 accept delivery
2019-09-25 08:32:00 accept delivery p1 accept delivery accept delivery
Table 1: Overall log of of an order-to-delivery scenario whose structure is illustrated in
Figure 1, and its flattening using the viewpoint of orders.

Package
1
p1
p2 p3
Item
Package
contains
carried

in
1
*
*
1
i1,1 i1,2 i2,1 i2,2 i2,3 i3,1
p1 p2 p3
Order o1 o2 o3

Package
1
p1
p2 p3
Item
Package
contains
carried

in
1
*
*
1
i1,1 i1,2 i2,1 i2,2 i2,3 i3,1
p1 p2 p3
Order o1 o2 o3
create order
(3)
add item
(6)
pay order
(3)
load item
(6)
send package
(5)
accept delivery
(5)
deliver package
(11)
3
3
3
3
3
4 1
1
2
3
2
5
6
3
Intelligent systems
needed in the
whole process
mining pipelines

3D processes require 3D models
Object-centric constraints [____,DL17] [____,BPM19]
Constraints co-referring via data model: co-evolution of multiple objects
• From propositional to
fi
rst-order temporal logics

• Interesting balance between expressiveness and decidability

• Discoverable from data (ongoing work)
Item
Order Package
create
order
add
item
get  
package
0..1 *
* 0..1
includes is in

Conclusions
Process mining: a fascinating
fi
eld at the intersection of data
science and process management
Intelligent systems required for solid, e
ff
ective process
mining
•No ad-hoc algorithms, but careful usage and further
development of well-established formalisms and techniques
AI and formal methods to the rescue for anticipatory
monitoring

Thank you!
montali@inf.unibz.it

Subsumption and incompatibility
Chain response(a,b): whenever a is executed, the next executed activity is b
Alternate response(a,b): whenever a is executed, a cannot be executed again
until b is executed

Response(a,b): whenever a is executed, b must be later executed

Negation succession(a,b): whenever a is executed, b cannot be later executed

Subsumption and incompatibility
Chain response(a,b): whenever a is executed, the next executed activity is b
Alternate response(a,b): whenever a is executed, a cannot be executed again
until b is executed

Response(a,b): whenever a is executed, b must be later executed

Negation succession(a,b): whenever a is executed, b cannot be later executed
Subsumes (is stronger than)
Subsumes (is stronger than)
Incompatible

Declarative process mining
DISCOVERY

Declarative process discovery
Simply stated…
Process discovery aiming at extracting
a declarative speci
fi
cation from a log
In our case: Declare

Declarative process discovery
Two settings
Discriminative mining
Speci
fi
cation mining
Event

log
Event

log
Partition
Discover
Discover
Speci
fi
cation that
covers all green traces
and rejects all red ones
Speci
fi
cation that
covers well all traces in
the log

All possible constraints grounded on
the activities in the log
The log

All possible constraints grounded on
the activities in the log
The log
Which to keep?

General idea
1.De
fi
ne suitable metrics to capture the meaning of covering
well -> interesting satisfaction

• Starting point: support and con
fi
dence from data mining

• Issues: not enough, not easy to import (see next slides)

2.Approach discovery by combining:

• Metrics for interestingness

• Temporal reasoning for logical correctness and for
computing the inputs of metrics

Naive support is not enough
Constraint support (naive) =

Issue: consider response(a,b)
• <a,c,b,a>
• <c,d,e,c,d,e,f>

• <b,c,d,e>

• <a,b>

• <a,a,b,a,b,a,b,a,a,a,b>

# traces that satisfy the constraint
total # traces in the log

Naive support is not enough
Constraint support (naive) =

Issue: consider response(a,b)
• <a,c,b,a>
• <c,d,e,c,d,e,f>

• <b,c,d,e>

• <a,b>

• <a,a,b,a,b,a,b,a,a,a,b>

Support: 4/5 (not informative)
# traces that satisfy the constraint
Need to:

1. Account for vacuous
satisfaction

2. Distinguish satisfying traces
based on interestingness

3. De
fi
ne event-based measures

Constraint activation and target
Activation: activity/moment that triggers an expectation in the constraint

Target: LTLf formula for the expectation

Systematically extracted from a normal form of constraints
AtLeastOne(a) Start Do a sooner or later
Response(a,b) a Do b afterwards
Precedence(a,b) b Did a before
NegationResponse(a,b) a Don’t do b afterwards
Template Activation Target

Trace-based support, refined
Constraint support (trace-based) =

Response(a,b)
• <a,c,b,a>
• <c,d,e,c,d,e,f>

• <b,c,d,e>

• <a,c,d,b>

• <a,a,c,b,a,b,a,d,b,a,a,c,a,b>

Support: from 4/5 to 2/5 (informative, but not re
fl
ecting what happens within a trace)
# traces that satisfy the constraint and activate it

Event-based support
Constraint support (event-based) =

Response(a,b)
• <a,c,b,a>
• <c,d,e,c,d,e,f>

• <b,c,d,e>

• <a,c,d,b>

• <a,a,c,b,a,b,a,d,b,a,a,c,a,b>

Support: 9/33 (informative, but not re
fl
ecting trace satisfaction/violation)
# events that satisfy the constraint activation and its target
total # events in the log

Trace- and event-based confidence
Activation and target: solid basis to import the notion of con
fi
dence from
association rule mining

Constraint con
fi
dence (trace-based) =

Constraint con
fi
dence (event-based) =

# traces that satisfy the constraint and activate it
# traces that activate the constraint
# events that satisfy the constraint activation and its target
# events that satisfy the constraint activation

Finally, discovery
1. Select templates of interest

2. Compute metrics for corresponding constraints (grounded on log activities)

3. Filter based on minimum thresholds

4. Redundant constraints?

• Keep the most liberal if metrics are better for it

• Keep the most restrictive in case of equal metrics

5. Incompatible constraints?

• Keep only the one with better metrics

6. Further processing to ensure consistency, minimality, …

Intelligent Systems for Process Mining

More Related Content

Similar to Intelligent Systems for Process Mining

More from Faculty of Computer Science - Free University of Bozen-Bolzano

Recently uploaded

Intelligent Systems for Process Mining