Drafting laws is not just translating do's en dont's into obligations and prohibitions. The complex structures of interrelated acts and sections have to be modelled as well. Drafting legislation exists of numerous additions and deletions of texts. When a legal drafter adds an obligation, the alteration may effect the boundaries of a prohibition. This paper discusses modelling norms, and describes methods for regulation drafting, repair and refinement. Each version is tested on a legal knowledge based system in order to compare with the desired behaviour. In this paper the design of an intelligent toolset is presented, both for drafting and refinement, as well as for application simulation.
1. Introduction
Drafting legislation resembles in a way the cyclic process of system design. Legal drafters have a common goal of intended behaviour, whereas system designers have to design a system that meets its design criteria [Breuker and Wielinga, 1989]. Software engineering cycles ensure that the system design is built up gradually and correctly. In legal drafting we want to use this method as well. The point is however, that we don't need to design an entire LKBS (legal knoweldge based system) for each new law domain. General legal problem solving behaviour has been implemented in legal knowledge based systems, for instance on the domains of industrial property [Nitta and Nagao, 1985], income tax [Sherman, 1987], benefit law [Nieuwenhuis, 1989] and traffic law [denHaan and Breuker, 1991]. The core of legal problem solving is similar for all law domains. An important difference in problem solving behaviour exists for different types of legal knowledge based systems built to perform different dedicated roles. For applying law, advice, planning and comparison specific reasoning modules are to be desired. Therefore, in the next section the design of a legal drafting environment is outlined, which is based on an existing KBS. Section 3 describes how regulations can be drafted and refined, using the representation and reasoning knowledge from the given LKBS designed for law application. Consequently, 3.2 represents the core of this research. In section 4 is shown how the relations between models and legal sources play a role in regulation refinement. The last section summarises.
2. Selecting a support environment
Drafting a certain type of legislation can only be supported when it exhibits a type of reasoning which is present in an operational LKBS. In figure 1 an architecture in this fashion for application of law is given as used in the traffic law system.
In this paper the base LKBS chosen is the TRACS architecture. In figure 2 the general design of a drafting environment is given. The legal reasoning modules of {\sc tracs} are loaded into the LKBS shell. The LKBS shell (left in figure 2) provides the drafting and testing environment for legislation under development. Only validated legal reasoning procedures are used to build the reasoning modules of an empty LKBS, because the drafters are not allowed to change the contents of standard legal reasoning modules. Any changes to overcome drafting errors have to be performed within the knowledge bases of the LKBS.
When legislation concerning law application has to be drafted, only the legal sources have to be modelled, and moulded into the specific reasoning architecture. To accommodate the TRACS architecture to law application in a new domain, the knowledge bases have to be filled with the domain and regulation knowledge of that domain. The structure of the legal reasoning modules remains unchanged. The best way is to use an LKBS that has already proven its merits, so its reasoning modules correctly model the required type of legal reasoning. To assess its correctness, legal reasoning itself can be tested by constructing a set of test cases such that the results of law application can be predicted exactly. This type of testing scrutinises the legal reasoning structure prior to drafting and testing new legislation. For instance, an artificial regulation can be drafted, in which exceptions and exclusions are embedded. When this law is presented to legal experts in order to solve special cases, the experts have to exhibit generally the same reasoning patterns and provide exactly the same answers. In [Svensson et al., 1992] the ExpertiSZe system is described that analyses the automatic application of the social security law in order to study its consistency and social and economic impact, based on the micro-simulation method further elaborated in [Svensson, 1993]. In this approach we want to go further than testing by application. Inspired by general AI-techniques such as knowledge base refinement [Aben and van Someren, 1990], we want to give legal drafters interactive methodological support.
2.1. Using intelligent tools for drafting legislation
Separated representation of legal knowledge and world (domain) knowledge (see [BenchCapon, 1989] and [Breuker and den Haan, 1991]) implies that the supporting intelligent modules are also divided over these two categories. There may be special dedicated tools in the fashion of Shelley [Anjewierden, et al., 1992] for editing domain information, and for editing the regulations themselves. In the former, constructs for typing information are provided, and in the latter legal expertise such as the structure of paragraphs and sections is supported. Drafting new regulations may start from scratch [den Haan, 1992]. When a law of a certain domain is to be drafted, the domain knowledge is modelled and represented in the domain knowledge base. Only world knowledge is represented here, not legal information, i.e. conceptual knowledge which is needed to interpret the law. If an existing law is altered, then existing representations and concepts can be used during the editing phase. When a version of the law is completed, test cases are imported into the LKBS shell. The resulting judgements are examined, and yield a model of behaviour as described by the current regulation. Only when this model is compared to the intended behaviour, i.e. the external drafting requirements, flaws can be detected. At this point, the editing/testing cycle starts again. When the modelled behaviour matches the intended behaviour, the drafting cycle has been completed, and the knowledge bases are filled with the final version.
2.2. Testing
The draft of the law text is tested by application to a set of given test cases. This yields a set of judgements. This process is exactly the same as the standard law application. The intended behaviour has been used on beforehand to determine the intended judgements the LKBS should reach. By examining the intermediate judgements and the underlying normative structures in the law, the behaviour as prescribed by the current version of the law text is created. Comparing this model to the intended behaviour may result in a series of flaws. The user can edit (new) sections, or bearing in mind the intended behaviour, the user can then debug the specific sections in the law responsible for the errors (this is described in more detail in paragraph 3). The cycle of editing, testing and debugging goes on until the judgements model equals the intended behaviour.
To test laws, a given set of situation descriptions is compared to the new regulations. The generic situations are constructed using the formulations in the regulations themselves. When all descriptions in the new regulations are gathered, this gives an overview of the real world behaviour the law can reason about. Anything outside this scope cannot be tested, because terms unknown to the system cannot be compared and related to its domain knowledge. It is also possible to generate a set of test situations. Terms in the description of the intended behaviour, possibly complemented by knowledge about the structure of legal concept types and domain concept types may give a situation generator directions about the construction of possible combinations for testing situations.
A set of applicable rules is constructed for each situation. The definition of a legal conflict is that a case gives rise to an inconsistent set of conclusions, i.e. the selected (applicable) legal rules have contradictive conclusions. Since the intended contradictions have been filtered out by the meta-rules of the LKBS, each remaining contradiction has to be studied. Repairing an unintended contradiction is guided by the meta-rules as well. Therefore, the following section first describes meta-rules for specificity as well as rule application, and then presents methods for repair and refinements.
3. Repair and refinements in regulations
Even when law texts only consist of obligations, contradictions may occur because the obliged situations themselves may be incompatible. Paragraph 3.1 suggests that some of these errors originate in faulty definitions of the meta-rules which result in the selection of the wrong section. On the other hand, paragraph 3.2 explains that also the definitions of the sections themselves may be culprits.
3.1. Controlling meta-rule application
When meta-rules solve the conflict by preferring one of the contradicting rules, an exception structure was presumably its source. In legal theory the following meta-rules are applied to solve conflicts [Hamfelt and Barklund, 1990]: Lex specialis performs a standard resolution of conflicts by selecting the most specific rule. Solutions for determining the specificity of legal rules and legal concepts can be found in the areas of set theory, taxonomic relations and abstraction hierarchies. Lex superior states that rules from distinctive law texts applying to the same area are distinguished with respect to the importance of the legislative body, and lex posterior allows that rules are selected on grounds of chronology. Lex specialis handles most of the conflicts, because exception structures are based on the notion of specificity. Therefore, operationalising lex specialis has a strong priority in modelling legal reasoning. The rules for specificity (A - B: A is more specific then B) as laid out in table 1 are based largely on the notion of subsumption (A £ B: A is a subtype of B).
A and B are the condition sets of legal rules and a, b are terms of resp. type t(a), t(b). Condition sets are used to determine the applicability of rules, so examining the specificity relation of two rules boils down to comparing their condition sets. Whenever conditions entail, subsume or are a subset of another condition set, then the other is more specific. The subsumption relations between condition sets are defined over predicates M,N and terms. When at least one of the constituents of a conditions set (or likewise of a predicate) subsumes a constituent in the other, on the condition that all other constituents are themselves not subsumed. The lowest level to decide subsumption is typological information which originates in the domain descriptions in the world KB. Repairs to unintended conflicts may now be solved either by changing the typological information, by changing a meta-rule or by adding a new specific meta-rule. Meta-rules may be as specific as ``In situation S select section N''. Note that this type of mending yields a complex patchwork of repairs.
To be able to transform legal rules, their definition must be formalised:
where all x are bound in one of M(1),...,M(m), N,...,N(n). In this formula the predicates M,N denote references to world knowledge (relations between variables or other predicates). Each predicate may have a number of arguments containing variables a. The a are typed variables, e.g. V:vehicle. The operators (o) may be either conjunctive (˙) or disjunctive (/). The M describe the necessary conditions for a legal rule and the N contain the juridical statements about the agent(s) in question. The arrow means that the juridical statements follow necessarily when the conditions are applicable.
Table 2 gives a formalization of the determination of the applicability of rules. The rule is applicable when all its terms in the condition are supertypes of concepts in the situation (or equal). Sit(M(i)) is an abbreviation of the fact that M(i) is a member of the given situation description (case at hand), and likewise A(N(j)) for N(j) in condition set A.
Removing all unintended inconsistencies from law texts can be performed in a positivistic way by legal knowledge based systems that operate purely on the basis of the law text and legal meta-rules. The following paragraph shows that impasses can be solved by abstracting or specifying concepts or rules according to the lex specialis.
3.2. Specialisation and generalisation
Unintended conflicts may have occurred when in the complex structure of norms sections contain too weakly or too strongly posed elements. Their definitions are not blindly removed or altered: the definitions are reused as input to the tuning mechanisms. In knowledge acquisition research attention is currently given to the aspect of reusability. In the KADS project (ESPRIT Project P5248, KADS-II) a library of primitive inferences supports the knowledge engineer. They serve as initial building blocks in system specifications. In [Aben, 1993] a formalization of inference schemes is given, as well as tuning mechanisms to transform given inferences to meet more specific or general requirements. In this way, inferences can either be directly reused, or after (minor) alterations. The same principle holds for the definitions of sections of law, or even for larger constructs.
When a law is tested and yields unintended inconsistencies, the definitions of the metarules are able to guide the user to the culpable rules. To remove the arisen conflict, one of these rules has to be selected. Since the most important meta-rule handles specificity, one the conflicting rules has to be made more or less specific. The result of this action is that:
