PART TWO:

Analysis of Better Rules and Rules as Code

Overview

1. To critically analyse a better rules approach, rules as code, or the concept of legislation or law as code, we have had to be able to articulate precisely what those things involve.

2. In practice, we have found it difficult to confidently describe conceptual distinctions among the following:
   1. law or legislation as code;
   2. a better rules approach and the Better Rules programme; and
   3. rules as code.

3. In the end, we have elected not to just describe those concepts, but to adopt a position on how the concepts should be distinguished. Effectively, if a better rules approach is to be adopted, it should be adopted in a form that resembles the way we describe it.

4. We feel that this approach is justified based on the direct experience of one member of our research team. We have combined that experience with the critical insights brought by the wider team from experience, reading, and research. In an appendix to the report, we set out in more detail some of the public claims associated with Better Rules and rules as code to provide context to the claims we make and the distinctions we draw. Part Two of this report is intended to be a summary.

5. We note that our formulation of “a better rules approach” appears to diverge at times from Better Rules promotional materials. Throughout the report, we endeavour to refer to the official Better Rules initiative within government using capitalisation. We refer to “a better rules approach” without capitalisation to distinguish the approach itself from the official government programme, which is currently nested within the Better Rules for Business and Better Rules – Better Outcomes programmes within the Ministry of Business, Innovation and Employment.

6. We emphasise that the practices comprising a “better rules approach” can be used regardless of whether the “better rules / Better Rules” label is applied or adopted. For us, “better rules” is primarily a convenient shorthand that links our topic to contemporary developments in New Zealand.

What is a “better rules approach”?

History and purpose

1. In 2018, the concept of “a better rules approach” came into existence within the New Zealand government’s Service Innovation Lab.⁹ It was an approach to help accurately interpret legislation to deliver government services within and among various government departments.

2. The better rules approach emulated many of the practices of Service Design. In essence, the approach is primarily a policy development method: the merit of this method does not rest primarily on the publication or operationalisation of formal “rules as code” outputs.

3. The Service Innovation Lab was not the only government department working with “law as code” type approaches. The Inland Revenue Department in New Zealand works with a proprietary Oracle system that uses business process modelling techniques and in the original Better Rules discovery, it is indicated that IRD modellers led the process of coding the rules that became a better rules approach.

4. In the context of the better rules approach, there are clear signs of it having been influenced by an approach to business rules and business process modelling. Firstly, the modelling was led by the IRD at the Better Rules Discovery documented in the 2018 report, and IRD takes a business rules and business process modelling approach. Second, core advocates of both the better rules approach and the rules as code area have a history of working in business process modelling. Third, the approach of developing “a concept model”, “a decision model” and “rule statements” are practices followed in business process modelling and information systems practices.

5. The Service Innovation Lab’s initial work received international acclaim¹⁰ and was featured in the OECD Global Trends 2019 report.¹¹ A number of other projects within the lab followed, exploring the use of a better rules approach and rules as code techniques. These included:

   1. Analysis of the Rates Rebate Calculator.¹²
   2. An investigation by the Accident Compensation Corporation into using machine consumable legislation approaches for a structural rewrite of the Accident Compensation Act 2001.¹³
   3. International collaboration on pension eligibility.¹⁴
   4. Establishment of the “Better Rules – Better Outcomes” Team within MBIE.¹⁵

6. Since being initially developed and shared with other groups, better rules approaches are being investigated or piloted in specific government policy projects. Government agencies that we understand to have explored the potential of a better rules approach, rules as code, or associated methods and techniques, include:

   1. Inland Revenue Department.
   2. Accident Compensation Corporation.
   3. Parliamentary Counsel’s Office.
   4. Land Information New Zealand.
   5. Department of Internal Affairs.
   6. Ministry of Social Development.
   7. Ministry of Primary Industries.
   8. State Services Commission.
   9. Department of Prime Minister and Cabinet.
   10. Ministry of Business, Innovation and Employment.

A service design approach to policy development

1. The initial concept for a better rules approach is best described as the application of “service design” techniques to policy development. Public materials from the Service Innovation Lab make the service design connection to policy development explicit:¹⁶

   What is new is testing the implementation logic and service design impacts alongside the policy development process, utilising approaches from other disciplines such as human centred design and test-driven software development. This opening up of the drafting process to include other ways of thinking and testing the rules has been coined ‘Better Rules’.

2. Digital.govt.nz defines service design as follows:¹⁷

   Service design is about making government services easy for people to use. This means designing services that put people at the centre and help them do the task they need to do, like learning to drive or buying a house. A service design approach looks at the whole task, rather than the separate parts that might be spread throughout a government agency or across different agencies. Service design identifies problems and opportunities for the people using the service and the people delivering it and works out the best solution.

3. In a better rules context, a service design approach to policy development means developing policy in a workshop format which combines a collection of methodologies from across the various professions involved in the public service. The team takes an active interest in implementation as an essential component of achieving policy intent. In doing so, it produces a clearer shared vision of what a regulatory system is intended to achieve and how it should achieve it.

