Towards legally-compliant governmental case work with Dynamic Condition Response Graphs

IT UNIVERSITY OF COPENHAGEN
TOWARDS LEGALLY COMPLIANT GOVERNMENTAL CASE WORK
WITH DYNAMIC CONDITION RESPONSE GRAPHS
HUGO A. LÓPEZ
SØREN DEBOIS
THOMAS T. HILDEBRANDT

WORKFLOW BANKS (ARBEJDSGANGSBANKEN.DK)
2 BEAT’19
López, Hildebrandt, Debois
• Lov om Aktiv beskæftigelsesindsats
(LBK nr 1428 af 14/12/2009)
• Lov om Aktiv socialpolitik
(LBK nr 946 af 01/10/2009)
• Lov om Arbejdsløshedsforsikring
(LBK nr 574 af 27/05/2010)
• Lov om Integration af udlændinge
(LBK nr 1062 af 20/08/2010)
• Lov om Sygedagpenge
(LOV nr 563 af 09/06/2006)
• Retssikkerhedsloven
(LBK nr 1054 af 07/09/2010)
• Datagrundlag
(BEK nr 418 af 23/04/2010)
Compliance?
2008-2013 Ambitious repository with more than 800 municipal workﬂows

2 BEAT’19
(LBK nr 1428 af 14/12/2009)
(LBK nr 946 af 01/10/2009)
(LBK nr 574 af 27/05/2010)
(LBK nr 1062 af 20/08/2010)
(LOV nr 563 af 09/06/2006)
(LBK nr 1054 af 07/09/2010)
• Datagrundlag
(BEK nr 418 af 23/04/2010)
Changes in laws!
Compliance?

2 BEAT’19
(LBK nr 1428 af 14/12/2009)
(LBK nr 946 af 01/10/2009)
(LBK nr 574 af 27/05/2010)
(LBK nr 1062 af 20/08/2010)
(LOV nr 563 af 09/06/2006)
(LBK nr 1054 af 07/09/2010)
• Datagrundlag
(BEK nr 418 af 23/04/2010)
Changes in laws! Process changes?
Compliance?

2 BEAT’19
(LBK nr 1428 af 14/12/2009)
(LBK nr 946 af 01/10/2009)
(LBK nr 574 af 27/05/2010)
(LBK nr 1062 af 20/08/2010)
(LOV nr 563 af 09/06/2006)
(LBK nr 1054 af 07/09/2010)
• Datagrundlag
(BEK nr 418 af 23/04/2010)
Compliance?
Process Changes!

2 BEAT’19
(LBK nr 1428 af 14/12/2009)
(LBK nr 946 af 01/10/2009)
(LBK nr 574 af 27/05/2010)
(LBK nr 1062 af 20/08/2010)
(LOV nr 563 af 09/06/2006)
(LBK nr 1054 af 07/09/2010)
• Datagrundlag
(BEK nr 418 af 23/04/2010)
Compliance?
Process Changes!
Continuous compliance?

OUR DREAM
• To support digitalisation processes to both
accommodate users’ needs and current
practices.
• Realised by providing ﬂexible process
engines that allow for a discretionary
execution in user activities.
•Business process engine should align
executions with requirements coming from
regulations, many of which might change over
time.
3 BEAT’19
ng digitalization of work processes in the Danish industry.
Exformatics MAPS (Italy)
TH Zurich, Switzerland
information Security
& Fabrizio Maria Maggi,
y of Tartu, Estonia
University, Amsterdam
Municipality partners
as early adopters:
Koncern IT - Copenhagen Municipality
IT & Digitalisation,
Syddjurs Municipality
Kammeradvokaten
& Globeteam
EcoKnow: Effective, co-created & compliant
adaptive case management for knowledge workers
adaptable digitalisation of knowledge work processes
g National and EU regulations (e.g. data protection)
ncreased effectiveness and legal compliance
Enabling technologies
shared as open source tools
via the OS2 open source
digitalisation community
2017 30.09.2021
oven Data Science Center
Netherlands

