A Software Tool for Legal Drafting
EE. Pimentel, V. Valero (Eds.): Workshop on Formal Languagesand Analysis of Contract-Oriented Software 2011 (FLACOS’11)EPTCS 68, 2011, pp. 71–86, doi:10.4204/EPTCS.68.7 c (cid:13)
D. Gor´ın, S. Mera & F. SchapachnikThis work is licensed under theCreative Commons Attribution License.
A Software Tool for Legal Drafting ∗ Daniel Gor´ın
Departamento de Computaci´on, FCEyN,Universidad de Buenos Aires, Argentina [email protected]
Sergio Mera
Departamento de Computaci´on, FCEyN,Universidad de Buenos Aires, Argentina [email protected]
Fernando Schapachnik
Departamento de Computaci´on, FCEyN,Universidad de Buenos Aires, Argentina [email protected]
Although many attempts at automated aids for legal drafting have been made, they werebased on the construction of a new tool, completely from scratch. This is at least curious,considering that a strong parallelism can be established between a normative document and asoftware specification: both describe what an entity should or should not do, can or cannot do.In this article we compare normative documents and software specifications to find out theirsimilarities and differences. The comparison shows that there are distinctive particularities,but they are restricted to a very specific subclass of normative propositions. The rest, wepostulate, can be dealt with software tools. For such an enterprise the
FormaLex toolset was devised: an LTL-based language and companion tools that utilize model checkingto find out normative incoherences in regulations, contracts and other legal documents. Afeature-rich case study is analyzed with the presented tools.
Although many attempts at automated aids for legal drafting have been made (e.g., [17, 24, 15,25, 18, 10]), they were based on the construction of a new tool, completely from scratch. Thisis at least curious, considering that a strong parallelism can be established between a normativedocument and a software specification: both describe what an entity should or should not do,can or cannot do. In the case of normative documents, it is a legal entity. In the case of softwarespecifications, it is a piece of software. Is a software specification so different from a normativedocument? If it is not, why do not reuse the already existing machinery that can successfullyanalyze specifications?In this article we compare normative documents and software specifications to find out theirsimilarities and differences. The comparison shows that there are distinctive particularities, butthey are restricted to a very specific subclass of normative propositions. The rest, we postulate,can be dealt with temporal model checkers. For such an enterprise the
FormaLex tool set wasdevised: an LTL-based language, FL , and companion tools that utilize model checking to findout normative incoherences in legal documents. FL is based on the following key-concepts: • It provides a background theory to state matters about the real world, such as event prece-dence (e.g., sunrise before dawn), uniqueness (each person is born only once), etc., thatwould otherwise had to be accommodated into unnatural deontic rules. Said background ∗ Partially supported by PICT 2007 532, UBACyT 20020090200116, 2002009020084 and 20020100200103. A Software Tool for Legal Drafting theory is translated into an automaton that determines the class of models over which therest of the language predicates. Section 4.1 provides the details. • Deontic rules are translated into LTL, but the input language, that is, the way the originaldeontic rules are written, is preserved, so this information can be used to perform a set ofanalysis, at a meta-logical level. See Section 4.3 for details. • The combination of an automata-based formalism plus a logic that can refer to it is verypowerful, and the software community knows it. FL takes advantage of that to easilyexpress properties that are generally difficult to pose in other formalisms, or lead to com-putational complexity problems. These features can be seen in Sections 3 and 5.A comparison between specifications and legal documents is presented in Section 2. Section 3highlights FL , our LTL-based language, by describing its use to express otherwise hard-to-writeproperties, and Section 4 gives details of the tool’s inner workings and formal semantics. A casestudy, where FL is used to expose problems in a feature-rich university’s regulation, is discussedin Section 5. Section 6 compares related work and Section 7 concludes the article.
It is often understood that regulations can be abstractly represented using the three well-knowndeontic operators for obligation (O), prohibition (F) and permission (P). Specifications can bealso thought of as using the same operators. “
The system must activate the brakes in no morethan three seconds after the emergency stop button is pressed ” is clearly an example of obligation.Prohibitions are also found: “ it is forbidden that the server sends unencrypted passwords throughthe wire ”. Permissions are not that frequent, but also possible: “ if out of resources the systemcan drop requests until the processor is freed ”.Nevertheless, some types of statements found in legal documents are not common in softwarespecifications. We divide them in two groups. The first one is composed of statements that haveequivalents in specifications, but under a somehow different structure:
Contrary-To-Duty Obligations.
Contrary-To-Duty (CTD) obligations are a way to modelphrases like “
The agent is required to do action X. If she does not, then action Y should beperformed ”. The first sentence is called the obligation and the last one the reparation , and wedenote that as O Y ( X ). Software specifications equivalents are conceivable, but the key differenceis how to treat O ( X ) ∧ O Y ( X ). A Software Engineering perspective could read the formula as“ obligation to perform X and obligation to perform X, plus reparation Y in case of failure of X,equals obligation to perform X plus reparation Y ”, considering that O Y ( X ) somehow supersedesplain O ( X ). However, a legal point of view is that O Y ( X ) means that a behavior that does notsatisfy X but performs Y is still legal, while the same behavior is illegal for the formula O ( X ),that does not contemplate a reparation. Amendments to Deal with Contradictions.
A legal corpus might contain the formulaF(kill), and then be modified to allow self-defense by the addition of P(kill in self-defense). It ishard to consider that such a corpus is contradictory, yet a software engineer will rather use thespecification F(kill unless in self-defense) that does not entitle a logical contradiction. Another FL case study was presented in [13], yet it was much smaller both in size and concepts. . Gor´ın, S. Mera & F. Schapachnik Permissions.
Besides their use as exceptions to prohibitions, what are permissions exactly?The question has been raised and analyzed many times before (e.g., [2, 5, 21, 19]), so let us hereonly say that in software a permission is little more than no-determinism, while in a normativesystem a permission is a much complex individual. It is worth noticing that the ability of a userof some application to use or not some functionality is not a permission, it is an obligation: thespecification would probably say that the software is obliged to behave in a way or some otherdepending on the user’s choices. Some phrases lend themselves to confusion: “
The user mayprint the displayed listing ”, in the context of a software specification is just a simpler wordingfor stating that in order to comply with the specification the software is obliged to present theprinting option, and, if chosen, print the listing.
Hierarchies.
Legal corpora have hierarchies. For example a regional law might set a tax to$10 while the national law sets the same tax to $20. If national laws override regional ones insaid normative system, the outcome is clearly $20. A software engineer might be tempted tosay that such system is equivalent to one that sets the tax to $20. However, the real normativesystem permits that if the national tax-setting law is canceled, the tax is still set at $10 by theregional one, while the software engineer model’s does not.
Ontologies.
In legal corpora ontologies are of common use. For instance, a law might setstandards for animals such as pets, while there might be another, more specific for dogs, thatmight set different conditions. Although software engineers are familiar with inheritance andsubclassing, it is not common to specify the requirements for a general class of actors and sepa-rately others, possibly contradicting the former, for a subclass. In a software specification theywill be treated in an ad-hoc manner, for example, with a requirement for dogs and another forpets that are not dogs, thus avoiding the contradiction.There are other types of statements that we believe have no equivalent in software specifi-cations:
Nesting of Deontic Operators.
Nesting of deontic operators, as in obligation to obligate(or to forbid, or to permit). In normative propositions such as “
The judge is obliged to oblige thecitizen to do X ” there are two obligations (and two responsible parties): if the judge does notcomply to oblige the citizen, she is to blame. If the judge complies but the citizen does not, thenthe citizen is at fault. The specification of a security system might use a similar phrase: “
Thesystem is obliged to oblige other users to do Y ”, with Y being something like “ not access eachothers private files ”. In this case, if the system does not enforce Y, then the system is at fault.Also, if users fail to do Y, then the same system is also responsible. This type of predicates seemto be just a complex wording for only one obligation.Care should be exercised when analyzing propositions where there is an apparent nesting ofobligations, but can be rewritten without nesting. E.g., “
The voting system should oblige usersto deposit the ballot in the case in less than one minute or else face prosecution ”. Such a phrasehas a very different meaning if found in the legal norm that regulates electronic vote, or in thesoftware’s specification. In the first case, it binds both developers and voters, while in the secondonly developers, as a software specification has no power over voters. In such a case, it can be4
A Software Tool for Legal Drafting rewritten as “
The voting system has to give one minute for the ballot to be deposited into thecase. In case of timeout, prosecution actions should be initiated [i.e., by notifying officials]. ”. Self-Referencing Modifications.
Self-referencing modifications, as in “
Let Article X of BillY be modified to mandate that from now on such and such ”. Self here means that they modifythe same normative systems that contains them. This should not be confused with any type ofsoftware compile-time or runtime configuration. In such cases the specification is still fixed andcontemplates the different possible behaviors. Deontic-Conditional Validity.
Deontic operators whose activating condition is the validityof another deontic operator. A typical example is a conditional over an obligation as in “ if at thetime of the execution the agent were obligated to ... then she ... ”. Software specifications mightimpose obligations based on the runtime operating conditions of the software, but they do notspecify behaviour that is conditional to the runtime requirements , if that term makes any senseat all.We found that the common denominator of the last group is considering the deontic operatorsas first-class operators, allowing for operators that take operators as parameters, check if they areactive, and so on. However, we believe that if we consider only the legal documents that do notuse such classes of predicates we can a) cover an important and varied amount of regulationsthat are common in the real world, and b) resort to the tools and technologies that can beused to analyze software specifications. The first group of predicates, we postulate, can beaccommodated in such setting if treated properly.We believe that this is good news for the deontic community, as it means that decades ofeffort in software-analysis tool building, optimizations and expressivity improvements can beleveraged, and there is no need to start from scratch and climb again the road from handlingtoy examples to real-size ones. FL Language
Our starting point is that many contracts and regulations can be formally analyzed with toolsoriginally aimed for software specifications. This allows for making the most out of existingtools. FL , introduced in [13], is built on the following premises: • It aims at finding coherence problems , defined in a very pragmatic way: behaviours cannot be permitted and forbidden, or obligated and forbidden, can not be plain mandatoryor mandatory with CTDs, CTD reparations cannot be forbidden, etc. The complete listof covered topics is presented in Section 4.3. • The input language is divided into a background theory and a set of rules. While therules are LTL formulae with additional deontic operators aimed at capturing normativepropositions, the background theory provides some simple constructs to describe the classof models over which the rules predicate. Although there are some prototype dynamic specification languages with self-referencing capabilities, theyare still far from being used in the current state of the practice. . Gor´ın, S. Mera & F. Schapachnik • Models are linear , and each one describes a possible legal behaviour. That is, behavioursthat do not comply with the normative rules are discarded. • If something is obligatory, then it must hold in every legal model at every possible state,and thus O ( j ) is interpreted as ✷ j . Prohibition of something is obligation to the contrary( F ( j ) ≡ O ( ¬ j )). The diamond operator works in the usual way, and ✸ j looks ahead inthe model for some state where j holds. • Contrary-To-Duty obligations are supported as O r ( j ), translated as ✷ ( ¬ j → r ). F r ( j )is interpreted as O r ( ¬ j ). It is worth noticing that our encoding skips out most of thedeontic logic paradoxes (see [14, Sect. 6] for details). • Although based on translating to LTL, the input syntax is preserved to perform analysisat the meta-logical level.Permission is thought of as absence of prohibition, but treated not as an operator thatmodifies the set of legal behaviours, but rather as a predicate that the legal models must satisfy.Otherwise, it is considered that the normative system under analysis (NSUA) has a coherenceproblem : it states that something is permitted when it actually is not. If the user flags thepermission as an exception to a prohibition, as in F(kill) and P(self-defense killing), the internalrepresentation of the affected prohibition is changed to reflect that. In the example, to F(killunless self-defense). The main component of the background theory is the action . An action can be happeningor not at any moment. In FL an action is interpreted as a digital signal that can be on or off foran arbitrary number of consecutive states. Actions can represent proper actions by the implicitagents (e.g., action DriveCar ) or non-controllable, external events (e.g., action
CarCrash ).There is no explicit notion of a role performing an action, so if they are needed the subject mustbe encoded in the action. We plan to add this feature in the future.Some requirements seem to be easy to express, like being licensed in order to drive a car. Itwould seem that it suffices to forbid the
DriveCar action if there is no prior
GetLicense action.But the easiness is only apparent, as individuals can not only get their license, but also lose it. Ifthe
LoseLicense action is also considered, establishing whether an individual is licensed or notby means of a pure formula amounts to “parenthesis counting”, and that can be very challengingto write or plain impossible depending on the particular logic used. FL incorporates the notionof intervals , similar to the fluents of [12]. An interval is delimited by beginning and endingactions, in a such a manner that there is no nesting nor closing of an already closed interval. Inthe automata, a propositional variable is set to true or false, indicating whether the interval isopen (see Section 4.1 for details). With intervals, the driving requirement can be posed as interval licensed delimited by actions GetLicense - LoseLicense and then simply stating F ( ¬ is licensed ∧ DriveCar ).Intervals can also be used to bound the occurrence of other actions: interval school_time delimited by actions
CourseBegin - CourseEnds action
TakeExam occurs only in scope school_time
There is also the view of obligation not as something that must always hold, but ratheras something that must be done, usually within some bound of time, sometimes called non-persistent obligation . We can deal with such expressions in two ways. Either with the O E ( j ) It does not mean the branching alternatives are not present, each possible alternative is present in one of theconsidered models. This can be done automatically for simple cases and requires manual intervention in others. A Software Tool for Legal Drafting operator that expresses an eventual obligation, one that ceases to exists as soon as it is fulfilled,or, if time bounds are provided (e.g., “
You ought to return the borrowed books within schooltime ”), by using intervals inside obligations: O ( ✸ school_time ReturnBook ). Other interactionsbetween obligations and deadlines are shown in [14].As the background theory is translated into an automata, we can accommodate there(bounded) counting , allowing for expressions like O ( bbc > → ✸ bbc = ), where the integercounter bbc , borrowed books count , is handled by the automata incrementing it and decrement-ing it with every BorrowBook or ReturnBook , respectively. Such formula properly states thatevery borrowed book must be returned, whereas the simple O ( BorrowBook → ✸ ReturnBook ) issatisfied by borrowing many and returning just one.Also interesting are persistent obligations with one-time-each reparations, where violating theobligation once, or even performing the reparation should not free the subject from the obliga-tion. An example of that is obligation to not cross red traffic lights, subject to a fee for each vio-lation. Such CTD obligations are usually hard to express. For instance, F PayFine ( RedCrossing ),says that red crossing is forbidden, except that a fine is payed immediately. If a diamond isadded, as in F ✸ PayFine ( RedCrossing ), then many violations can be canceled with one payment.In FL the formula can be easily stated with the aid of a fines counter that increments with BeFined and decrements with
PayFine , and the following formulae: F BeFined ( RedCrossing )(red crossing is forbidden, under the penalty of being fined), O ( fines > → ✸ PayFine ) (it ismandatory to eventually pay the fines).Section 4 shows formal semantics, how the background theory is translated into automata,the handling of formulae and how the coherence checks are defined and performed. FL ’s background theory is translated into a B¨uchi automata network with additional code thatcontrols state transitions and handles state variables. Each run of the automata defines astandard LTL model over which the rules formalized in the next section predicate. The toolcan use SPIN [20], DiVinE [3] or NuSMV [9] as backends for model checking, but the encodingpresented here will use an agnostic dialect.Time modeling is discrete, considered as succession of states, some of which have a propername to refer to timestamps of interest for the NSUA. In FL an action is thought of as a digitalsignal that can be on or off for an arbitrary number of consecutive states. Thus, each action isrepresented by an enumerated variable that covers the HAPPENING and
NOT_HAPPENING states.This is an easy way to model time density, as the net effect is that any event can happen whileothers are taking place.One single automaton is responsible for controlling all the variables. It has a single statecalled running and non-deterministically guarded self-transitions. Let’s exemplify with theaction
BorrowBook (e.g., from the library). declare enum borrow_book = NOT_HAPPENINGrunning -> runningguard borrow_book = NOT_HAPPENING -> set borrow_book = HAPPENING;guard borrow_book = HAPPENING -> set borrow_book = NOT_HAPPENING; . Gor´ın, S. Mera & F. Schapachnik runningborrow_book
NOT_HAPPENING -> HAPPENING borrow_book
HAPPENING -> NOT_HAPPENING
The automaton can switch the value of borrow_book or leave it as it is, changing othervariables. At the automaton level only one variable changes at a time, resembling the one inputassumption of SCR [4]. As said before, at the normative level many actions can be taking placeat the same time.The encoding shown so far allows to easily refer to whenever actions are happening or not, butsometimes it is required to express that an action has happened completely (i.e., it has finishedtaking place) or just happened (i.e., has finished taking place in the current state). For instance“ account the loan after borrowing ”, needs to refer to a moment when the
BorrowBook action isnot happening after having happened. To facilitate this, another state called just_happened , ofa type sometimes refered to as urgent or committed , is included in the automaton. The semanticsof such type is that whenever an execution reaches one of these states, of all the available options,the automaton must execute a transition that leaves a committed state: running -> runningguard borrow_book = NOT_HAPPENING -> set borrow_book = HAPPENING;running -> just_happenedguard borrow_book = HAPPENING -> set borrow_book = JUST_HAPPENED;just_happened -> runningguard borrow_book = JUST_HAPPENED -> set borrow_book = HAPPENING; With this new possible value for the state variable actions can be not happening for anarbitrary number of states, switch to
HAPPENING , also for an arbitrary number of states, butbefore switching to
NOT_HAPPENING again they must spend one state as
JUST_HAPPENED . Finishedactions are easy to pose with this new state: in O ( BorrowBook → ✸ AccountLoan ). From theformula perspective, the terms
BorrowBook and
AccountLoan are translated to propositionalvariables whose value is borrow_book = JUST_HAPPENED and account_loan = JUST_HAPPENED respectively.If actions have output values, as in: action
BorrowBook output values { available, in house reading only, not available } another enumerated variable borrow_book_output is added to the automaton and the encodingturns into: ...running -> just_happenedguard borrow_book = HAPPENING -> set borrow_book = JUST_HAPPENED,borrow_book_output = AVAILABLE;guard borrow_book = HAPPENING -> set borrow_book = JUST_HAPPENED,borrow_book_output = IN_HOUSE_READING_ONLY;guard borrow_book = HAPPENING -> set borrow_book = JUST_HAPPENED,borrow_book_output = NOT_AVAILABLE;... A Software Tool for Legal Drafting
So the output is set non-deterministically to any of the possible values and it is retaineduntil the next setting. Similarly, if the action has extra guards, they are added to the guard ofthe transition.As we mentioned before, intervals are another important feature of the language. Let’ssuppose books can only be borrowed during the academic year: interval academic_year delimited by actions
BeginYear - EndYear action
BorrowBook occurs only inside academic_year
A boolean variable, academic_year_opened is added to the automaton, and is set by thetransitions that represent the respective actions. Also, it is added as a guard, so no
BeginYear happens inside an academic year and no
EndYear happens outside one. Similarly, it is added asa guard for
BorrowBook .Expressivity-wise, counters are a very powerful feature: they are basically a non-negative in-teger variable with actions that either increment, decrement or reset their value. The implemen-tation is straightforward: an integer variable is added to the automaton, and it is manipulatedin the respective transitions.Temporal actions are a way to implement timers. The temporal actions ta , . . . , ta n clausedeclares a sequence of time points that follow the specified order and let an arbitrary number ofactions happen between them. The implementation uses another synchronizing automaton withone state representing each ta i and others representing the time intervals after ta i and before ta i + . FL ’s Syntax and Semantics We present here a formal definition for the rule-stating part of FL . Although allowed in the inputlanguage, general terms like bcc > , action.value , etc. are abstracted away as propositionalsymbols in the presented syntax. There is no need to model them explicitly since they can bethought of as encoded in propositional values that later the model handles in the proper way.The same happens with actions a , which are abstracted as the proposition a=JUST_HAPPENED . Syntax.
Let props be a countable infinite set of symbols, intervals ⊆ ( props × props ) aset of intervals, and forms the set of FL formulae in the signature h props , intervals i definedas inner forms :: = ⊤ | ⊥ | p | ¬ j | j ∧ j | ✸ j | ✸ i j forms :: = O ( j ) | F ( j ) | O r ( j ) | F r ( j ) | O E ( j ) | P ( j ) , where p ∈ props , j , r , j , j ∈ inner forms and i ∈ intervals . We usually work with (finite)sets of forms when specifying a NSUA, so conjunction between formulae in forms does notneed to be formally defined. We will usually write one formula below another, implicitly defininga conjunction between them. Some operators could have been defined in terms of others, but weintentionally define all of them at this level since our tool considers them differently for coherenceanalysis (see Section 4.3 for more details). This reduced presentation does not allow for nesting of deontic operators, a restriction only introduced tosave space in this article. For the same reason we ommit the repared version of the O E operator. . Gor´ın, S. Mera & F. Schapachnik Semantics.
We give FL semantics by providing a translation Tr from FL into classic LTL ,as both work over the same class of models. Let F be a set of FL formulae whose intendedmeaning is defining the set of legal models for the NSUA. Recall that LTL models are lin-ear infinite structures that represent possible runs on the automata defined by the backgroundtheory. We first split permissions from the rest and define the Tr domain as F ¯ P = { j | j ∈ F such that j is not of the form P ( y ) } . Tr acts as the identity for the inner forms construc-tions not explicitly specified and it is asumed that the target LTL signature has the implicitlydefined propositions involved in the translation (like i opened for each interval i ). Tr ( ✸ i j ) = i opened → ( i opened U Tr ( j )) Tr ( O ( j )) = ✷ Tr ( j ) Tr ( F ( j )) = ✷ ¬ Tr ( j ) Tr ( O r ( j )) = ✷ ( ¬ Tr ( j ) → Tr ( r )) Tr ( F r ( j )) = ✷ ( Tr ( j ) → Tr ( r )) Tr ( O E ( j )) = ✸ Tr ( j ) Tr can be lifted to take a set of FL formulae and return the set of their translations.Let’s now consider an automaton A defined by the background theory and the class of models C A that represents all possible runs on A . Let F be the set of FL formulae that encode the NSUA.The class of legal models defined by F over C A is defined as C F A = { M ∈ C A | M | = Tr ( F ¯ P ) } . That is, every legal model must satisfy the obligations and prohibitions specified by F .But what about permissions? Permissions are actually a check that must be performed on C F A to ensure coherence. The condition that C F A must fulfill is the following: for every j of theform P ( y ) in F there must be a model M in C F A such that M | = Tr ( y ). I.e., if something ispermitted then the rest of the NSUA does not prevent it from happening.We are going to expand the concept of coherence in the next section by analyzing other casesof interest. A difficult topic in deontic logic is the concept of coherence of a normative system: wheneverthe set of rules is “contradictory” in any sense. As stated in the literature (e.g., [19]), theproblem cannot be simply reduced to logical consistency. We take a pragmatic approach wherea normative system is not coherent if it has any of a list of problems.While some of them are straightforward to check, others require more sophistication. Let’ssee an example of each class. To fix notation, j y means that j is incompatible with y andthe following equivalences hold: O ( j ) = O ⊥ ( j ), F r ( j ) = O r ( ¬ j ).To check that there are no forbidden obligations (i.e., that there is no pair of rules O ( j ) and O ( y ) such that j y ), we need to check that there is at least one possible legal behaviour thatsatisfies both the background theory and the complete set of formulae. To do that, all the rules r i are conjuncted into F = V Tr ( r i ), and both the automata and ¬ F are fed to the model checker.If ¬ F is not satisfiable the model checker will output a counter example trace, t . t satisfies thenegation of ¬ F so it is the legal behaviour we were looking for. Should ¬ F be satisfiable, thatmeans that F is not, so a backtracking-type of procedure should be started to find the “guilty”rules. How to improve this procedure is an active area of research. That is, the basic version of LTL with the standard boolean connectives plus the until operator (from whichthe diamond is defined). A Software Tool for Legal Drafting
We are also interested in checking that there are no “contradicting obligations”: rules O r ( j )and O r ′ ( y ) with j y even if it is not the case that r r ′ . That is, incompatible obligations, butwith compatible reparations. If that were the case, there would be a legal behaviour: doing thereparations r and r ′ , yet it makes no sense that the primary obligations j and y are impossibleto comply with.To check for that, we build F ′ as V Tr ( O ( j i )) for all the rules r i = O r i ( j i ). Then the automataand ¬ F ′ are fed to the model checker as before. If ¬ F ′ is satisfiable there is no way to complywith all the obligations, leaving aside the possible reparations. If ¬ F ′ is not, then, as before,the t ′ counter example trace is a possible way of complying with all the primary obligations.It should be noted that this last check is one of the analysis were preservation of input syntaxis important and the translation of repared obligations is not done directly.The following conditions also violate coherence: • Forbidden reparations , such as O r ( j ) and F ( r ). In that case the reparation is only nominal,as it is indeed forbidden. O r ( y ) and O ( y ) with r y is another case of the same problem. • Obligations with conflicting reparations . If r r ′ and O r ( j ) and O r ′ ( j ) is found then thereis a contradiction in how the obligation j could be repaired. Note that this does not meanthat there is no legal behaviour, as respecting j is always allowed. • Impossible permissions . Whatever was said to be permitted should be possible as wasexplained in Sections 3 and 4.2. • Unrealizable background theory . The background theory should not generate an empty setof traces, which would mean it is, by itself, logically inconsistent.
To show FL at work we analyze some excerpts from a university regulation. This case studyfocuses on conflicts that can arise from students being able to be also teachers. Althoughfictional, the inspiration is real. The case study features the use of actions, intervals, counters,obligations, prohibitions, permissions and many forms of coherence analysis.The analyzed excerpt is the following:
1. Chapter 1, Students.(a) Every individual that has enrolled for a career and has not yet graduated from it is consideredto be a student.(b) Students should respect each other. Major disciplinary faults are punished by forbidding theentering to university premises for one year after the fault.(c) Students have the following rights: ..., participate in research activities, ...2. Chapter 2, Teachers.(a) There are three teaching categories: c1) Undergraduate Teaching Assistant (aka UTA), c2)Teaching Assistant and c3) Professor.(b) To become a teacher, aspirants must apply when the selection opens. The selection will bemade based on the following criteria for each category: [omitted, not relevant to the casestudy](c) To apply for the UTA category, aspirants must be students at the time of the selection. The UTA category position lasts one year in the real case. This particular spelling of the norm was chosenbecause it is desired that only students fill this position, yet allow them to keep the job if they graduate after theselection. . Gor´ın, S. Mera & F. Schapachnik (d) Teachers must perform their duties, starting 30 days after the selection ends.(e) Working from home is allowed, but teachers must spend at least one day a week in thepremises of the university.3. Chapter 3, Research.(a) Research activities can only be pursued by members of approved research groups.(b) Research groups are conformed by accredited professors or teaching assistants.4. Chapter 4, University Library.(a) Every borrowed book should be returned by the end of the month. (b) Students and teachers are subject to a fine for not returning books in time.(c) As students are generally on a budget, their fine should be low.(d) Teachers should be an example of conduct, thus their fine should be strictly higher that thestudents’ one. Let’s model the student’s chapter first. To avoid clutter some abbreviations will be used,such as not declaring actions that are used to bound intervals if they do not take any extraparameter, as it is the case for declaring what a student is. interval student delimited by actions
Enroll - Graduate
Regarding discipline, they should not commit disciplinary faults or be banned from enteringthe premises for one year. To model that we will define two intervals: one that spans from thefault to one year after, and another that accounts for being inside the building. interval ban delimited by actions
CommittFault - OneYearPassed interval inside_building delimited by actions
Enter - Exit
And stipulate the prohibition: F ✸ ban ¬ is inside building ( CommitFault ) (1)meaning that the fault should not occur but if it does, during the ban period the student cannotbe inside the building ( is inside building is a boolean variable made true between the boundingactions of the interval).Article 1c permits students to do research, in what can be thought of as a case of antitheticalpermission [26]: a permission set to invalidate future prohibitions. P ( is student ∧ DoesResearch ) (2)Now let’s focus on the teachers’ selection process. There is the selection interval and itspossible outcomes: being elected in any of the categories, or not being elected at all. action
ElectWinners output values { teacher c1, teacher c2, teacher c3, no teacher } interval selection delimited by actions OpenSelection - ElectWinners action
Apply only occurs in scope selection
For simplicity let’s only model the requirements for the c1 category (UTAs) of still being astudent: O ( ✸ selection ( Apply → is student )) (3)Teachers also have duties, that must start 30 days after the election: The more realistic requirement of returning within days is also possible but more involved, thus the simplerversion is preferred for space reasons. A Software Tool for Legal Drafting interval grace_period delimited by actions
ElectWinners - interval on_duty delimited by actions - +inf interval week delimited by actions StartWeek - EndWeek occurs only in scope on_duty repeatedly
It is mandatory to have a weekly visit: O ( is teacher → ✸ week Enter ) (4)with is teacher defined as macro is teacher = Apply ∧ ( ElectWinners . teacher c1 ∨ ElectWinners . teacher c2 ∨ ElectWinners . teacher c3 ) Regarding Chapter 3, the restriction of research activities to members of research groups is: F ( ¬ JoinResearchGroup ∧ DoesResearch ) (5)while the requirements of being TA or professor to belong to a research group is: F ( ¬ ( ElectWinners . teacher c2 ∨ ElectWinners . teacher c3 ) ∧ JoinResearchGroup ) (6)Then there is the borrowing of books, similar to both students and teachers, that requiresthe bbc (borrowed books count) counter and signaling months (it should be noted that the exactduration of a month is not important and it is thus abstracted away): counter bbc increases with action
BorrowBook decreases with action
ReturnBook interval month delimited by actions
MonthBegin - MonthEnd repeatedly
Although articles 4c and 4d are mainly motivational, there is one prescriptive consequence,even at the level of abstraction we are using – fines should be different:
StudentFine
TeacherFine .Article 4b is a CTD to 4a, so we encode them as: O StudentFine ( is student → ✸ month ( bbc > → ✸ month bbc = )) (7) O TeacherFine ( is teacher → ✸ month ( bbc > → ✸ month bbc = )) (8)When analyzed by FormaLex three coherence problems are pointed out. First, the repa-ration for not returning borrowed books is troublesome for teachers that are also students, andthe tool signals a case of conflicting reparations , as there are traces where the implicit agentis indeed a teacher and a student. Looking at the NSUA nothing impedes students to becometeachers, quite the contrary, as there is a UTA category.What type of fine should a UTA be subject to? Whatever conclusion can be obtained bylooking at the motivational articles 4c and 4d is disputable, as it is both true that UTAs shouldbe an example of conduct because they are teachers, and that they are also on a budget, becauseUTAs’ salaries are symbolic. As the fining would probably be decided by a library’s clerk, thereis high risk of different solutions applied to identical cases. It would be much better if this casecould be decided by the norm-givers, and that is the sense of the warning.The second problem is more involved and related to the weekly visit rule. The tool detectsthat the reparation of the rule that forbids discipline faults (1) contradicts the obligation to theweekly visit (4). Indeed, there is the possibility of a student committing a fault, thus beingbanned to enter the premises, applying for a teaching position, then being elected as UTA andnot being able to comply with his weekly visit duty.A possible solution is to forbid the application of punished students as in: Note that although the name of the
Apply action is in the present tense, because of the translation, it is easierread if it thought of as written in the past tense. This reflects the fact that the intended semantics is to check ifthe action has occurred at some point in the past. The same happens with formulae 5, 6 and 9. . Gor´ın, S. Mera & F. Schapachnik action Apply only occurs in scope selection requires that ¬ CommitFault
However, the problem persists, as the student can now apply (not yet being faulty), committhe fault, then being selected, to the same effect. A better solution would be to restrict the
ElectWinners action so only non faulty students can become teachers: F ( CommitFault ∧ ElectWinners . teacher c1 ) (9)This formula states that it is forbidden to commit the fault and to be elected UTA. Observethat if the fault is commited before becoming a teacher, then this formula forbids the election,which is the primary intention of it. On the other hand, if the fault is commited after becomingUTA, then again the reparation of the rule that forbids discipline faults (1) contradicts theobligation to the weekly visit (4). This situation is also noticed by the tool and notified to theuser as a warning. If the user considers that it should be possible to repair the fault even underthese conditions, then she must introduce appropriate modifications in the NSUA to envisagethis situation. If, on the other hand, she thinks that it is correct to tighten the rules for teachersso they should not have a way to repair their faults, then the warning can be ignored.The third problem is the collision of allowing research only to TAs and professors (rules 5and 6) with the permission for students by rule 2. The fix is either the removal of the permissionor the inclusion of at least UTAs into research groups.There is another interesting aspect of this NSUA. Let’s assume somebody proposes a differentwriting for article 2c, that is supposedly more faithful to the spirit of not letting graduates fillthe UTA category. She proposes defining what a graduate is: interval graduate delimited by actions Graduate - +inf and plain forbidding the application of graduates. When queried about the validity of this newwriting:? F ( ✸ selection ( Apply ∧ is graduate ))the tool responds that the prohibition does not hold as there is a trace where a student graduatesand then enrolls again (say, for a different career) before applying. That perfectly satisfies therequirement that during the selection process applications must be done by students (3), as theimplicit agent is also a student. It means that the phrasing of the rule (3) does not comply withthe intended normative effects: restrict the UTA category to non-graduates; so the proposedalternate writing is actually the correct one. This “bug” is extracted from a real university’sregulation.An interesting remark is that although the lack of roles in FL can be seen as a drawback,it turned useful in this case. Should roles had been available, probably many of the abovementioned bugs would have been concealed, including the real one. The idea of using a temporal logic for deontic purposes is not new. It can be traced to [1, 22,16, 8, 11, 7, 23], among others who use some type of temporal-deontic logic. However, as far aswe know they provide neither tool support nor a translation into a standard tool, and thus arenot directly comparable to our work which is heavily tool-biased.[18] deals with automated conflict detection in norms by using a tool that supports ontologiesand translates normative propositions into a Prolog program, but the analysis is restricted tological contradiction. More similar to our approach of analyzing contracts and regulations for4
A Software Tool for Legal Drafting coherence problems are BCL [15] and
C L [24]. BCL is a contract specification language thatis meant for monitoring, allows to build executable versions, can detect conflicts among rulesoff-line and provides features like clause normalization. However, it lacks support for temporalreasoning and background theories.
C L is another logical language based on dynamic logic that treats deontic operators as first-class citizens. It is based on an ad-hoc tool and it neither uses background theories, nor discusseshow to deal with some limitations of expressivity: for instance, in dynamic logic approaches itis easy to say that if a book is borrowed ( b ), a book should be returned ( r ) as [b]O(r), but suchrule matches the borrowing of multiple books and the returning of just one; the correct versionis pretty involved or plain impossible depending on the particular logic. Starting from the premise that normative systems are very similar to software specifications wepropose a language and related tool set to analyze the former with tools designed for the latter.Besides the similarities, the decision is based on avoiding to build tools from scratch: modelcheckers have decades of effort in tool building, optimizations and expressivity improvements.In this article we analyzed a feature-rich, real-life inspired, case study. Although fictional,we believe it shows the power of both the tool and its underlying definition of coherence tospot defects that are not self-evident. Our next step is dealing with a 100% real case studyto investigate the payoff of having to logically encode the NSUA vs. the severity of the defectsfound.
References [1] Thomas ˚Agotnes, Wiebe van der Hoek, Juan A. Rodrıguez-Aguilar, Carles Sierra & MichaelWooldridge (2009):
A Temporal Logic of Normative Systems . Towards Mathematical Philosophy
28, pp. 69–106, doi:10.1007/978-1-4020-9084-4 5.[2] C.E. Alchourr´on & E. Bulygin (1981):
The expressive conception of norms . New studies in deonticlogic
DiVinE – A Tool forDistributed Verification (Tool Paper) . In:
Computer Aided Verification , LNCS
Developing high assurance avionics systems with the SCRrequirements method . In:
Digital Avionics Systems Conferences, 2000. Proceedings. DASC. The19th , 1, IEEE, doi:10.1109/DASC.2000.886888.[5] Guido Boella & Leendert van der Torre (2003):
Permissions and obligations in hierarchical normativesystems . In:
ICAIL ’03: Proceedings of the 9th international conference on Artificial intelligenceand law , ACM, New York, NY, USA, pp. 109–118, doi:10.1145/1047788.1047818.[6] Guido Boella, Leendert W. N. van der Torre & Harko Verhagen, editors (2007):
NormativeMulti-agent Systems, 18.03. - 23.03.2007 . Dagstuhl Seminar Proceedings
Designing a DeonticLogic of Deadlines . In Alessio Lomuscio & Donald Nute, editors:
DEON , Lecture Notes in ComputerScience . Gor´ın, S. Mera & F. Schapachnik [8] Julien Brunel, Jean-Paul Bodeveix & Mamoun Filali (2006): A State/Event Temporal Deontic Logic .In Lou Goble & John-Jules Ch. Meyer, editors:
DEON , Lecture Notes in Computer Science
NuSMV: a new symbolic modelchecker . International Journal on Software Tools for Technology Transfer (STTT)
Norm Refinement and Design throughInductive Learning . In: , pp. 33–48, doi:10.1007/978-3-642-21268-0 5.[11] Tim French, John Christopher McCabe-Dansted & Mark Reynolds (2010):
Axioms for Obligationand Robustness with Temporal Logic . In Guido Governatori & Giovanni Sartor, editors:
DEON , Lecture Notes in Computer Science
Fluent model checking for event-based systems . ACM SIG-SOFT Software Engineering Notes
Model Checking Legal Documents . In:
Proceedings of the 2010 conference on Legal Knowledge and Information Systems: JURIX 2010 , pp.111–115, doi:10.3233/978-1-60750-682-9-151.[14] Daniel Gor´ın, Sergio Mera & Fernando Schapachnik (2011):
FormaLex – A Software Tool forLegal Drafting . Technical Report GMS-2011, FCEyN, Universidad de Buenos Aires. Available at http://publicaciones.dc.uba.ar/Publications/2011/GMS11 .[15] G. Governatori & D.H. Pham (2009):
Dr-contract: An architecture for e-contracts in defeasiblelogic . International Journal of Business Process Integration and Management
Temporalised Normative Positionsin Defeasible Logic . In:
ICAIL , ACM, pp. 25–34, doi:10.1145/1165485.1165490.[17] Nienke den Haan (1997):
Tools for automated legislative drafting . In:
ICAIL ’97: Proceedings of the6th international conference on Artificial intelligence and law , ACM, New York, NY, USA, p. 252,doi:10.1145/261618.261662.[18] S. Hagiwara & S. Tojo (2006):
Discordance Detection in Regional Ordinance: Ontology-based Vali-dation . In:
Proceeding of the 2006 conference on Legal Knowledge and Information Systems: JURIX2006: The Nineteenth Annual Conference , IOS Press, pp. 111–120.[19] J¨org Hansen, Gabriella Pigozzi & Leendert W. N. van der Torre (2007):
Ten Philosophical Problemsin Deontic Logic . In Boella et al. [6].[20] Holzmann (2003):
The Spin Model Checker: Primer and Reference Manual . Addison-Wesley,doi:10.1109/32.588521.[21] David Makinson & Leendert W. N. van der Torre (2007):
What is Input/Output Logic? Input/OutputLogic, Constraints, Permissions . In Boella et al. [6], pp. 383–408.[22] J.J.C. Meyer, R.J. Wieringa & F.P.M. Dighum (1998):
The role of deontic logic in the specificationof information systems . In:
Logics for Databases and Information Systems , Kluwer, pp. 71–116.[23] G. Piolle (2010):
A Dyadic Operator for the Gradation of Desirability . Deontic Logic in ComputerScience
C L : An Action-Based Logic for Reason-ing about Contracts . In:
WoLLIC ’09: Proceedings of the 16th International Workshop onLogic, Language, Information and Computation , Springer-Verlag, Berlin, Heidelberg, pp. 335–349,doi:10.1007/978-3-642-02261-6 27. A Software Tool for Legal Drafting [25] Ellis Solaiman, Carlos Molina-jimenez & Santosh Shrivastava (2003):
Model Checking CorrectnessProperties of Electronic Contracts . In:
Proceedings of the International conference on Service Ori-ented Computing (ICSOC03) , Springer-Verlag, pp. 303–318, doi:10.1007/978-3-540-24593-3 21.[26] Audun Stolpe (2010):