4. Importantly, a regulatory system is wider than just the legislation or legal rules that may form the legal bedrock of that wider system.¹⁸ Frequently, we have found that rules as code advocates are really talking about modelling a wider regulatory system, not just the law (legislation) itself.

5. Because of the way that a better rules approach requires that policy development anticipates service design and implementation requirements, it produces a superior description of the overall regulatory system required to deliver a policy programme.

6. In a policy development context that results in legislation or a legal instrument, this superior description of the overall regulatory system provides better information for drafters to understand what role legislation plays in that system, and how to implement that policy through legislative instruments – whether drafting legislation, secondary legislation, policy instruments, standards, or guidelines. We note that, independently of the Better Rules programme, there has been significant attention on improving the way that government departments prepare drafting instructions for the Parliamentary Counsel’s Office.¹⁹ A better rules approach could assist.

7. A core “knowledge asset” in the process is the “concept model”. Within computer science, a conceptual model is also known as a domain model. It represents the core concepts in a problem domain and the relationships between them:²⁰

   The conceptual model attempts to clarify the meaning of various, usually ambiguous terms, and ensure that confusion caused by different interpretations of the terms and concepts cannot occur. Such differing interpretations could easily cause confusion amongst stakeholders, especially those responsible for designing and implementing a solution, where the conceptual model provides a key artifact of business understanding and clarity. Once the domain concepts have been modeled, the model becomes a stable basis for subsequent development of applications in the domain. The concepts of the conceptual model can be mapped into physical design or implementation constructs using either manual or automated code generation approaches. The realization of conceptual models of many domains can be combined to a coherent platform.

8. A better rules approach to policy development rests heavily on the use of such conceptual models, which are drawn in part from information systems and computational theory.

9. Taking a service design approach to policy development improves a policy’s suitability for implementation in digital systems (i.e., computers). This is achieved by emphasising the way that a service will ultimately be delivered and received. A service design approach to policy using a multidisciplinary team also means incorporating expertise from people with experience in the operational side of government, who can sometimes be excluded from the policy development process.

“Translation” in a better rules approach

1. The original Better Rules Discovery Report mentions “translation” at multiple points, and translation occurs in multiple ways.

2. Our examples below are not intended to uncharitably dismantle the original discovery report: we are conscious of the circumstances in which it was produced. Rather, our intent is to illustrate how confusion might arise when it comes to considering the concept of “translation” in a better rules approach.

3. In summary, there are two points at which “translation” is relevant to a better rules approach.

   1. One translation point is the one that exists between the natural language instruments that describe the relevant regulatory system and the machine-executable code modelling or implementing that regulatory system. This is the translation point that we have scrutinised from a legal perspective in Part 3 of our report. This is the translation point that has attracted the most public attention, particularly for rules as code and law as code advocates.

   2. There is a second translation process which is not easily understood by outsiders to the policy process. This translation point exists between different groups of people that work together in different parts of the policy development process.

4. There are signs that both these points of “translation” are anticipated in the Better Rules Discovery Report, although they are not always carefully delineated.²¹

5. At page 26, a “translation gap” can be “removed” between policy, legislative intent, and software supporting service delivery:

   Making legislation or business rules machine consumable at the creation of rulesets would enable: … remov[ing] the “translation gap” that currently exists between policy and legislative intent, and the software that is developed to support service delivery.

6. At pages 7-8, “translation” is anticipated in relation to “policy, legislation and the business rules of government”, where “the logic of these rules” is turned into “reusable, machine consumable programmatic logic”:

   There are opportunities if we consider how we might make policy, legislation, and the business rules of government not just human and machine readable (like the XML, or Extensible Markup Language version of New Zealand’s legislation on legislation.govt.nz), but machine understandable. Turning the logic of these rules into reusable, machine consumable programmatic logic at source (rather than through translation) supports service innovation by both government and, where appropriate, by third parties (including artificial intelligence). However, we must remember that ensuring human and machine consumable rules have equivalence and are openly accessible is essential for transparency of government and algorithmic decision-making.

7. At page 12, in a future state, it is hypothesised that “we remove the need for translation of the rule” and at page 14, “translation gaps” can be “reduce[d] or negate[d]” in “policy production and consumption”, leading to “delivery of the rules to humans and systems”:

   We hypothesised that this future state approach would reduce or negate the translation gaps in policy production and consumption and lead to more timely and reliable delivery of the rules to humans and systems.