AGENDA
4 BEAT’19
1. What is a (formal) regulatory compliance framework
(RPC)?
2. A declarative approach to RPC.
1. Dynamic Condition Response Graphs as declarative
choreographies.
3. Experience report: Modelling & verifying laws against
processes.
4. Conclusions

1. REGULATORY COMPLIANCE FRAMEWORKS
We conducted a Systematic Literature
Review (SLR) covering different aspects
of regulatory compliance frameworks
using formal models, answering the
following questions:
5 BEAT’19
1.What are the common elements that conform a formal regulatory compliance
framework for process-oriented technologies?
2.How do current technologies formalise real regulatory documents?
3.How do regulatory compliance frameworks improve the behaviour of process
models?
4.How possible is to accommodate changes in laws in current regulatory
compliance frameworks?
5.How mature is the method/tooling available, from the evidence present in
research literature?

6
REGULATORY COMPLIANCE FRAMEWORKSIEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL . X, NO. X, DATE 20XX 3
Index Number of Hits
EBSCO Discovery Service 1.418
Web of Science 17
Scopus 375
JSTOR 87
Science Direct 765
SpringerLink 2.331
Xplore 13
ACM Digital Library 10
Business Source Premier 2
Total Hits 5.018
TABLE II: Results of the manual pilot
and keywords, limiting the search space to content that is most
relevant to the SLR. This functionality was not present in some
of the indexes (e.g.: SPL), increasing the sample with articles that
contain the keywords in their full-text versions but whose topics do
not correspond to the interest in this SLR. The total set of articles
retrieved contained duplicate entries as some meta-searchers index the
same journals than publisher-specific databases (e.g.: SD and SCO
are both owned by Elsevier, and the journals indexed in SD are also
present in SCO). We have decided to allow this as meta-searchers are
likely to include hits in areas not considered in our standard search
procedures (computer science).
III. INCLUSION AND EXCLUSION CRITERIA
This SLR restricted sources to primary studies in formal veri-
fication and business process management. No statistical methods
have been applied in the research. The studies in consideration must
Fig. 2: Construction of the Quasi Gold Standard Dataset
A. Control set
In the development of this SLR we have built a Quasi-Gold-
Standard (QGS) dataset [38]. This involved the construction of a pilot
study and the collection of expert suggestions, as described in Figure
2. The pilot was built on a manual search of all relevant studies in
the following journals published between 2012 and 2017:
• Springer’s Journal of Artificial Intelligence and Law [3].
• Springer’s Journal on Software & Systems [4].
• Elsevier’s Data & Knowledge Engineering [1].
Automated search
Control sample
BEAT’19

6
REGULATORY COMPLIANCE FRAMEWORKS
5018 2283
10492
46
A total of 46 Primary
Studies were identiﬁed
with accuracy of 93,33%
wrt the QGS
BEAT’19

ANATOMY OF A REGULATORY FRAMEWORK
7 BEAT’19
business process monitoring will assess the design of internal controls and serve as an
input to internal controls certification.
Fig. 1. Interconnect of Process Management and Controls Management
Given the scale and diversity of compliance requirements and additionally the fact
that these requirements may frequently change, business process compliance is indeed
a large and complex problem area with several challenges. Following our initial
premise that business and control objectives are (or should be) designed separately,
but must converge at some point, we present below a list of essential methods and
techniques that need to be developed to tackle this overall problem.
2.1 Control Directory Management
Regulations and other compliance directives are complex, vague and require
[1]
S. Sadiq, G. Governatori, and K. Namiri,
“Modelling Control Objectives for Business
Process Compliance,” in Business Process
Management, 2007, pp. 149–164.

