The document discusses an algorithm for ensuring consistency in declarative process discovery, highlighting how to identify and address conflicting constraints within event logs. It emphasizes the importance of safe constraints with 100% support and presents a systematic methodology for handling constraints to prevent inconsistencies in discovered process models. Limitations and future work are noted, including potential applications for mixed declarative-imperative models and user-defined criteria for constraint management.

1. Ensuring Model Consistency in
Declarative Process Discovery
Claudio Di Ciccio, Fabrizio Maria Maggi, Marco Montali and Jan Mendling
13th International Conference on Business Process Management
Innsbruck, Austria
claudio.di.ciccio@wu.ac.at

2. Foreword
Event logs
Process discovery
Declarative process discovery
SEITE 2

3. The event log
Process model
SEITE 3

4. The event log
Process instance Event log
Trace
SEITE 4

5. The event log
EventTask
Process instance Event log
Trace
SEITE 5

6. The event log
SEITE 6
Event

7. The event log
SEITE 7
Event

8. The event log
SEITE 8
Event

9. The event log
Process instance Event log
Trace
SEITE 9

10. The event log
SEITE 10
Event

11. The event log
SEITE 11
Event

12. The event log
SEITE 12
Event

13. The event log
SEITE 13
Event

14. Process discovery
SEITE 14

15. Process discovery
SEITE 15
?

16. Mining flexible processes

17. Declarative process discovery
SEITE 17
?
Objective: understanding the
constraints that best define
the allowed behaviour of the
process behind the event log

18. Declarative modelling of
processes
 Usage of constraints
 “Open model”
 Declare
 state-of-the-art language
If A is performed,
B must be performed,
no matter if before or afterwards
(responded existence)
Whenever B is performed,
C must be performed afterwards
and B can not be repeated
until C is done
(alternate response)
SEITE 18

19. Declare:
existence templates
SEITE 19
Existence(n, A)
Activity A occurs at least n times in the process instance
BCAAC ✓ BCAAAC ✓ BCAC ✗ (for n = 2)
Absence(A)
Activity A does not occur in the process instance
BCC ✓ BCAC ✗
Absence(n+1, A)
Activity A occurs at most n+1 times in the process instance
BCAAC ✗ BCAC ✓ BCC ✓ (for n = 2)
Exactly(n, A)
Activity A occurs exactly n times in the process instance
BCAAC ✗ BCAAAC ✗ BCAC ✗ (for n = 2)
Init(A)
Activity A is the first to occur in each process instance
BCAAC ✗ ACAAAC ✓ BCC ✗
Absence(2, A) ≐ AtMostOne(A)
Existence(1, A) ≐ Participation(A)

20. Subsumption hierarchy of
relation Declare templates
SEITE 20

21. Declare: Forward-unidirectional
relation constraint templates
RespondedExistence(A, B)
If A occurs in the process instance, then B occurs as well
CAC ✗ CAACB ✓
BCAC ✓ BCC ✓
Response(A, B)
If A occurs in the process instance, then B occurs after A
BCAAC ✗ CAACB ✓
CAC ✗ BCC ✓
AlternateResponse(A, B)
Each time A occurs in the process instance, then B occurs
afterwards, before A recurs
BCAAC ✗ CAACB ✗ CACB ✓
CABCA ✗ BCC ✓ CACBBAB ✓
ChainResponse(A, B)
Each time A occurs in the process instance, then B occurs
immediately afterwards
BCAAC ✗ BCAABC ✗ BCABABC ✓
Activation Target

22. Declare: Backward-unidirectional
relation constraint templates
RespondedExistence(B, A)
If B occurs in the process instance, then A occurs as well
CAC ✓ CAACB ✓
BCAC ✓ BCC ✗
Precedence(A, B)
B occurs in the process instance only if preceded by A
BCAAC ✗ CAACB ✓
CAC ✓ BCC ✓
AlternatePrecedence(A, B)
Each time B occurs in the process instance, it is preceded by A
and no other B can recur in between
BCAAC ✗ CAACB ✓ CACB ✓
CABCA ✓ BCC ✗ CACBAB ✓
ChainPrecedence(A, B)
Each time B occurs in the process instance, then B occurs
immediately beforehand
BCAAC ✗ BCAABC ✗ CABABCA ✓
Target Activation

23. Declare:
Coupling relation templates
CoExistence(A, B)
If B occurs in the process instance, then A occurs, and viceversa
CAC ✗ CAACB ✓
BCAC ✓ BCC ✗
Succession(A, B)
A occurs if and only if it is followed by B in the process instance
BCAAC ✗ CAACB ✓
CAC ✗ BCC ✗
AlternateSuccession(A, B)
A and B occur in the process instance if and only if the latter
follows the former, and they alternate each other in the trace
BCAAC ✗ CAACB ✗ CACB ✓
CABCA ✗ BCC ✗ CACBAB ✓
ChainSuccession(A, B)
A and B occur in the process instance if and only if the latter
immediately follows the former
BCAAC ✗ BCAABC ✗ CABABC ✓
Target Activation
Activation Target

24. Declare:
negative relation constraints
NotCoExistence(A, B)
A and B never occur together in the process instance
CAC ✓ CAACB ✗
BCAC ✗ BCC ✓
NotSuccession(A, B)
A can never occur before B in the process instance
BCAAC ✓ CAACB ✗
CAC ✓ BCC ✓
NotChainSuccession(A, B)
A and B occur in the process instance if and only if the latter
does not immediately follows the former
BCAAC ✓ BCAABC ✗ CBACBA ✓
Target Activation
Activation Target

25. Mining declarative processes:
ingredients
“Submit draft”,
“Write deliverable”,
“Organise agenda”,
…
SEITE 25
a,
b,
c,
…
Activities Process alphabet

26. Mining declarative processes
RespondedExistence(a,b) ?
RespondedExistence(a,c) ?
…
Response(a,b) ?
Response(a,c) ?
…
SEITE 26
• Support:
fraction of cases fulfilling the constraint
• Confidence:
support scaled by fraction of traces in
which the activation occurs
• Interest factor:
confidence scaled by fraction of traces in
which the target occurs
Support Conf. I.F.

27. Mining declarative processes
RespondedExistence(a,b) ?
RespondedExistence(a,c) ?
…
Response(a,b) ?
Response(a,c) ?
…
SEITE 27
Support Conf. I.F.

28. Mining declarative processes
RespondedExistence(a,b) 
RespondedExistence(a,c) ?
…
Response(a,b) ?
Response(a,c) 
…
SEITE 28
Support Conf. I.F.

29. Mining declarative processes
RespondedExistence(a,b) 
RespondedExistence(a,c) ?
…
Response(a,b) 
Response(a,c) 
…
SEITE 29
Support Conf. I.F.

30. Mining declarative processes
RespondedExistence(a,b) 
RespondedExistence(a,c) 
…
Response(a,b) 
Response(a,c) 
…
SEITE 30
Support Conf. I.F.

31. Mining declarative processes
RespondedExistence(a,b)
RespondedExistence(a,c) 
and
Response(a,b) 
Response(a,c)
and
…
SEITE 31

32. From constraints-based model
to FSA
RespondedExistence(a,b)
RespondedExistence(a,c) 
and
Response(a,b) 
Response(a,c)
and
…
SEITE 32
[^a]*((a.*b.*)|(b.*a.*))*[^a]* [^a]*(a.*c)*[^a]*

Regular
Expression
Deterministic
Finite
State
Automaton

33. To be kept in mind
RespondedExistence(a,b)
RespondedExistence(a,c) 
and
Response(a,b) 
Response(a,c)
and
…
SEITE 33
[^a]*((a.*b.*)|(b.*a.*))*[^a]* [^a]*(a.*c)*[^a]*

Regular
Expression
Deterministic
Finite
State
Automaton

34. So far, so good
What is the problem?
SEITE 34

