A Software Tool for Legal Drafting

Although many attempts at automated aids for legal drafting have been made, they were based 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 a software 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 their similarities and differences. The comparison shows that there are distinctive particularities, but they are restricted to a very specific subclass of normative propositions. The rest, we postulate, can be dealt with software tools. For such an enterprise the \FormaLex tool set was devised: an LTL-based language and companion tools that utilize model checking to find out normative incoherences in regulations, contracts and other legal documents. A feature-rich case study is analyzed with the presented tools.

💡 Research Summary

The paper investigates the striking parallel between normative legal documents (laws, contracts, regulations) and software specifications, arguing that both describe what an entity must, must not, or may do. While many previous attempts at computer‑assisted legal drafting built bespoke systems from the ground up, the authors propose reusing the mature toolbox of software verification. They first classify normative statements into three groups. The first consists of the classic deontic operators—obligation (O), prohibition (F), and permission (P)—which map directly onto Linear Temporal Logic (LTL) operators □ (always), ◇ (eventually), and the dual of prohibition. The second group contains “Contrary‑to‑Duty” (CTD) constructs, where a primary obligation may be violated and a secondary reparative obligation must then be fulfilled (e.g., “If the agent fails to submit X, she must pay a fine”). The third group gathers more complex legal features such as hierarchical overrides, ontological specialisation, nested deontic operators, and self‑referencing amendments; these are rare in software specifications and often exceed the expressive power of plain LTL.

To bridge the gap, the authors introduce the FormaLex (FL) language and toolset. FL separates a “background theory” from a set of deontic rules. The background theory defines primitive notions of actions (digital signals that can be on or off) and intervals (time‑bounded segments delimited by start and end actions). Actions may represent controllable events (e.g., DriveCar) or external occurrences (e.g., CarCrash). Intervals allow the expression of conditions such as “the driver must be licensed between GetLicense and LoseLicense actions,” enabling concise modelling of stateful requirements without explicit role constructs.

The rule component enriches LTL with deontic operators. An obligation O ϕ is interpreted as □ ϕ, a prohibition F ϕ as O ¬ϕ, and a permission P ϕ as the absence of a corresponding prohibition (or as an explicit predicate that must hold in all legal models). CTD obligations are encoded as Oρ (ϕ) ≡ □(¬ϕ → ρ), and their prohibited counterparts as Fρ (ϕ) ≡ Oρ ¬ϕ. This encoding deliberately sidesteps many classic deontic paradoxes, because the reparative obligation ρ supersedes the original duty only when the primary condition fails.

The FL compiler translates the high‑level rules into pure LTL formulas, preserving the original syntactic structure for meta‑logical analysis. These formulas are then fed to existing model‑checking engines (e.g., NuSMV, SPIN). The tool automatically constructs all possible legal behaviours (models) that satisfy the background theory; any model violating a rule signals a coherence problem. The authors define three main coherence problems: (a) contradictory obligations and prohibitions, (b) CTD reparations that are themselves prohibited, and (c) permissions that conflict with explicit prohibitions. When such a problem is detected, the tool reports the offending clauses, enabling the drafter to resolve the inconsistency before the document is enacted.

A substantial case study validates the approach. The authors formalise the complex set of regulations governing a large university in Buenos Aires, comprising roughly 200 normative clauses, including obligations, prohibitions, permissions, CTDs, hierarchical overrides, and temporal constraints. After encoding the regulations in FL, the model‑checking phase uncovers several hidden contradictions—e.g., a rule that allows borrowing books only during “school time” while another rule unintentionally permits borrowing at any time, and a self‑defence amendment that effectively nullifies a blanket prohibition on killing. The tool also demonstrates how to model counting constraints (e.g., “each borrowed book must eventually be returned”) by using integer counters within the automaton, something that would be cumbersome in pure LTL.

In the related‑work discussion, the paper contrasts FL with earlier legal‑automation efforts that rely on natural‑language processing or bespoke deontic logics. By leveraging the well‑studied LTL and automata‑based verification infrastructure, FL achieves higher scalability, better tool support, and a clearer semantic foundation. Nonetheless, the authors acknowledge limitations: self‑referencing amendments, deep ontological hierarchies, and nested deontic operators remain only partially supported, and extending FL to handle them will require additional meta‑logical layers or richer type systems.

In conclusion, the research demonstrates that a large portion of normative legal drafting can be treated as a software specification problem. The FormaLex language and its accompanying toolchain provide a pragmatic pathway to reuse decades of software verification research for legal analysis, offering automatic detection of incoherences, support for temporal and counting constraints, and a concrete methodology for drafting more robust legal texts. Future work will focus on expanding the expressive power to fully cover the remaining “legal‑only” constructs and on integrating user‑friendly front‑ends for non‑technical legal practitioners.