ANATOMY OF A REGULATORY FRAMEWORK
7 BEAT’19
the actors’ behavior. On the other hand, governmental
et al. 2012). Normative multi-agent sys
potential approaches for modeling regul
environments where organizational actors ca
as autonomous agents, and regulations can b
the normative constraints directing the be
agents.
In a nutshell, CCCF captures organizati
the notion of agents and captures regulations
of norms (obligations and prohibitions). Mo
not only provides the components for repre
normative constraints but also their compli
To indicate organizational interactions, C
concept of event sequence to represent
Table 1 Governmental regulations and business processes
Governmental regulations Business processes
Issued by legal authorities Designed and implemented by
organizations
National perspective Organizational perspective
Focus on the effects of actions Focus on the process of actions
Increase social welfare; economics,
safety, environmental concern
Increase the efﬁciency of
organizations to achieve
higher organizational beneﬁt
Legal authority Secondary authority
394 AI & Soc (2
[1]
J. Jiang, H. Aldewereld, V. Dignum, S.
Wang, and Z. Baida, “Regulatory
compliance of business processes,” AI &
Soc, vol. 30, no. 3, pp. 393–402, Aug. 2015.
business process monitoring will assess the design of internal controls and serve as an
input to internal controls certification.
Fig. 1. Interconnect of Process Management and Controls Management
Given the scale and diversity of compliance requirements and additionally the fact
that these requirements may frequently change, business process compliance is indeed
a large and complex problem area with several challenges. Following our initial
premise that business and control objectives are (or should be) designed separately,
but must converge at some point, we present below a list of essential methods and
techniques that need to be developed to tackle this overall problem.
2.1 Control Directory Management
Regulations and other compliance directives are complex, vague and require
[1]
S. Sadiq, G. Governatori, and K. Namiri,
“Modelling Control Objectives for Business
Process Compliance,” in Business Process
Management, 2007, pp. 149–164.

FORMAL LANGUAGES AND COMPLIANCE RULES
8 BEAT’19
Logic Based: 40
Process Based: 15
Others: 9

9
PROCESS LANGUAGES USED IN COMPLIANCE VERIFICATION
Logic Based: 3Process Based: 44
BEAT’19
Others: 10

DCR GRAPHS
• A Declarative Business Process Modelling
notation (Hildebrandt & Mukkamala
2010).
• Deﬁnes activities, roles, and behavioural
constraints:
• Conditions
• Responses
• Dynamic inclusion/exclusion.
• State signals whether activities are pending
(!), included, or executed already.
10 BEAT’19
•DCR graphs constitute the formal foundation of
the process engine developed by DCR Solutions

2. FORMALISATION OF LEGALLY-COMPLIANT BUSINESS
PROCESSES
11
Formalisation
of compliance
rules
Formalisation
of Business
Processes
Regulations Choreographies
Compliance 
checking
Matches the speciﬁcation of compliance rules and the executions of business
processes.
- If rules are satisﬁed by all the runs in a choreography, it is compliant, otherwise, it
is in violation with a compliance rule.
BEAT’19

PROCESSES
11
Formalisation
of compliance
rules
Formalisation
of Business
Processes
Compliance 
checking
DCR processes
processes.
BEAT’19

PROCESSES
11
Formalisation
of compliance
rules
Formalisation
of Business
Processes
Compliance 
checking
DCR processes
DCR processes
processes.
BEAT’19

PROCESSES
11
Formalisation
of compliance
rules
Formalisation
of Business
Processes
Compliance 
checking
DCR processes
DCR processes
Process Reﬁnement
processes.
BEAT’19

DCR AS DECLARATIVE CHOREOGRAPHIES
•A formal language is classically a subset of the finite sequences L* of some labels L
(denoting the primitive actions) 
•Formal languages over both finite and infinite sequences are of interest if we want to
specify liveness properties
•The labels of choreographies are interactions among multiple participants, which we
will refer to as roles.
•An (binary) interaction is of the form (a, r1,r2) where a is a basic action, and r1 is the
sending role and r2 is the receiving role. Let Interact be the set of all such binary
interactions.
•An abstract choreography is a language over Interact
•Any favourite notation for specification of languages can be used to specify abstract
choreographies if we choose the labels to be Interact
12 BEAT’19

DCR PROCESSES
13 BEAT’19
Below we introduce the Dynamic Condition Response (DCR) process language.
As already informally described in the introduction, it is based on the notions
of dynamic inclusion and exclusion of labelled events, related by conditions and
response relations introduced in DCR Graphs [29,17].
We assume ﬁxed universes of events E and labels L; each event e 2 E has an
associated label `(e) 2 L. A DCR process [M] T comprises a marking M and a
term T. The syntax of both are given in Fig. 3 below.
T, U ::= f !• e condition
| f • e response
| f + e inclusion
| f % e exclusion
| T | U parallel
| 0 unit
::= t | f boolean value
::= ( , , ) event state
M, N ::= M, e : marking
P, Q ::= [M] T process
Fig. 3. DCR Processes Syntax.
Below we introduce the Dynamic Condition Response (DCR) process language.
As already informally described in the introduction, it is based on the notions
of dynamic inclusion and exclusion of labelled events, related by conditions and
response relations introduced in DCR Graphs [29,17].
We assume ﬁxed universes of events E and labels L; each event e 2 E has an
associated label `(e) 2 L. A DCR process [M] T comprises a marking M and a
term T. The syntax of both are given in Fig. 3 below.
T, U ::= f !• e condition
| f • e response
| f + e inclusion
| f % e exclusion
| T | U parallel
| 0 unit
::= t | f boolean value
::= ( , , ) event state
M, N ::= M, e : marking
P, Q ::= [M] T process
Fig. 3. DCR Processes Syntax.
Syntax:

THE BUYER-SELLER CHOREOGRAPHY
14 BEAT’19
Structured Communication-Centred Programming for Web Services 5
(1) Buyer asks Seller for quote;
(2) Seller replies with a quote;
(3) Buyer accepts or rejects;
(4) In case of acceptance,
(a) Seller orders from Shipper;
(b) Shipper sends back details;
(c) Seller forwards to Buyer.
(5) In case of rejection,
(a) terminate.
accept
quote
quoteCh
+ reject
Buyer Seller Shipper
deliveryCh
details
details
he diagram is ambiguous at the branching (+) actions in (4) and (5): the pur-
ose of such diagrams is to oﬀer an informal overview: they naturally omit de-
ailed control structures (choices, loops, etc.) and manipulation of values/states.
he reason why such global descriptions are practised in engineering is because
hey enable a clear grasp of the whole interaction structure, lessening synchro-
isation and other errors at the design stage.
WS-CDL is intended to extend these virtues of global notations to a full
edged description language. We ﬁnd, through our involvement in its design
rocess, that it is based on two engineering principles: the Service Channel
Principle (SCP) where invocation channels (e.g. a channel at which Buyer

THE BUYER-SELLER CHOREOGRAPHY
14 BEAT’19
Structured Communication-Centred Programming for Web Services 5
(1) Buyer asks Seller for quote;
(2) Seller replies with a quote;
(3) Buyer accepts or rejects;
(4) In case of acceptance,
(a) Seller orders from Shipper;
(b) Shipper sends back details;
(c) Seller forwards to Buyer.
(5) In case of rejection,
(a) terminate.
accept
quote
quoteCh
+ reject
Buyer Seller Shipper
deliveryCh
details
details
he diagram is ambiguous at the branching (+) actions in (4) and (5): the pur-
ose of such diagrams is to offer an informal overview: they naturally omit de-
ailed control structures (choices, loops, etc.) and manipulation of values/states.
he reason why such global descriptions are practised in engineering is because
hey enable a clear grasp of the whole interaction structure, lessening synchro-
isation and other errors at the design stage.
WS-CDL is intended to extend these virtues of global notations to a full
edged description language. We find, through our involvement in its design
rocess, that it is based on two engineering principles: the Service Channel
Principle (SCP) where invocation channels (e.g. a channel at which Buyer
Well-formed process: define role sender-
receiver role dependencies in event flows.

CHOREOGRAPHIES: OPTIONAL BEHAVIOUR
The seller may send a new quote, but it does not have to: 
http://dcr.itu.dk/Workbench/Default/1333479641/4144010668
15 BEAT’19

AFTER REJECTION (MAY BEHAVIOUR)
The quote may be send again, but it does not have to
16 BEAT’19

CHOREOGRAPHIES: MUST BEHAVIOUR
The quote is pending, and it must be executed.
17 BEAT’19

AFTER SECOND STEP (QUOTE)
18 BEAT’19

ENDPOINT PROJECTION (BUYER)
(Safe Distribution of Declarative Processes, SEFM 2011 LNCS 7041)  
19 BEAT’19

ENDPOINT PROJECTION (SELLER)
20 BEAT’19

ENDPOINT PROJECTION (SHIPPER)
Interface event which is an interaction between two other roles: Not well formed! 
21 BEAT’19

DCR CHOREOGRAPHIES VS REGULAR CHOREOGRAPHIES
22 BEAT’19
The nodes of the global graph are
interactions (sender, receiver, message),
their connections are either ﬂows, or
combinations of parallel compositions or
non-deterministic choice.

22 BEAT’19
corresponds to BPMN choreographies,
(and to global session types)

Claim: global graphs are strictly less expressive
than Choreographic DCR graphs.
Global Graph —> DCR:
A global graph can be expressed in a DCR processes should be easy (the mapping from standard
flows is done through conditions+responses, non-determinism via conditions, parallel composition is
homomorphic).
DCR —> Global Graph:
Apparently not possible. Try mapping DCR to asynchronous transition systems and then map those
to the subset of BPMN or prove that it can not be done by finding a pattern of causality/conflict that
can not be expressed
22 BEAT’19
corresponds to BPMN choreographies,
(and to global session types)

2. FORMALISATION: FROM REGULATIONS TO PROCESSES
Knowledge about
the process
23 BEAT’19
Knowledge about
regulatory framework
involved
Non-IT background:
Law, Humanities
Work practices
liable to laws

2. FORMALISATION: FROM REGULATIONS TO PROCESSES
Knowledge about
the process
23 BEAT’19
Knowledge about
regulatory framework
involved
Non-IT background:
Law, Humanities
Work practices
liable to laws
How can we empower her
work practice?
- In the creation of process models
- In the traceability of compliance
requirements

A PROCESS HIGHLIGHTER
López, Debois, Hildebrandt, Marquard. The Process Highlighter: From Text to
Declarative Processes and Back. In Business Process Management. 2018. 66—
70
http://www.dcrgraphs.net

A tool that focus on the transparent alignment
between documentation and process models.
• How/where does my process implements this
feature?
• Why do I require this activity in my process
model?
70

feature?
model?
70
Usage
• Top-down development: from descriptions to
processes

feature?
model?
70
Usage
processes
• Bottom-up compliance: from processes to
regulations.

feature?
model?
70
Usage
processes
regulations.
• Traceability of changes in the process.

feature?
model?
70
Usage
processes
regulations.
• Traceability of changes in the process.
• (ongoing work) generation of runtime
veriﬁcation policies

TESTS
Industrial Test: Case workers at Syddjurs municipality adopted the tool and
created full models for the Danish Consolidation Act on Social Services.
25 BEAT’19
Case studies: GDPR Art. 6 (right to object), 94/46/EC (data protection
directive).
47 Activities
50 Relations
14 Roles
All relation types (condition,
responses, milestone, inclusion,
exclusion) were used

VERIFICATION: PROCESS REFINEMENT
Compliance rules and processes have a different vocabulary:
26 BEAT’19
Compliance
Rule
Term
alignment
Compliance
Rule
Compliance
Rule
Compliance
Rule
Rule
Instances

27 BEAT’19
Compliance
Rule
Term
alignment
Compliance
Rule
Compliance
Rule
Compliance
Rule
Rule
Instances
The customer should have
received an automated email
notiﬁcation at the time his
personal data is outsourced from
the bank to the credit bureau
service.
95/46/EC (data protection directive).
Sect IV, Art. 11. §1
to
a-
te
on
e-
o-
er-
m
au
outsources client
data
postprocessing clerk,supervisor
receive email
notification about
processing of
personal data
customer
checking of the
customer bank
privilege
credit broker
checking of
customers credit
worthiness
credit bureau service
determining the
risk level of the
loan application
manager
checks customer's
credit broker
credit worthiness
postprocessing clerk
objects to
processing loan
application data
customer
delete application
data
bank
cancel loan
application
bank
▼
▼
▼
▼
▼
▼
er
ed
or-
re
he
e1 e2

27 BEAT’19
Compliance
Rule
Term
alignment
Compliance
Rule
Compliance
Rule
Compliance
Rule
Rule
Instances
service.
to
a-
te
on
e-
o-
er-
m
au
outsources client
data
receive email
notification about
processing of
personal data
customer
checking of the
customer bank
privilege
credit broker
checking of
customers credit
worthiness
determining the
risk level of the
loan application
manager
checks customer's
credit broker
credit worthiness
objects to
processing loan
application data
customer
delete application
data
bank
cancel loan
application
bank
▼
▼
▼
▼
▼
▼
er
ed
or-
re
he
e1 ︎→ f1 : “(credit broker) sends
notiﬁcation email about processing of
personal data”
e2 ︎→ f2: “(supervisor) outsources
credit check”
e2 ︎→ f2′ : “(post-processing clerk)
outsources credit check”
e1 e2

27 BEAT’19
Compliance
Rule
Term
alignment
Compliance
Rule
Compliance
Rule
Compliance
Rule
Rule
Instances
service.
to
a-
te
on
e-
o-
er-
m
au
outsources client
data
receive email
notification about
processing of
personal data
customer
checking of the
customer bank
privilege
credit broker
checking of
customers credit
worthiness
determining the
risk level of the
loan application
manager
checks customer's
credit broker
credit worthiness
objects to
processing loan
application data
customer
delete application
data
bank
cancel loan
application
bank
▼
▼
▼
▼
▼
▼
er
ed
or-
re
he
e1 ︎→ f1 : “(credit broker) sends
notiﬁcation email about processing of
personal data”
e2 ︎→ f2: “(supervisor) outsources
credit check”
e2 ︎→ f2′ : “(post-processing clerk)
outsources credit check”
Inst(RC2) =
{[ f1 : (⊥,⊤,⊥),
f2 : (⊥,⊤,⊥)]
f1→•f2 || f1•→f2,
[ f1 : (⊥,⊤,⊥),
f2′ :(⊥,⊤,⊥)]
f1→•f2′ || f1•→f2′
}
e1 e2

REGULATORY COMPLIANCE
Defined in terms of Process Refinement:
28 BEAT’19
(Refinement). Let Instance, Spec be DCR processes. We say that
Spec is a refinement of Instance (written Spec ⊑ Instance) iff
lang(Spec)⇂alph(Instance) ⊆ lang(Instance).
We say that Spec refines Instance iff Instance⊕Spec ⊑ Instance.
Works for safety and
liveness properties

28 BEAT’19
liveness properties
⊕ checks if markings for
Instance and Spec
agree on their overlap

28 BEAT’19
(Compliance). Let Plaw and Spec be two DCR processes*. We say that Spec is
compliant with Plaw (written Spec ◁ Plaw)if ∀Pi ∈ Inst(Plaw), Spec reﬁnes Pi.
liveness properties
Instance and Spec

28 BEAT’19
(Compliance). Let Plaw and Spec be two DCR processes*. We say that Spec is
compliant with Plaw (written Spec ◁ Plaw)if ∀Pi ∈ Inst(Plaw), Spec reﬁnes Pi.
Theorem (Compliance checking is decidable). Given two DCR Processes* Plaw,
Spec. Checking Spec ︎◁Plaw is decidable.
liveness properties
Instance and Spec

CONCLUSIONS & FUTURE WORK
•Some compliance rules refer more than just event dependencies.
•ISO 27002-10.1.3 Segregation of duties.
•Data-dependent compliance rules.
•Implementation of Process Refinement
•Refinement does not scale well in these cases. Runtime Verification is currently
being explored.
•Structured Data + Types.
29 BEAT’19
•We showed a methodology for regulatory compliance of business processes
•Based on Declarative choreographies (DCR graphs)
•With a user base with little formal-methods background.
•Yet enjoying the benefit of formal verification.
What is next?

Towards legally-compliant governmental case work with Dynamic Condition Response Graphs

More Related Content

Similar to Towards legally-compliant governmental case work with Dynamic Condition Response Graphs (20)

Recently uploaded (20)

Towards legally-compliant governmental case work with Dynamic Condition Response Graphs