8. At page 10, both translation points are run together. Translation is anticipated from “rules” into rules that can be delivered in business systems. At the same time, translation is considered between “each group next in the production and consumption chain” who must “translate the output from the previous step”, which creates a risk of errors:

   We explored the issues around the work of translating rules so they could be used by business systems to deliver services. It became apparent that all the different groups involved in the policy to service delivery process use a structured language, have standards and frameworks and use manuals and guidelines. However, the language and the tools and materials are unique to each of the different groups and are largely not shared. The different groups work more or less in silos. This means that each group next in the production and consumption chain has to translate the output from the previous step without full knowledge of that step, and without having had input into that step. The translation process is inefficient, opens up the process for errors and there is limited sharing of knowledge and experience across the groups … Inefficiencies are amplified as business systems with embedded, or hard coded, rules rely on being notified of upstream changes and must replicate the change process.

9. In traditional policy development approaches, policy development tends to be linear. This is why the language of “agile” software development is sometimes used to describe a better rules approach, in order to contrast it with the more “waterfall” based approach that metaphorically describes traditional policy development.

10. In a linear approach, each stage of the policy development process tends to be siloed. Each silo has its own area of expertise and skill. As the policy moves from one silo to the next, the implicit assumptions about the policy made within each silo compound at each stage of the process. Different siloes in a linear policy process must explain the policy not just to the world at large (in the final legal instrument), but also to each other as the policy moves from one stage of the process to the next.

11. This intra-government translation process is the reason why the better rules approach emphasises the production of common knowledge assets. These knowledge assets are produced by multidisciplinary teams sitting across the various siloes and can be used in any of the various siloes in the policy process. These knowledge assets are primarily the concept model, decision flow diagram, and rule statements (from business rules modelling approaches). However, one additional knowledge asset that has captured attention is the coded computational model of the regulatory system or policy as produced from those assets.

12. The coded “rules-as-code” model of the policy is simply another tool for facilitating communication between policy development siloes. Those knowledge assets are designed to require the implicit assumptions held by different actors to be stated explicitly, reducing the likelihood of “incorrect translation” between stages in the policy process.

13. We pause to note that, from the very initiation of a “better rules approach” as first described in the Discovery Report, there was the intention that the rules of government be drawn from legislation, policy and business rules, and that these rules would be incorporated directly into coded systems that are used to implement government policy. Also, there was some suggestion that, through a process of parallel drafting, the “translation gap” between legislation and other human readable sources of the rules and the software implementation of them could be not just reduced, but at times removed entirely.

Features of a better rules approach

1. Having dealt with these points, we summarise our view that a better rules approach has the following features:

   1. Policy is developed using a multi-disciplinary team. To our understanding, this is a departure from the usual policy development approach. This is a significant point to note when assessing the overall relative merits of wider adoption of a better rules approach.

   2. The multidisciplinary team includes policy professionals, legal experts (lawyers), legal drafters, service designers, business rules analysts and computer programmers. This facilitates a wide perspective on the topic being considered in relation to policy development. The approach aims to be user-centred, co-creative, evidence-based and holistic.²² The different skillsets of all members contribute to the process. Communication across disciplinary boundaries can be difficult, but being able to identify areas of miscommunication or misunderstanding between these groups is a beneficial and essential part of the process.

   3. To date, there has been less observable emphasis on the formal inclusion of people outside government employment who are intended to be the recipients of these services. Service designers are the primary way of capturing the needs and experiences of people outside government in a better rules approach. We think there is a further significant opportunity to incorporate the perspectives of people outside government into the policy development process through a comprehensive better rules approach that includes them .

   4. Like Rules-as-Code approaches, a better rules approach incorporates skillsets from computer science and business process modelling, including concept modelling, decision flow diagrams, and rule statements. The primary purpose of using these methods is to clarify the intended regulatory system being developed: they clarify policy intent.

   5. The use of these “knowledge assets” (concept models, decision flow diagrams, rule statements) reflects the holistic perspective brought by service designers. A service design approach accounts for the way many of the “rules” produced through a policy development process will eventually be implemented in digital systems. These rules will influence the way a service is delivered, whether they are derived from legislative instruments or not. Other non-legislative instruments (including the limitations of software design or code) can also exert a normative influence. A core goal for some better rules and rules as code advocates is to better account for the source of various rules that comprise an overall regulatory system so that the legitimacy of rules can be assessed, and the comparative significance of legislative rules can be incorporated by contrast with other rules and limitations, such as the limitations of software systems or the imperatives of operational delivery.

   6. The better rules team produces an array of outputs. One possible output includes rules-as-code: by “rules-as-code” we mean a computational model of the intended regulatory system. This model will include both legal and non-legal rules. The model, because it is intended to be computable, is produced in machine-executable languages. Based on workshops run to date it has been recognised that the act of attempting to code the rules is valuable, even if the coded model is eventually discarded.²³ This is because the team must attempt to “explain” the policy to a computer system, which does not share the assumptions and contextual understanding of the team.²⁴ Whether or not a coded model is ever executed, the process alone serves to highlight whatever assumptions and implied contextual factors that have been brought by the policy development team. Without being surfaced in this way, these assumptions might otherwise have been implicitly incorporated into the policy design, and only surfaced later at the point of service design and operational delivery.

   7. Another output produced from a better rules approach is a list of questions that the regulatory system or computational model requires to be posed to a user (or service designer). The list of questions reflects the need to identify “inputs” to both the policy system and the computational model. The team identifies these questions/inputs during the better rules process. For example, if eligibility is based on age, service designers will need to ask questions such as: what is your birth date; are you over the age of 18; what is your age; etc.

   8. Identifying these questions compels the team to identify the kinds of inputs that will be required to answer those questions. It also enables consideration of how the inputs would be implemented in a digital (coded) system. This in turn enables the team to consider whether those inputs can be drawn from existing records or whether they will require data entry by a human. Accordingly, areas of judgement, ambiguity and discretion can be identified, as well as inputs that cannot be drawn directly from digital datasets. This is also important from a service design perspective. It enables the team to consider the burden that a regulatory system puts on citizens or staff having to enter those inputs. It is also possible to assess the overall “computability” of a legal instrument or regulatory system based on the extent of human input required in order for the computational model of the system to operate.

   9. By representing a policy or regulatory system in code, this enables the use of software development techniques to test and assess the proposed policy system represented in the code. One promising opportunity is to use “test driven development” and test suites. Test suites are used extensively in software development. They have also been used in rules-as-code demonstrations. France has used the OpenFisca platform to model its tax and benefits system and subsequently used test suites to assess whether or not the model (and by implication the relevant regulatory system) was performing as expected.²⁵

   10. Within the Better Rules workshops, test suites were easily understood by the non-programmers on the team. Test suites worked as a bridge between programmers, non-programmers, and the coded model. If a non-programmer had a question about the implementation of a policy, they could propose a test, and see how the model responded to it. In the policy space, test suites can be seen as a crude (or brute force approach) to capturing policy intent. Testing is, at its essence, a collection of scenarios represented by input data and the expected outcomes to be produced by the system when presented with those inputs. By contrast, policy development and legislative drafting is normally directed toward expressing the rules and guidelines that link those inputs and outputs (which are finite and reproducible), rather than the inputs and outputs themselves (which are potentially limitless in their scale and variety).

   11. Test suites offer a way to retain institutional knowledge that arises during the policy development process by illustrating what a policy development team intended to be the output of a coded model or regulatory system when presented with particular inputs or scenarios. The test suites can be preserved as another “knowledge asset” in a better rules approach alongside the coded model of the system.

