The document discusses declarative process mining, outlining the principles of declarative process specifications, discovery, monitoring, and reasoning with temporal logics. It highlights the complexity, predictability, and flexibility of processes, and contrasts imperative and declarative modeling paradigms. Moreover, it elaborates on the significance of constraints, templates, and their applications in business process management, particularly using languages like Declare and linear temporal logic.

1. Declarative process mining
CLAUDIO DI CICCIO (Sapienza University of Rome)
MARCO MONTALI (Free University of Bozen-Bolzano)

2. declarative
process mining

3. declarative
process mining
1. Declarative
process
speci
fi
cations

4. declarative
process mining
1. Declarative
process
speci
fi
cations
3. Discovery
4. Monitoring

5. declarative
process mining
1. Declarative
process
speci
fi
cations
2. Reasoning with
temporal logics
and automata
3. Discovery
4. Monitoring

6. declarative
process mining
1. Declarative
process
speci
fi
cations
2. Reasoning with
temporal logics
and automata
3. Discovery
4. Monitoring
5. Extensions

7. AI
PM
declarative
process mining
1. Declarative
process
speci
fi
cations
2. Reasoning with
temporal logics
and automata
3. Discovery
4. Monitoring
5. Extensions

8. Declarative process mining
1. DECLARATIVE PROCESS SPECIFICATIONS

9. Not all processes are the same…

10. Not all processes are the same…
Complexity how easy it is
to coordinate, collaborate,
and take decisions within
the process

11. Not all processes are the same…
Complexity how easy it is
to coordinate, collaborate,
and take decisions within
the process
Predictability how easy it
is to know in advance how
to execute the process

12. Not all processes are the same…
Complexity how easy it is
to coordinate, collaborate,
and take decisions within
the process
Predictability how easy it
is to know in advance how
to execute the process
Repetitiveness how
frequently a new process
instance is started

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

14. On control and flexibility
complexity ->
predictability <-
repetitiveness <-
Control
degree to which a
central
orchestrator
decides how to
execute the
process

15. On control and flexibility
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

16. On control and flexibility
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

17. 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

18. Reality is often more flexible than it seems…

19. Reality is often more flexible than it seems…

20. What is a process?
A possibly in
fi
nite set of
fi
nite traces
Fix a
fi
nite set of activities
• Trace =
fi
nite sequence of activities from (event = activity in a position!)
Σ
Σ

21. What is a process?
A possibly in
fi
nite set of
fi
nite traces
Fix a
fi
nite set of activities
• Trace =
fi
nite sequence of activities from (event = activity in a position!)
= the in
fi
nite set of
fi
nite traces over
• Very controlled process: a tiny subset of
• The most liberal process: the whole
Σ
Σ
Σ* Σ
Σ*
Σ*

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

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

24. Flexibility and control as contrasting forces
Σ*
control
fl
exibility

25. BPM!

26. BPM?

27. BPM?
Knowledge-
intensive
processes

28. The issue of flexibility is widely known

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

30. 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

31. 31
Imperative process
models

32. 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

33. 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

34. 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
Input Output

35. 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
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

36. A process…
Σ*

37. … and an imperative model of it
Σ*

38. 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)
• Business constraint: whenever you close an order, you have to
pay later at least once
Σ

39. 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>

40. 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>

41. Quiz: How to model the process with BPMN?
“Whenever you close an order, you have to pay later at least once”
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

42. Quiz: How to model the process with BPMN?
“Whenever you close an order, you have to pay later at least once”
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

43. Quiz: How to model the process with BPMN?
“Whenever you close an order, you have to pay later at least once”
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

44. Quiz: How to model the process with BPMN?
“Whenever you close an order, you have to pay later at least once”
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

45. 45
Declarative process
specifications

46. !
Simplicity
cannot be
obtained by
sweeping
complexity
under the
carpet

47. Our goal
Compact
speci
fi
cation
Reality
represents

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

49. 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

50. Declarative specifications as constraints
Process Imperative
model
Declarative
speci
fi
cation

51. Declarative specifications as constraints
Process Imperative
model
Declarative
speci
fi
cation

52. Declarative specifications as constraints
Process Imperative
model
Declarative
speci
fi
cation

53. 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]

54. Origin of Declare…
Language, formalisation, reasoning, enactment

55. Which constraints are useful?

56. 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

57. 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

58. Existence templates

59. Relation templates

60. Mutual relation templates

61. Negation templates

62. 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

63. Flexible shopper in Declare
“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>
Pick
item
Close
order
Pay
Accepts all {i, c, p}*

64. Flexible shopper in Declare
“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>
Pick
item
Close
order
Pay
response

65. Interaction among constraints
Aka hidden dependencies [MontaliEtAl,TWEB2010]
Cancel
order
Confirm
order
Pay
If you cancel the order, you
cannot pay for it
If you con
fi
rm the order,
you must pay for it

66. Interaction among constraints
Aka hidden dependencies [MontaliEtAl,TWEB2010]
Cancel
order
Confirm
order
Pay
If you cancel the order, you
cannot pay for it
If you con
fi
rm the order,
you must pay for it
Hence:
forbidden to
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?

67. A full Declare model

68. A short detour
Are Petri nets declarative?
A Petri net supporting every trace on the given activities
Pick
item
Close
order
Pay

69. A short detour
Are Petri nets declarative?
Adding places induces temporal constraints
But shall we interpret them backwards? Or forward?
Pick
item
Close
order
Pay

70. A short detour
Are Petri nets declarative?
Atemporal and negative constraints cannot be explicitly
captured, nor incrementally
Pick
item
Close
order
Pay