35. While mining a real-life log…
 Support threshold: 0.85
 Confidence threshold: 0.25
 Interest factor threshold: 0.25
SEITE 35

36. While mining a real-life log…
SEITE 36

37. Time to challenge the X
SEITE 37


38. Time to challenge the X
Loading…
SEITE 38

39. The result
SEITE 39

40. The problem
 When support threshold is lower than 100%,
constraints can be valid through most of the log, though being in conflict
 Example: an event log consists of two traces:
1. <a, b, a, b, a, b, c>
2. <a, b, a, b, a, c>
 Support threshold: 0.7
• a is always the first
 Init(a)
• c is always the last
 End(c)
• In 6 cases over 8 (75%), a and c do not directly follow
each other
 NotChainSuccession(a,c)
• In 5 cases over 7 (71.143%), b and c do not directly follow
each other
 NotChainSuccession(b,c)
SEITE 40

41. The problem
 When support threshold is lower than 100%,
constraints can be valid through most of the log, though being in conflict
 Example: an event log consists of two traces:
1. <a, b, a, b, a, b, c>
2. <a, b, a, b, a, c>
 Support threshold: 0.7
• a is always the first
 Init(a)
• c is always the last
 End(c)
• In 6 cases over 8 (75%), a and c do not directly follow
each other
 NotChainSuccession(a,c)
• In 5 cases over 7 (71.143%), a and b do not directly follow
each other
 NotChainSuccession(b,c)
 Question: what can be done right before c?
 inconsistency!
SEITE 41

42. The problem
 When support threshold is lower than 100%,
constraints can be valid through most of the log, though being in conflict
 How to trust a discovery algorithm that can return inconsistent models?
SEITE 42

43. The solution
Cross-product of automata
SEITE 43

44. The solution
 Rationale:
1. How to find inconsistencies among constraints?
 Use the automaton-based model for constraints
 Do cross-product automata recognise the empty
language?
2. How to search the inconsistencies?
 Exploit:
a) The product operation between automata
b) The hierarchy of Declare templates
 Guideline:
 Preserve the most meaningful constraints
SEITE 44

45. The algorithm /1
1. Divide the constraints
having a support of
100% from the rest
 Those that have a
support of 100% cannot
contradict each other
 In other words, we
consider them “safe”
SEITE 45
 NotChainSuccession(a, c) 0.75 0.75 0.75
 Response(a, b) 0.83 0.83 0.83
 ChainSuccession(b, a) 0.72 0.72 0.72
 ChainResponse(b, a) 0.80 0.80 0.80
 ChainSuccession(a, b) 0.91 0.91 0.91
 NotChainSuccession(b, c) 0.71 0.71 0.71
 …
 Init(a) 1.00 1.00 1.00
 Participation(b) 1.00 1.00 1.00
 AtMostOne(c) 1.00 1.00 1.00
 End(c) 1.00 1.00 1.00
 ChainPrecedence(a, b) 1.00 1.00 1.00
 CoExistence(a, b) 1.00 1.00 1.00
 …

46. The algorithm /2
2. Sort constraints having
a support of less than
100% (“unsafe”) by:
i. Support (desc.)
ii. Confidence (desc.)
iii. Interest Factor (desc.)
SEITE 46
 Init(a) 1.00 1.00 1.00
 Participation(b) 1.00 1.00 1.00
 AtMostOne(c) 1.00 1.00 1.00
 End(c) 1.00 1.00 1.00
 ChainPrecedence(a, b) 1.00 1.00 1.00
 CoExistence(a, b) 1.00 1.00 1.00
 …
 ChainSuccession(a, b) 0.91 0.91 0.91
 Response(a, b) 0.83 0.83 0.83
 ChainResponse(b, a) 0.80 0.80 0.80
 NotChainSuccession(a, c) 0.75 0.75 0.75
 ChainSuccession(b, a) 0.72 0.72 0.72
 NotChainSuccession(b, c) 0.71 0.71 0.71
 …
sort

