1. The Agile Project (late 2008-2012) Traceability and change in legal requirements engineering Building bridges between three knowledge domains Alexander Boer aboer@uva.nl Tom van Engers Saskia van de Ven

2. Project partners  Academic input: Leibniz Center for Law (University of Amsterdam) and Technical University Delft  Technology input and product development: BeInformed and O&I  User input and validating pilot studies: Immigration & Naturalization Service (IND) and Dutch Tax and Customs Administration (Belastingdienst)

3. About the project  Agile: Advanced Governance of Information services through Legal Engineering  Goal: Increase the agility of organizations that deliver law-governed services in a network environment  Products: 1.two PhD theses (Saskia & Yiwei) 2.design methodology & prototype specification language 3.prototype distributed service-oriented architecture & supporting tools

4. Two PhD theses  Leibniz Center: accounting for how law is implemented in the organization (Saskia van der Ven)  Delft University: accounting for how rational agents use the law, and the way it is implemented (Yiwei Gong)  Effectiveness and efficiency  Evasive behaviour of clients (taxpayers, immigrants)  Intentions of other network partners (employers, family members, etc.)

5. Domains for examples and pilots  Sales transactions (private law)  Legislating (reusability)  Knowledge worker permits (IND)  Involves income criterium, potential for interaction with client, Belastingdienst and employer in application process  Income and wages (Belastingdienst)  One person business (ZZP) wages tax support pilot

6. Agility and Traceability

7. Two aspects of agility  Quick adaptation of the organization  Processes, services, knowledge resources are robustly designed  Decoupling: Separation of concerns in specification and implementation  Quick impact analysis  Which processes, services, knowledge resources, etc are affected by a change?

8. Legal impact analysis  Is a service, process, or resource redesign legally speaking effective and is it compliant?  Sources of law: legislation, case law, organizational guidelines  What problems and opportunities are created by a change in the sources of law for existing services, processes, and resources?  Compliance, efficiency, enforceability, changing patterns of service delivery (chain partners) and consumption (taxpayers, immigrants)

9. Abilities to develop in Agile 1.monitoring and managing the sources of law relevant to the organization, distinguishing versions of these sources of law, and determining the applicability of rules originating from these sources of law in time and to categories of cases; 2.maintaining traceability from sources of law to implementation knowledge resources without ending up with Gordian provenance link knots; 3.efficiently and quickly justifying existing business processes, data in databases, etc, justified by old law, in new law if possible; 4.anticipating the effects of changes in law not directly addressing the organization itself to service delivery and consumption by network partners and clients; 5.developing an organizational structure, IT infrastructure, other resources, and – importantly - network arrangements that are robust in the face of changes to the law; and 6.delivering timely, constructive, and accurate feedback to the legislator.

10. Traceability and Impact Analysis I  The main knowledge resource of legal impact analysis: Provenance links from implementation knowledge resources to sources of law  Provenance = origin, history  Tends to either be very incomplete or to degenerate into a Gordian knot  Domain-specific obligations are more likely to be explicitly linked than ability-creating rules, even though the latter are more likely to cause big changes if they are changed!

12. 11/19/2015blad 12 Source of law Implementation knowledge model Intermediate representation At the IND

13. Traceability and Impact Analysis II  Decoupling approach: simple inert concept-centered requirements model intermediating between sources of law and implementation resources  New staff uses it to acquire domain knowledge  However, it plays no role in impact analysis and implementation  Determination of applicability of rules is hard  Approach: rule applicability reasoning & services simulation using an improved requirements model

14. Approach on the conceptual level  Improving agility of organizations by 1.Ontological stratification and supervenience: rigid identity criteria distinguish the legal institutional domain from its implementation in the organization 2.Versioning (and identification) of sources of law (MetaLex) and of implementation resources 3.Create a mediating Agile knowledge resource that distinguishes three knowledge domains 4.Traceability based on rules bridging knowledge domains and on concepts describing the knowledge domains