71. Declarative process mining
2. REASONING WITH TEMPORAL LOGICS AND AUTOMATA

72. Back to the roots

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

74. 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

75. 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
Can be
seamlessly
extended
with past-
tense
operators

76. 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
Can be
seamlessly
extended
with past-
tense
operators
Trace t satis
fi
es a
formula is now
formally de
fi
ned:
φ
t ⊧ φ

77. Template formulae

78. Semantics of Declare via LTL
Atomic propositions are activities
Each constraint is an LTL formula (built from template formulae)
…
Each state is empty or contains
one single activity
0..1
Con
fi
rm
order
Reject
order
Finalize
order

79. Semantics of Declare via LTL
Atomic propositions are activities
Each constraint is an LTL formula (built from template formulae)
…
Each state is empty or contains
one single activity
0..1
Con
fi
rm
order
Reject
order
Finalize
order
⇤(F ! ⌃(C _ R))

80. Semantics of Declare via LTL
…
Each state is empty or contains
one single activity
⇤(F ! ⌃(C _ R))
^ ¬(⌃(F ^ ⌃F))
^ ¬CWF
^ ¬RWF
0..1
Con
fi
rm
order
Reject
order
Finalize
order
Atomic propositions are activities
Each constraint is an LTL formula (built from template formulae)
A Declare speci
fi
cation is the conjunction of its constraint formulae

81. 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

82. ⇤(F ! ⌃(C _ R))
^ ¬(⌃(F ^ ⌃F))
^ ¬CWF
^ ¬RWF
0..1
Con
fi
rm
order
Reject
order
Finalize
order
Wait a moment…

83. ⇤(F ! ⌃(C _ R))
^ ¬(⌃(F ^ ⌃F))
^ ¬CWF
^ ¬RWF
0..1
Con
fi
rm
order
Reject
order
Finalize
order
Wait a moment…
Just what we needed!
However…
Each process instance should
end in a
fi
nite number of steps!

84. 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
' ⌘ ¬ ¬'

85. Look the same, but they are not the same
Many researchers: misled by moving from in
fi
nite to
fi
nite traces
In [DeGiacomoEtAl,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”

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

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

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

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

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

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

92. Quiz: does this specification accept traces?
a b

93. Quiz: does this specification accept traces?
a b
Only the empty trace <>,
due to
fi
nite-trace
semantics

94. 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 automata you know from a typical
course in programming languages and compilers

95. 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 automata you know from a typical
course in programming languages and compilers

96. 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!
[DeGiacomoVardi,IJCAI2013]
[DeGiacomoEtAl,TOSEM2022]

97. 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!
[DeGiacomoVardi,IJCAI2013]
[DeGiacomoEtAl,TOSEM2022]

98. Few lines of code
[DeGiacomoEtAl,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

99. Few lines of code
[DeGiacomoEtAl,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]

100. Constraint automata
Template: pre-compiled into a DFA
Constraint: grounds the template DFA on speci
fi
c activities

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

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

103. Combining constraints
responded existence(a,b) response(a,c)
AND

104. Combining constraints
responded existence(a,b) response(a,c)
AND
X

105. Combining constraints
responded existence(a,b) response(a,c)
AND
X

106. 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

107. 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

108. 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

109. Network

110. Ready?

111. Declarative process mining
3. DISCOVERY

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

113. 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

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

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

116. 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

117. 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

118. 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
total # traces in the log
Need to:
1. Account for vacuous
satisfaction
2. Distinguish satisfying traces
based on interestingness
3. De
fi
ne event-based measures

119. 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

120. 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
total # traces in the log

121. 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
total # traces in the log

122. 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

123. 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

124. 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

125. 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, …

126. Example

127. Example

128. Example

129. Example

130. Example

131. Example

132. Example

133. Example

134. Example

135. Research tooling

136. Declarative process mining
4. MONITORING

137. 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 task (process mining at runtime)
• Di
ff
erent from predictive monitoring!
…
…
t
…
…
…
Evolving trace
Declare speci
fi
cation
Monitor
Continuous feedback

138. 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?

139. RV-LTL truth values
[BauerEtAl,TOSEM2011]
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

140. 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,TOSEM2011]

141. Monitoring by coloring automata
[MaggiEtAl,BPM2011] [DeGiacomoEtAl,TOSEM2022]
Each automaton state: colored with an RV-LTL value
• Via simple
fi
nal-state reachability checks

142. Monitoring by coloring automata
[MaggiEtAl,BPM2011] [DeGiacomoEtAl,TOSEM2022]
Each automaton state: colored with an RV-LTL value
• Via simple
fi
nal-state reachability checks

143. Monitor in action

144. Monitor in action

145. Monitor in action

146. Monitor in action

147. Monitor in action

148. Monitor in action

149. Early detection of violations
Quiz: could we have
anticipated the detection of
violation?

150. Early detection of violations
If a further p occurs, will be
violated
To bring it back to satis
fi
ed,
we need to do p next

151. Global automaton
Tracks the RV-LTL value for the combination of all constraints

152. 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)

153. Declarative process mining
5. CONCLUSIONS AND EXTENSIONS

154. Conclusions
Managing and mining
fl
exible processes is an open
challenge
Declarative speci
fi
cations to handle
fl
exibility by design
AI and formal methods to the rescue for declarative process
mining
No ad-hoc algorithms, but careful usage and further
development of well-established formalisms and techniques

155. 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

156. Thank you!
claudio.diciccio@uniroma1.it
montali@inf.unibz.it