47. The algorithm /3
3. Create the automaton
representing the safe
constraints, as the
product of the single
constraints’ automata
 Initialise the
“product automaton”
SEITE 47



…
Init(a) Participation(b)
ChainPrecedence(a,b)

48. The algorithm /3
3. Create the automaton
representing the safe
constraints, as the
product of the single
constraints’ automata
 Initialise the
“product automaton”
SEITE 48

49. The algorithm /4
For every unsafe-constraint
automaton, following the
order of step 2:
4. Intersect the product
automaton with the
unsafe constraint
SEITE 49

NotChainSuccession(a,c)

50. The algorithm /4
4. (…cnt)
 If the result accepts only
an empty language:
 discard it if no constraint
is higher in the hierarchy
 relax the constraint
otherwise, and repeat
step 4.
 Else, include the unsafe-
constraint in the list of
returned constraints,
and save the product
automaton
SEITE 50

…
NotChainSuccession(b,c)

51. The algorithm /4
4. Return the process
model made of:
 safe constraints, and
 unsafe constraints not
leading to automata
recognising empty
languages
SEITE 51

52. The algorithm: recap
SEITE 52

Init(a)
Participation(b)
AtMostOne(c)
End(c)
ChainPrecedence(a, b)
…
ChainSuccession(a, b)
Response(a, b)
ChainResponse(b, a)
NotChainSuccession(a, c)
ChainSuccession(b, a)
NotChainSuccession(b, c)
…
sort
…
…
1

53. The algorithm: recap
SEITE 53

Init(a)
Participation(b)
AtMostOne(c)
End(c)
ChainPrecedence(a, b)
…
ChainSuccession(a, b)
Response(a, b)
ChainResponse(b, a)
NotChainSuccession(a, c) 
ChainSuccession(b, a)
NotChainSuccession(b, c)
…
sort
…
…
1
2

54. Conclusion
Which were the conflicting constraints in the log?
What is more in the paper
Limitations and future work

55. SEITE 55

56. Which were the conflicting
constraints in the log?
1. NotSuccession(send meeting, organize agenda)
2. NotChainSuccession(send draft, send deliverable)
3. Succession(send draft, submit report)
SEITE 56

57. SEITE 57

58. Conclusions, limitations and
future work
We have presented an algorithm that automatically finds
inconsistencies in a mined Declare model (more in the paper)
 The checks are purely based on operations over automata
 Optimisations exploit Declare semantics
 http://github.com/cdc08x/minerful
Limitations:
 The order in which the constraints are checked deeply affects the returned
result
 Performances are heavily affected by the interplay of constraints
Future work:
 Application of the technique over mixed declarative-imperative models
 User-defined criteria for constraints sorting/selection
 Heuristics for a more efficient exploration of the search space are currently
under investigation
 http://www.promtools.org/prom6/nightly
SEITE 58

59. Ensuring Model Consistency in
Declarative Process Discovery
Claudio Di Ciccio, Fabrizio Maria Maggi, Marco Montali and Jan Mendling
13th International Conference on Business Process Management
Innsbruck, Austria
claudio.di.ciccio@wu.ac.at

60. Ensuring Model Consistency in
Declarative Process Discovery
Claudio Di Ciccio, Fabrizio Maria Maggi, Marco Montali and Jan Mendling
13th International Conference on Business Process Management
Innsbruck, Austria
Extra slides deck

61. The application of the method
to minimise the model
 Rationale:
1. How to find redundancies among constraints?
 Use the automaton-model correspondence
 Same language recognised after the product?
 Main difference with the inconsistency-
checking algorithm
 Constraints having support 100% are checked for
redundancies
 More details in the paper
SEITE 61

62. The application of the method
to minimise the model
SEITE 62
BPIC 2012

63. The algorithm /4
4. Return the process
model made of:
 safe constraints, and
 unsafe constraints not
leading to automata
recognising empty
languages
SEITE 63
<a, b, a, b, a, b, c>
<a, b, a, b, a, c>