15. Three knowledge domains supervenient on eachother

16. Legal theory input  (Re)presentation: Some medium (re)presents a proposition or rule  Constitutiveness: Some (brute) thing counts as a legal thing according to some rule  Normativity: action counts as a violation  Abstraction: Every legal thing must be constituted by some thing to exist  Applicability: Some rule applies to a thing  Evidence: something is evidence for a proposition

17. Isolating changes in three knowledge domains

22. Interface to other knowledge resources  Specifications, logical models, knowledge base rules, schemas, etc, used in the organization are not in the bottom layer, but share (contextualized interpretations of) concepts, rules, individuals, etc with the bottom layer. 1.To share is to use the same IRIs for reference, or to be able to resolve the IRI in one model to the corresponding one in the other. 2.Agile resources minimally interfere with technology choices in the organization 3.Import/export functionality is however very desirable, in particular for knowledge bases 4.In usage, knowledge is contextualized to problem setting (assumptions etc.) and restricted to tool/language- specific expressive fragment and semantics (datalog, epistemic interpretation, negation as failure)

23. “Brute reality”  business processes: when, why, and how to react when citizens want to interact with the organization?  citizen life event modeling: when and why do citizens want/have to interact with the organization?  services: Description of transaction script from perspective of client role focusing on the changes (on the service target) valuable to the client, as advertized by a provider capable of bringing about those changes

24. Service and business process patterns  legal services: the service target is the legal position of the client: the value provided is an improvement of the client's position, and intended by the client  Legal position analysis of transaction scripts based on Hohfeldian relations: bundles of duties/rights and powers/liabilities  Service notion adds provider/client roles  Reuse business ontologies?

25. Example rules Demonstration of how rules define the interface between domains and exist within domains

26. Example  Rules:  t1 The publication of a text presenting a rule counts as the creation of that rule.  t2 Rule t1 applies to text published by a rule maker.  t1 represents legal rule r1 and t2 represents legal rule r2  logical rules a1 and a2 (in OWL2) represent their meaning to agents that have to apply them

27. Rules in Agile  Legal rules are distinguished from (presenting) text and from (representing) logical axioms  Exist in institutional reality,  Exist in time, and  Are Traceable  to expressions of sources of law (MetaLex)  representation and applicability  to their use in implementation resources  contextualization of the meaning of rules  Logical rules are about three layers of reality and the interfaces between them

28. Example OWL2 rule a1: “The publication of a text presenting a rule counts as the creation of that rule.” if Publication that (resultsIn some (Text that (represents some Rule))) then (constitutes some Creation that (resultsIn some Rule) and (applicable value r1)))

29. Rule 1: intended models Publication Creation Text Rule resultsIn represents constitutes {t 1,t 2 } {r 1,r 2 } applicable: {r 1 }

30. Other example OWL2 rule a2: Rule t1 applies to text published by a rule maker. if Rule that (representedBy some (metalex:Expression that(metalex:realizes value t1))) then (appliesTo all (Creation that (actor some RuleMaker) and (applicable value r2)))

31. FRBR bibliographic layers in CEN MetaLex

32. Applicability rules  If t1 changes (a new expression of the work)  A new legal rule presented by the new expression is created  And rule r2 automatically applies to it because it applies to all rules presented in expressions of t1

33. Applicability and defeasibility  Two kinds of applicability  Actual: if the rule produces a legal effect it is/was applicable  Potential: If it will produce a legal effect if applied it is applicable  Defeasibility and whole OWL2 axioms  no special conditional but belief base revision  presents a challenge in accounting for its semantics  Purpose is to find problems rather than solve them

34. To do in the next years  Versioning methodology for all resources  MetaLex for sources of law  Making the modeling simple using patterns  “Model sentences” in the law  Reusable service, transaction, process, information carriers patterns (and agents)  Easy to use model editor  Develop agent simulation architecture for  Impact analysis  Simulating alternative implementations