Goals of a better rules approach

1. Considering the expansive discussion above, the goals of people pursuing a better rules approach appear to include the following:

   1. Achieving improved clarity, logical consistency, and conceptual coherence in a policy or regulatory system being developed.

   2. Any policy in development will have been examined and investigated thoroughly from a multidisciplinary perspective that includes consideration of factors relevant to service delivery, implementation and operationalisation.

   3. Anticipating how a legal instrument is to be operationalised in computer systems, thereby reducing the frequency of situations where the Executive must make potentially unwarranted implementation decisions in situations where the statute is silent or ambiguous.

   4. Assisting in the preservation of institutional knowledge about a particular policy while it is under development (e.g. through test suites and knowledge assets like concept models).

   5. Identifying unintended gaps in regulatory systems and legislation.²⁶

   6. Providing a methodology through computational modelling for allowing large enactments to be restructured in a way that tracks the way original policy intent may have changed or not, for example through the use of test suites.

   7. Ensuring that, using a service design approach, the implementation of the legislation in an operational setting will not undermine the overall intent and purpose of the Act. An example is the use of a better rules approach to make changes to the New Zealand Rates Rebate Act by removing the mandatory requirement to make a statutory declaration. This improvement was identified through service design processes that noted how this procedural requirement in an operational setting was working to undermine the purpose of the Act²⁷)

Comparing better rules with ‘Rules as Code’

1. There exists no specific authoritative definition of “rules as code” and so this analysis is based on our own impressions, including the sources used above to comprehend a better rules approach.

2. The term “rules as code” is mostly used as a rallying point or hashtag (#rulesascode) to encourage a wider conversation engaging the many perspectives and practices that surround the practice of putting these two fields (“rules” and “code”) together.

3. Academic practitioners with expertise in computational law have also grappled with understanding what “rules as code” specifically refers to, both by way of inclusion and exclusion.²⁸

4. One useful historical artifact is a PDF archive of a discussion forum around “Better Rules”, which also frequently uses the phrase “rules as code”.²⁹

5. A report by the OECD entitled “Cracking the code” provides an extensive look at the term (see Part 4, OECD Primer).³⁰ In the primer report prepared by the OECD, the authors took an approach of defining what rules as code is not, rather than what it is, partly to respond to fervent and repetitive disagreement about the concept in online discussions. There have also been articulations of both “wide” and “narrow” understandings of the term,³¹ as well as distinctions between rules as code as a process (referring mainly to a better rules approach) versus rules as code as an output.³²

6. Our description seeks to extract the key conceptual points that frame the recent discussion primarily to contrast it from a better rules approach as we understand it.

Goals

1. A fundamental perspective of the Rules as Code movement is that coded rules giving effect to a policy, legal, or regulatory system could be elevated from their incidental existence as a tool of operations to being purposefully and structurally designed. They could then be incorporated into software systems as well as being published openly for whatever uses might be identified.

2. Within the rules as code movement, “rules as code” (or coded models of the law) can be produced from legislative instruments and other sources of “the rules” once those rules are already in effect. A key insight from the Better Rules Discovery projects is that this was a very difficult task when legislation had not been produced with digital systems in mind, hence the emphasis on using various approaches to improve the policy development process itself.

3. Once rule-sets have been coded, the clear intent in a rules as code approach is that these rules should be a reliable indication of what “the rules” require. These rules go beyond mere guidance, to the point that they can be relied upon for the purposes of assessing legal compliance or even to form a regulatory base layer for government as a platform.

4. Projects like the open-source platform OpenFisca have been influential in shaping the shared values and vision that do exist around the term rules as code. These include:

   1. Coding rules modelled directly from legislation and publishing them in an open and reusable format.

   2. Publishing services that allow people to navigate the coded rules to understand how the rules apply to their situation.

   3. Using coded rules to inform and model changes to the law for research purposes.³³

5. Rules as code advocates frequently point to the opaqueness, inscrutability and inaccessibility of written law to the average person and argue that rules (understood to include law) represented in code would enable the use of software systems to understand what the law requires people to do.

6. In an Appendix, we include excerpts from the OECD primer that clearly anticipate that “rules” include a wide range of sources that give a guide to conduct, and importantly include legislation and case law as well as non-legal materials. Generally speaking, there is not always careful distinction between the way that the sources of “the rules” might affect the legal character of the “rules as code” being produced.

7. By publishing “rules as code”, advocates suggest the following outcomes can be achieved.

   1. Society (or rule-takers) could leverage computing platforms and tools to create the means of ensuring that, in line with one goal of the rule of law, “the law should be clear and clearly enforceable”.³⁴

   2. Further, it is suggested that coded rule sets can be published in a way that structurally separates the logic of the rules (their syntactical structure) from the way the law is applied. This facilitates the incorporation of rule logic into government department software architecture. If further steps are taken to make the code publicly available, it allows government departments to be “open by default” and allow users to see how “the law” has been incorporated as code directly into software operations.

Features

1. Recent advocates for rules-as-code posit the following features and desired ffects:

   1. Implementing law and legislation in digital systems (in “code”), including the assessment of compliance with the law through digital systems.

   2. Publishing law and legislation in coded form, or in machine-executable languages, with the intention that such published code be relied upon by the community at large.

   3. A focus on reducing the “translation gap” between the law and the computational model of the law, and in some cases, attempting to leave no translation gap at all through one-to-one correspondence between the expression of a rule in machine executable languages and in natural language.

   4. The use of computational models of “the rules” (including the law) that can be produced by government and relied upon by citizens and executive government staff. This is a key foundation of the “Government as a Platform” concept, ³⁵ and advocates see availability of such models creating the means for wider integration between government and non-government entities through digital platforms.

   5. As with better rules approaches, a shared use of techniques from computer science and business process modelling, including concept modelling, decision flow diagrams, and rule statements to produce a coded model of the law.

   6. A greater emphasis on legal instruments that already exist, rather than legal instruments under development in the policy process (by comparison with a better rules approach).

   7. Incorporation of other concepts from the field of software development including sandboxing, version tracking software (such as git), and virtualisation (digital twins).

   8. An open approach to how operational rules (including legislation) will be implemented in digital systems, leading to wider scrutiny and public ownership of any particular coded rule set used in operations. Advocates argue that public availability of these coded rule sets would allow incorrect legal interpretations of the law in software systems to be identified more quickly.³⁶

Brief history of law and code

1. In response to a primer written by the OECD on “rules as code”, scholars with an extensive history of exploring law and code have noted that rules as code is effectively a new label, attitude or approach to a well-furrowed concept.

2. There is a complex body of scholarship on the interaction between legal systems and computer systems. Some of this scholarship deals with the theoretical and jurisprudential questions raised by modelling law in code and implementing those coded models. Some of this scholarship focuses primarily on the constitutional implications of using code to achieve legal objectives. Other scholarship touches on the way democratic legislatures might be capable of implementing law that protects individual privacy, copyright, and any number of other legal concepts in an age of pervasive computing technologies.

3. We think there is a significant link worth exploring further between the way that better rules and rules as code approaches owe their lineage to business process modelling techniques, including the use of computational languages and systems for modelling business compliance with law and other regulatory instruments. Policymakers should also be aware of the influence of RegTech and FinTech principles and motivations behind the renaissance of law as code concepts in the contemporary better rules and rules as code movements.

4. The practice of intentionally implementing law in and through computer systems has a long history. In recent decades, the most notable application was research and development of “Legal Expert Systems”. that was particularly prevalent during the 1980s and 1990s. There is a substantial body of legal and computational academic research detailing the challenges of building such systems.

5. New Zealand’s Accident Compensation Corporation has explored the use of better rules approaches for a structural rewrite of its governing legislation, but it has a longer history of attempting to model legislation in machine languages. From discussions with people involved at the time, ACC had previously attempted in the 1990s to encode the incoming ARCIC 1992 in the Prolog language for implementation in software systems and for claims triaging.

6. Generally, by contrast to more recent rules as code initiatives, research into legal expert systems placed lesser emphasis on the public production of coded rule-sets for reliance and use, and a greater emphasis on building systems that would enable people to pose and answer legal questions. The potential uses of such systems were cast broadly and included, for example, an attempt to predict and model judicial reasoning in litigation without using statistical methods, as well as extracting normative rules from difficult source material such as case law.

7. The history of modelling law in computer code has numerous methodologies, technologies, and techniques. To aid in understanding this practice we believe there are a few main objectives with differing core objectives that seem to dominate law as code attempts.

   1. Legal information retrieval. This area of scholarship aims to standardise the way legally relevant sources of the law are standardised, categorised, and able to be retrieved by software systems. This area falls largely outside our immediate focus.

   2. Providing authoritative answers. This was often the objective of the Legal Expert Systems of the 1980s and 1990’s. This is generally the most obvious objective for people first introduced to the concept of code as law. Expert systems were rule-based artificial intelligence systems that combined expert information and a logic for solving domain-specific problems that replicated the process of human experts. The goal was to be able to seek legal answers to legal questions from computer systems.

   3. More recently, Legal Expert Systems scholarship has shifted to simply modelling an interpretation of the law, without aiming for authoritative answers.³⁷ This approach is underpinned by the idea that code may never adequately mimic the features of natural language nor the authority of the written law. As such, any coded model of the law can never be considered absolutely correct for all tasks in all cases. Subsequently, this approach focuses instead on achieving a sufficient interpretation, or producing a software system that operates in partnership with human operators as a decision-support system.

8. We say that the aim of some contemporary rules as code advocates are the same as those of the builders of legal expert systems: they wish to build models of law that can in any case be relied upon to conclusively answer legal questions, to the point that they can be automated and systematised, to form a regulatory base layer for digital government.

9. In a useful article, Greenleaf, Mowbray and Chung succinctly state important historical features of the AI & Law movement which should have direct bearing on development of Rules as Code approaches, saying “it is important to realise that this field is not a tabula rasa.”³⁸

10. One crucial insight from the history of developing legal expert systems is the way that legal expert systems rely on knowledge-bases which are shaped through the legal interpretation of the law, as formulated by the people who created that knowledge base. Another crucial insight is that legal expert systems will never be exclusively technical: they require inputs, assessment and interpretation by a human user in order to function correctly.

11. Greenleaf et al summarise these insights into a 15-point list, which is further summarised as follows (although edited for length):³⁹

    … looked at from the user perspective, … what counts as a useful level of legal expertise is relative. A system may be valuable to a class of users even though it has a relatively low point at which it admits that a problem is beyond its expertise, and it may serve as a method of triage. … [I]t is not realistic to try to build legal expert systems that encapsulate all the knowledge necessary to answer user problems … The more realistic aim is to build decision support systems, in the use of which the program and the user in effect pool their knowledge/expertise to resolve a problem … Expertise can and should be represented and utilised by pro- grams in many ways … This means the knowledge- based system (the knowledge representation and the program) should not be ‘closed’: it must be integrated with text retrieval, hypertext and other tools which allow and assist the user to obtain access to whatever source materials are necessary to answer the parts of a problem dependent on the user’s expertise … The result is an integrated decision-support system.

12. Greenleaf and colleagues have recently demonstrated the value of this historical expertise to the rules as code community. In 2020, the New South Wales government released a computational model of gaming regulations intended to enable people to understand their compliance when running community gaming (or gambling) events. In reply, Greenleaf et al demonstrated that their DataLex system, which is the product of decades of legal scholarship and computational development, could produce a coded rule-set in approximately 24 hours.⁴⁰

13. The lessons from those building Legal Expert Systems therefore must be considered. In the extract below, Greenleaf et al state the conclusions reached by builders of such systems at the time, and the importance of interpretation both legally and factually:⁴¹

    The aim in building legal expert systems is not to build a ‘robot lawyer’, which simply extracts unproblematic facts from a user and then comes to a conclusion. Almost all systems require the user to provide some degree of interpretation of the questions asked, and the sources of law involved, requiring at least a minimal level of interpretative skills. The real model of a legal expert system is therefore one of collaboration between a semi-expert computer system, and a semi-expert user, with control of a problem’s resolution alternating between them. The aim is to support decisions made by human users. The result is best described as a ‘legal decision support system’, rather than an ‘expert system’ or ‘robot lawyer’.

14. Greenleaf et al also emphasise that “interpretation issues cannot be eliminated from “knowledge-bases” that inform rules as code / legal expert systems:⁴²

    Access to legal sources and other forms of legal expertise is almost always necessary, except in the most trivial of legal expert systems, because interpretation issues cannot be eliminated from knowledge-bases. This means that inferencing systems cannot be ‘closed’: they must give users access to the legal sources on which interpretation is based. Because law is constantly changing (most notably, by the creation of new case law), if such access is to a limited set of resources (‘closed’ in another sense) it will be unsatisfactory. From a user perspective, inferencing systems must be as open as possible to all relevant legal resources, primary and secondary.

15. We do not make these points to diminish the potential of modern rules as code, law as code, or better rules approaches – or the standing of their respective advocates. Instead, we believe it is essential to briefly note the existence of these issues as the tip of a significant iceberg of scholarship.

Conclusions on Better Rules and Rules-as-Code

Endorsing a better rules approach

1. Rules as Code is a term that is used in a discussion forum created for the purpose of discussing “Better rules”. It began to be used in the context of an international movement inspired in part by the better rules approach and the Better Rules programme.

2. The focus of rules as code as we see it is taken to be much more focused on the use and implementation of coded rule-sets, with less emphasis on the use of modelling and service design in policy development.

3. People sometimes use the “rules as code” label to refer to what we have described here as a better rules approach. There are also examples of better rules advocates focusing primarily on the alleged benefits of using and implementing a rules as code output produced during the better rules process. We raise this to highlight the challenge of determining the boundaries and overlap of both concepts.

4. We define a better rules approach as follows:

   1. the use of multidisciplinary policy development methods and expertise;

   2. to enhance the conceptual coherence and logical consistency of a policy initiative;

   3. with a view to its superior expression in natural language legal instruments;

   4. and consideration of how that policy or regulatory system (as bounded by the legal instrument) will be implemented as a matter of service design, both by human and digital systems.

5. The better rules approach is an attempt to develop legislation and regulatory systems in ways that make them more amenable to being operationalised in digital systems while minimising the kind of unwarranted interpretive leaps that must sometimes be made by executive agencies created coded interpretations of the law.

6. A better rules approach is also a way of ensuring that delivery of policy through digital systems adheres closely to Parliamentary intent, as expressed in legislative language. In this sense, it has positive democratic implications for the use of software to deliver government services.

7. As we discuss in the next part, our concerns about better rules and rules as code approaches stem from situations where the legal status of the rule sets produced, by comparison with legislation itself, are said to be equivalent.

8. In particular, we explain why there are risks to any apparent lack of critical appreciation about the role of natural language for statutory interpretation and the separation of powers, and the value of interpretability in natural language legal instruments.

The process of modelling is often more significant than computation of the model

1. When a policy or regulatory system is modelled in code using a better rules approach, it is important to recognise that the task is often more about creating and mapping the concepts and their relationships to each other than it is about creating computational formulas. The resulting models capture what often is the most complex aspect to law; understanding what parts are pertinent to a given situation and what questions need answering.

2. We are persuaded of the benefits that can be derived from creating accurate, reliable and accessible coded models of the law and its legal effect, but these benefits equally derive from modelling a wider regulatory system or the way a policy will operate. By a “coded model” we mean a sort of schematic (or “blueprint”, as the better rules community often describes it) of a particular legal or regulatory system or a device that allows users to gain a better understanding of how the law affects them in any given activity. Such models can be instructive, promote efficiency, reduce barriers to accessing justice, and reduce the risk of misunderstandings between legal parties.

Fairly comparing legislation to code

1. One point to emphasise is that the advantages of enacting law in code should be compared with statutory drafting as it is now, not as it was in the past. In New Zealand, for example, there has been a demonstrable shift to plain language drafting and drafters internationally use a range of digital tools, including extensible mark-up languages (XML).⁴³

2. Drafters have been aware of the ambiguities that can be created by imprecise use of logical operators for decades, and avoiding undue syntactic ambiguity is a basic expectation of legislative drafters.⁴⁴ If vague or semantically ambiguous drafting has been used, that is generally because it is what is required to pragmatically and constitutionally give effect to the intended policy as understood by the drafter.

3. Many legal instruments may be drafted without access to people with specific drafting skills, including contracts, or secondary legislation, and this can produce very poor legal instruments. But legislative drafting is seldom if ever done by untrained drafters.

4. It is important to bear in mind that not all drafting is done under ideal conditions, even where the drafter is highly skilled and experienced. One of the greatest benefits of a better rules approach is the way that it tightens ambiguity in a policy before the policy is given to a drafter for legislative drafting. Equally, the preparation of a variety of knowledge assets – such as the concept model – is an important way of communicating policy intent, and thereby enhancing legislative drafting.

Imprecision can be modelled, but not automated

1. Imprecision in the law, or ambiguity in natural language legal instruments, might be thought by some to make modelling of the law impossible. In practice, coded models can incorporate mechanisms for human input, where an input would otherwise not be able to be computed.

2. The task of coding a rule-set means that areas of computability and non-computability can be identified, which can be beneficial from the service design perspective at the heart of better rules.

3. It is possible and programmatically simple to incorporate human discretion into a computational model as an input to the model’s operation, however this human discretion element cannot be automated.

4. Importantly, the deliberate modelling of imprecision in a computational model does not avoid the initial step of interpreting the law in order to decide how that model should be constructed. The decision about where imprecision exists in legislation and how that is to be reflected in a coded rule set as drawn from legislation is fundamentally a matter of legal interpretation, and in principle contestable.

The sources of the rules

1. When producing coded models of “the rules” or “the law” or a wider regulatory system, it is essential to maintain a distinction between various rules based on their source and the authority they carry. A legislative rule should generally always override a rule based on operational policy and practice, for example.

2. Descriptively, based on documentary materials describing better rules and rules as code, it is difficult to say whether these important distinctions are always taken into account by all advocates for rules as code or better rules approaches.

3. When rules as code or better rules approaches sit exclusively within government, there is a risk that they become too inwardly focused. There can be a temptation to treat operational policy interpreting the law as having equal weight to the law itself.

4. Some advocates clearly express the intention that coded rule sets will be used for assessing legal compliance. Despite this, in some cases, the “rules” of the system to be coded appear to include sub-legislative or extra-legal sources of rules, such as organisational practice and policy, or “policy intent” as understood independently from the Parliamentary intent manifested in statutory language. There is not always clear consideration of the way that incorporating these non-legal or extra-legal rules might affect the legality of the coded rule-sets being published or operationalised.

5. It is equally important to note that, for others, this ability to clearly ascertain the legal authority for a coded rule within a rule set is a core benefit of a better rules approach. Presently, digital systems used by the state can incorporate normative limitations that stem from the software system itself or from operational limitations, not from the law itself. By preparing coded models of the law (during policy development or after legislation is passed), there can be enhanced transparency about when a rule is drawn from an authoritative or legal source, as opposed to when it has been introduced due to other considerations.

6. Isomorphism, in a law as code context, refers to the traceability and structural similarity between a coded representation of a rule and its legal source. It is desirable because it allows a coded representation of a rule to be traced back to its authorising source, as well as to scrutinise that rule for the faithfulness and accuracy of its interpretation.⁴⁵ This traceability is a key goal for some better rules and rules as code advocates.

7. Given the links between the rules as code movement and the public service, the authority to dictate an operational interpretation of what “the rules” mean to the community at large is often taken for granted.

8. If coded rule-sets were to be created by non-government actors, we suspect the distinction between legal rules and extra-legal (or non-legal) rules would be more carefully observed. Coded rule sets created by non-government actors that are not legally compliant can be simply dismissed by government regulators. By contrast, a non-government actor seeking to displace a coded rule set used by a government agency faces much greater barriers to displacing that rule set, such as litigation or administrative and judicial review.

9. In summary:

   1. It is essential that any coded model of the law that is to be treated as a guide to what the law requires people to do must carefully distinguish between rules in the model drawn from the law itself, and rules in the model drawn from non-legal sources like policy instruments, business rules, or operational considerations.

   2. For some advocates of better rules approaches and rules as code, achieving this careful distinction between the legal authority of coded rules is a key goal and contended benefit.

Legal implications of “code as law”

1. Our overarching impression is that recent work around rules as code and better rules shows a lack of understanding around the constitutional implications of both approaches. There is little attention to the role of the separation of powers, the independence of Parliamentary Counsel, case law, contestable legal interpretation or legal argument, and the constitutional significance of the judiciary.

2. Some rules as code and better rules advocates clearly intend to create legislation-as-code that leaves no room for interpretation at all.⁴⁶ That may be acceptable when it comes to some kinds of legal instruments, or various policy or rules-based instruments that sit below the status of legislation, however to suggest that Parliament should pass legislation that, by its architecture, permits no interpretation, should ring significant constitutional alarm bells.

3. The constitutional implications of using computers and principles of computation to deliver legal effects is the predominant focus of this report.

4. Finally, we note that the New Zealand Parliament has created a range of legislative mechanisms for both:

   1. revising the wording of legislation where it is unclear or to take account of technological changes (discussed in Part 3); and

   2. also to delegate authority to an AES to exercise legal tasks (discussed in Part 4).

5. In Parts 3 and 4, we explore the way that these existing mechanisms can be used to give effect to the key benefits of better rules and rules as code approaches, without undermining constitutional principle or undermining the status of natural language legislation as a key method of balancing and separating power in a constitutional democracy.