It is difficult to comprehensively define what a better rules or rules as code approach is about. In this appendix, we collect notable statements about better rules and rules as code as drawn from selected promotional and publicity materials about those concepts. We do this to provide some basis for the way we describe them in Part Two and illustrate what we have in mind when we have stated our conclusions about the merits of those approaches.
It would be unfair to take a video or a website as being a comprehensive and exhaustive expression of the Better Rules programme as a whole, let alone the views of various proponents of better rules or rules as code approaches.
With that limitation in mind, such videos and promotional materials do give some sense of what people associated with such approaches may think are appealing benefits of it. Further, they are important guides to the kinds of messages that senior policymakers and Ministers might be receiving about the better rules approach which may require critical examination.
We emphasise at the outset that we are only including selective statements that go to our core subject of investigation: the extent to which law and code can have equivalent meaning and effect such that “machine consumable legislation” could be more widely adopted.
We have not included comments that go to the way a better rules approach merely improves policy development in order to produce higher quality natural language legislation: this is because we think the benefits of this approach are uncontroversial and we have articulated why in Part Two.
It is only when it is suggested that machine-consumable and natural language legislation should have the same legal status, or that their meaning is identical, that our concerns are engaged. The following statements are illustrative of those concerns.
The first significant articulation of what a “better rules” approach involves is documented in a discovery report from 2018.
One point we also note is that absence of any translation gap can be understood at two points in the better rules process: first, at the policy development stage, as a policy project moves between different government siloes; second, at the point of policy delivery, where machine-consumable and natural language rules are taken to express identical intent as well as identical effect. It is the latter of these two stages that we are examining.
We think the core promise of the better rules approach is summarised as:
“We believe that co-creation of software and legislation is possible today, and with the addition of the right software tools, there is an opportunity to have an isomorphic output that can generate the knowledge assets which convey the policy intent and legislative meaning to all interested and affected parties.”
It is not clear how “isomorphism” is intended in the better rules discovery report. At times, it appears that isomorphism is understood as referring to an absence of any translation gap, or the presence of equivalent meaning, between the code and the sources of the rules. By contrast, in the academic literature, isomorphism is better understood as traceability or correspondence, which acknowledges that users of a coded system will need to trace coded rules back to their primary source materials in order to assess whether an interpretation is acceptable, and how to interpret the coded rule for themselves.144 At times, bare traceability is apparently envisaged. At other times, absolute equivalence between machine and natural language rules is touted as a benefit.
In the report, the authors summarise the value not of a better rules approach, but instead of “machine consumable legislation”. Within the list itself, values are described as relating to either “legislation or business rules” being machine consumable “at the creation of rulesets”. Along with “faster implementation of policy” and modelling of policies before they are implemented, one value is to:
remove the “translation gap” that currently exists between policy and legislative intent, and the software that is developed to support service delivery
While the risk of incorrect translation might be minimised, it is too far to suggest it can be removed entirely. We also note the way that policy intent and legislative intent are merged, despite the way that policy intent derives from the executive, and legislative intent is inferred from the text and purpose of Parliamentary instruments.
At the outset, we note that the discovery report proceeded by adopting the methods used by the Inland Revenue Business Rules team. Core to the better rules approach is the influence of business rules modelling approaches and the core knowledge assets – the concept model, decision/flow model, and rule statements – are drawn from business rules processes.
Approach to experiments – Each team followed the approach the IR Business Rules team takes when mapping out rules by creating a concept model that describes the discrete concepts of the Act (or part thereof) and the relationships between the concepts, … Then we developed decision models where the eligibility or entitlement criteria are clearly mapped. The concept and decision models were iterated as the teams either refined the rules (in the case of the Holidays Act) or better understood the rules and their logic (in the case of the Rates Rebate Act). Each team used the models they had created as a basis for common understanding and from which they could generate: 1. pseudocode, or rule statements that detail the logic of the rules in a human readable format; 2. human readable legislation; 3. software code.
Notable statements in the rest of the report include:
We note here the references to “machine and human consumable rules that are consistent, traceable [and] have equivalent reliance” and the “use of machine consumable rules by automated systems” to provide feedback into the policy development system.
We concluded that the initial impact of policy intent can be delivered faster, and the ability to respond to change is greater, with:
- Multidisciplinary teams that use open standards and frameworks, share and make openly available ‘living’ knowledge assets, and work early and meaningfully with impacted people.
- The output is machine and human consumable rules that are consistent, traceable, have equivalent reliance and are easy to manage.
- Early drafts of machine consumable rules can be used to do scenario and user testing for meaningful and early engagement with Ministers and impacted people or systems.
- Use of machine consumable rules by automated systems can provide feedback into the policy development system for continuous improvement.”
We recommend the method of setting out translations in the tables on p 22 that clearly illustrate how the natural language has been interpreted into pseudocode, and allows scrutiny of whether those interpretive steps are justified. Then, the software code sits alongside the pseudocode. Clearly, performing this exercise for an entire Act would be complex.
We also note that groups of users of “rules” are set out. The following entities are all grouped under the heading of “regulators”, despite the important constitutional differences between, for example, parliamentary, executive, and judicial actors:
Regulators (including government departments, judiciary, policy analysts, legislative drafters, select committees, Treasury, and international groups) who use the rules when: monitoring compliance with the rules; understanding how the rules are being used; developing, testing and modelling changes to the rules, and validating the quality of this modelling.”
Finally, under the conclusions section, we note the following statements:
A website for Better rules accessed in June 2019 includes the following statements.
“[Better rules] is about re-imagining regulation as an open platform based on logic, decision models and rules – also known as ‘legislation as code’. We are reframing the regulatory design process using an end-to-end system design approach to enable regulation to be more easily implemented as part of NZ government’s digital services for citizens and businesses.”
“The problem[:] The traditional models of creating, managing, using and improving the ‘rules’ of government (policy, legislation, regulations and business rules) were developed for use in a non-digital environment, and can result in a mismatch between policy intent and implementation.”
“Better Rules is about policy-makers, regulators, legislative drafters, service designers, software developers and impacted people working closely together to clearly articulate the rules underpinning the regulation and how those rules will actually work in practice.”
“If we consider the future state, the code/machine consumable version of the regulation would be available from a single source.”
“It ensures that regulation is developed to be machine-consumable – in parallel with the (current) human-readable version.”
An updated version of the same site, accessed January 2021, includes the following statements:
A promotional video for the Better Rules approach includes the following statements of note:
The project is described as relating to legislation as code as well as rules as code and better rules. The first subheading is: “What are Better Rules and Rules as Code (aka Legislation as Code)?” The summary of the work is:
This important work started when looking at Rules as Code as part of the Lab’s reusable components workstream. The team soon realised there was a systemic issue that other agencies were interested in exploring how to ensure government rules could be accurately delivered as Rules as Code without creating yet another siloed version of the rules (which is essentially what happened with the coded legislation behind the SmartStart financial help tool).
In more detail, the work is explained as follows, and we note the reference to “unambiguous” rules, the focus on “what the government really intended when creating … rules”, the reference to business rules and use in the IRD:
Imagine if the creation and implementation of government ‘rules’ (i.e. legislation, regulation, policy) was multidisciplinary, more open, participatory and robust. What if these rules were unambiguous, and understandable and usable by both people and digital government services from the day they are enacted?
Better still, what if the wording and logic of the rules was drafted by a multidisciplinary and multi stakeholder team to better capture what the government really intended when creating or amending rules?
The practice of making business rules directly available to digital systems as software code has been around for decades, e.g. for tax calculator tools on the IRD website, or internal business systems within government departments.
The Service Innovation Lab does articulate a clear distinction between: Rules as Code – a “reinterpretation” of the rules after they have been written; and Better Rules, being testing implementation logic and service design impacts during the drafting process.
This approach [in the immediately preceding quote] can be thought of as Rules as Code. This is usually done after the rules have already been written and requires a reinterpretation of the rules by service delivery people and software developers. This has proved a risky approach where implementation by government and non-government organisations are out-of-step with either the intent or the actual rules.
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’.
Along with this much clearer emphasis on the distinction between Better Rules and Rules as Code, there is a clearer articulation of the benefits of a better rules approach, independently of whether the coded model of the rules is ever implemented, let alone treated as “the law”:
[Better Rules] brings multi-disciplinary teams together to look at what’s proposed in a Bill or Amendment: People from policy and operations, software developers and those working on the delivery side: working together to virtually model and test the draft rules, using real data and likely scenarios, to ensure the rules are implementable and more likely to achieve the intended outcome. This represents a real sea change for governments, allowing simultaneously for more complex and more comprehensible rules that can better adapt to edge cases. This is not only about harnessing the speedier benefits of digital. There’s less risk of misinterpretation. It means more issues and errors are identified before the legislation is passed through the rapid iteration of the rulesets during their development. The approach is also more democratic, supporting open, transparent government and enabling NGOs, communities, social enterprises and the private sector to be part of the government services ecosystem.
What is significant is the emphasis on “less risk” of misinterpretation, rather than the absolute removal of any interpretation exercise.
This resource also outlines a history of how the better rules approach, its demonstration internationally, and how it has shifted into its “rules as code” incarnation. Reference to the OECD primer in May 2020 suggest the site has been revised since 2018:
At the end of 2018, the Lab collaborated with counterparts in Israel and Uruguay to build a small Legislation as Code demonstrator to explain the concept using pension eligibility as the example. This was shown to the D7 (now Digital Nations) Ministerial Summit in Israel. Global interest in the Better Rules and Rules as code approaches accelerated after the OECD’s Observatory for Public Sector Innovation selected the Better Rules approach from over 500 public sector innovation case studies to be included in the Embracing Innovation in Government Global Trends Report 2019. The Governments of New South Wales, Canada and the US have since conducted their own Better Rules and Rules as Code experiments. In September 2018 a global Better Rules online discussion forum was launched. Lively discussion is ongoing in this forum as well as on Twitter (#rulesascode, #legislationascode, #betterrules) and LinkedIn (#rulesascode, #legislationascode). By 2019, Better Rules had become its own programme led by MBIE and supported by the Lab. The OECD released a draft rules as code primer in May 2020 as a way to collate everything that is currently understood about Better Rules and rules as code at this time
The site includes a link to a video by Brenda Wallace, an original participant in the Service Innovation Lab and the Better Rules discovery. It was recorded in 2019 and is a useful contemporaneous record of how better rules was perceived at the time.145
We were given access to some speaking notes in relation to an address given in July 2019 from a legislative drafter who had been involved with advocating for better rules.
The speaking notes illustrate the way that a very narrow definition of a better rules approach can nevertheless morph into an argument in favour of direct implementation of rules as code instruments, as if they have equivalent meaning to the legislative instrument. The notes also suggest that the role of interpretation can be minimised and it would be desirable for end users if interpretation could be completely avoided.
The notes begin by articulating how legislation is increasingly implemented in software systems and poses the proposition that software systems themselves are “users” of the law. It also notes the way that software can have normative effects in influencing human behaviour.
Technology is an integral part of the way we live our lives, answer our questions, and access our goods and services. As many of our rules are set out in legislation, the software that drives that technology needs to reflect relevant rules set out in that legislation. This has created both a new audience for legislation, and a new way in which it is used—legislation is “consumed” by machines. Software, and the algorithms within it, are like an invisible level of law – they operate things that provide our day-to-day interface with the law, but are not currently seen, or visible in legal terms.
The speaker suggests that legislation is inaccessible to humans, and therefore legislation should instead be prepared to provide clear answers through software systems.
Let’s be honest – the general public doesn’t particularly care about legislation itself, and they don’t want to have to read it, and understand its meaning and implications. What they want, is an answer to a question about something real that is going on in their lives. How do a I get a fishing licence? Am I eligible for financial assistance? Can my neighbour build a fence that high? Increasingly, people find the answers to those questions directly from a computer. So, we can no longer assume that the primary audience for legislation is a human one – many of our rules are now primarily consumed and used by machines, and those machines are then used by humans.
The speaker notes a distinction between machine readability and machine executability, and the way that New Zealand legislation is already published in machine readable forms.
New Zealand’s legislation is currently published in human readable formats (PDF and HTML) and a machine readable format (XML). XML by itself cannot be directly integrated into a digital system, however, because XML is simply a way of presenting human readable text in a more structured way. It is not executable, or directly usable, by a digital system.
The speaker acknowledges the role of interpretation in taking natural language and representing it in “software languages” and the risk that interpretation of legislative rules may vary, stating that this is “inefficient and high risk”:
In order for it to be able to be used by a digital system, humans need to read, interpret, and re-write it into software languages. Further, this happens individually, independently, and repeatedly every time a person wants to reflect legislative rules in a digital system. It is inefficient and high risk. This is exactly what happened, and what went wrong, with the Holidays Act in New Zealand.
The proposed solution is to produce “legislation in 2 formats”, including a “machine executable software code version of that legislation”. The intent is that the code “version” is reliable such that it “accurately reflects the requirements of the Act”. This is said to be an intention of “Rules as Code”, by contrast with a better rules approach.
But, what if we could produce legislation in 2 formats from the outset? What if we could provide human readable legislation like we do right now, and a machine executable software code version of that legislation? That would have enabled those payroll companies to produce their payroll systems using the machine executable software code version of the Holidays Act, with the confidence that the software accurately reflects the requirements of that Act. That is exactly what Rules as Code aims to achieve.
From discussing Rules as Code, the speaker transitions to the terminology of a better rules approach, clearly stating that it is a “policy development methodology”, as we do.
Better Rules is effectively a policy development methodology. It was developed in New Zealand … We developed it because [we] tried converting legislation into software code using the 3rd option I just described, using a particular piece of technology. Frankly, it was a terrible experience and raised all manner of issues and difficulties. That led to the Better Rules discovery. It was established to answer the question, if the output we are seeking is machine consumable legislation, what inputs do we need to produce it? And what process would we use to produce it? Better Rules works by getting all the people who are developing the policy, and all the people who will write and implement the legislation, and the software code that will give effect to that legislation, in the same room together at an early stage of the policy development process, to help shape the policy. That enables the most effective implementation model and the end use of the policy in the real-world to be identified and used as a key input into the development of the policy from the outset. This enables an end-to-end, system-design approach for policy development. The knowledge, experience, and needs of the people who will be implementing the legislation and writing the software to give effect to it are built in from the beginning. I want to emphasise that this is only a part of the policy development process. All of these people don’t need to be involved throughout the policy development process.
If that paragraph is read in isolation we find little to disagree with. The speaker continues by noting the influence of other professions on the use of concept models, decision models and rule statements, which are used as a blueprint for drafting. Importantly, the blueprint sets out the policy, not the law.
Under the Better Rules approach, 3 document sets are produced. A concept model, a decision model, and rules statements. … The 3 sets of documents are effectively blueprints that are produced using logical, analysis techniques. These techniques aren’t new. They are already used in many different professions, and by numerous businesses. We are simply applying the techniques used by other professions, in a policy development context. These blueprints collectively set-out the policy. Just like the blueprints for a house, you can look at them, and then describe them in narrative form in any language. In our case, we can use them as drafting instructions for writing legislation, and for software developers to write code. The advantage of this is that we don’t have to first write legislation, and then translate it into a software format. That is where that translation gap creeps back in again. Instead, the legislation and software can be developed and produced in parallel, following the blueprints, with the legislation and the software shaping and assisting the development of the other, simultaneously. If something doesn’t work, then you go back and adjust the blueprints. And both the legislation and the software code are adjusted to reflect that change. This is an agile methodology, which we hear so much about. But applied to a policy and legislative drafting context.
The speaker suggests that, in some situations, there should be no potential for differing interpretations of the law, including when it is implemented in software code. At this point, the kinds of constitutional considerations we address in Part 3 become relevant. Further, the speaker clearly begins to anticipate that the software “version” of legislation will be directly implemented in high stakes situations such as piloting a motor vehicle, with the intent that code directly limits human conduct.
In some situations, there is no room for mis-translations, or differing translations of legislation in software. For example, there are likely to be multiple manufacturers of driverless vehicles in the future, each of which will have software that sets out what a vehicle does when driving itself on our roads. That software has to accurately reflect our land transport rules. It is critical that there is no translation gap between our land transport rules and the software in those vehicles, or between the software produced by the different manufacturers of those vehicles. The obvious need is to ensure that all vehicles do the same thing when they are on the road together. The best way to achieve this would be to provide an official, machine consumable version of the land transport rules so each manufacturer is using exactly the same software version of the rules in their vehicles.
It is not clear what legal status the software “version” of the legislation is intended to have, but it is clear that it will be directly relied upon for compliance reasons. Later, in relation to international trade rules (and not legislation), the speaker refers to the prospect that no natural language version of the rules is required, and only the software version of the rules should be operative. Despite that, it is anticipated that trade rules will be “implement[ed] … at all vertical levels within a country”, thereby apparently being used to influence behaviour within domestic jurisdictions.
An interesting use case for Rules as Code is international trade rules. Software code is a universal language, and is also the language that will be used in a real-world sense to implement the trade rules at all vertical levels within a country, as well as horizontally between trading countries. There are suggestions that it would be better to draft these rules directly as software, instead of a natural language. As long as everyone agrees that the software does what it needs to do, then countries can sign-up to an agreement that simply sets out the software, rather than natural language statements of what the rules are, and how they will be implemented – they can shift straight to implementation. The agreed text of the trade rules would be the software code itself – there is no need for a human-readable version of the rules.
The speaker proposes that a distinction can be drawn between answering legal questions, and giving effect to legislation but provides no further detail. There is no proposed limitation on how code that gives effect to legislation can be used.
Next, the purpose for producing machine consumable legislation is not to answer legal questions, per se. It is to provide software code that gives effect to legislation. People can then use that code for whatever purpose they choose; which may well include a digital system that answers legal questions. But it can also be used for all manner of other things. There is no limit or restriction on it.
Finally, in concluding remarks, the speaker proposes that people only really want legislative effect, and not legislation itself.
Many of you will have heard Professor Theodore Levitt’s observation, that “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.” That’s what this is all about—people don’t want legislation in and of itself. They want the results of the legislation. These days, achieving those results usually involves a computer—Rules as Code is about enabling that use.
We understand this to suggest that modelling the legal effect of legislation in code is an adequate substitution for legislation itself. The speaker is never clear on what the formal status of the software version of the legislation should have, but it is clear that the software version will be used in limitless ways to give effect to the legislation itself. In context, this must be understood as giving effect to an interpretation of the legislation, one which has been embedded in the software version by Executive government during the policy development process.
The speaker’s remarks have to be read in context, in an oral address aiming to sketch the dimensions of the developing Better Rules and Rules as Code approaches. It would be unfair to assess the remarks too closely, and it would be wrong to suggest that the speaker does not have a close and detailed understanding of legal and constitutional theory. That is why we have not named the speaker.
Our purpose in including these notes is to provide an illustrative example of the way that advocates for better rules approaches frequently transition away from advocating purely for the beneficial policy effects of taking a better rules approach and instead shift toward full advocacy for implementing a non-interpretable authoritative software version of legislation for direct implementation in computer systems, in some cases even suggesting natural language legal instruments can be avoided entirely. The stated intent of these initiatives is to influence human behaviour through software systems, even where those software systems control dangerous machinery (self-driving cars), and cover areas potentially attracting criminal penalties, or leading to significant damage to people and property.
Early on in the Better Rules Programme, a discussion forum was convened on a platform called Loomio. The platform hosted extensive discussion. After some time, the Loomio forum was deactivated, but a PDF export of the forum was collated, which is available online and provides useful insights into how discussion of the topic has developed.
The PDF version of the discussion forum removed the names of the people posting. We include some points of note here, and recommend keyword searching the document for the word “interpret” (found on 26 pages), “legislation as code” (found on 30 pages), and “rules as code” (found on 32 pages) to gain some idea of how the topics we discuss in this report were treated by commenters.
On 21 September 2018, a poster stated:
[Commenter’s company] has spent the last 17 years codifying other people’s rules, including legislation, that are defined in legalese or some variation of logical English. I can assure you that no matter how experienced or careful the authors, matter how many peer reviews, no matter what checks and balances, using natural language to define rules always fails to define rules that have only one possible interpretation. That is why we have Courts. The problem is the idiom – what do the words mean in this exact context? And all of that is before you factor in discretionary input, which is endemic in legislation. You can refute the above – no problem. But if its correct, then the issue is that the algorithm must actually be the legislation, not a representation of it. The algorithm in this context is the first order predicate logic, the algebra, and the rules (constraints) that convert the re world data into the useful outcomes that the legislators require. If true, it follows that natural language description of the legislation must be derived from the algorithm, not the other way around. How long before legislators start passing laws that are defined by algorithms and proven with the myriad of test cases that any normal system would require?
In reply, a user said:
I disagree, though maybe only slightly. I don’t think it’s necessary that either the natural langue or encoded versions of the law be primary, and the other secondary. Both can be primary, like in Canada where we have legislation that is written in both English and French, and both languages are authoritative. …
On 24 October 2019, a user replied to a question about the distinction between existing policy automation engines or business rule systems. The reply is instructive for the way that user regards the role of interpretation:
… business systems that use rules are not the right place to provide authoritative management, provision and access to rules, as those applied usage of the rules create too easily a pressure to encode the rules bespoke to purpose. OPA/RaaP are tools largely for the applied use of rules where they are already provided in a human readable form and need translation into a machine form, but you get variance of interpretation this way, whether it is a machine translating it (OPA, RaaP, etc) or a human interpreting it. If you had just the rules available as machine consumable code, consumable by business systems that then apply the rules according to the specific context, then the translation gap is avoided, the rules are applied consistently across very different use cases, and everyone is using the same version of those rules.
On 24 October 2019, a user wrote:
… we can use coded rules to build automated or semi-automated systems that deliver a result, an explanation of the rules applied to get to the result, and all inputs and evidence considered. It’s essential that decisions be transparent and explainable, especially for governments, whether those decisions are made by a person or a machine. Rules as Code would eliminate needless duplication. Secondly, it would be far more efficient. Currently, we have numerous businesses each coding their own version of the same laws. This creates the risk that translations will be incorrect or misinterpreted. In contrast, a single government-provided and assured translation, made available via Application Programming Interfaces (‘APIs’, which make it possible for machines to speak with one another and transact) would cut down on this needless duplication. Regulators would be able to see the rules being consumed, and the community would have certainty that the rules being used by automated systems were the correct interpretation (or even certiTed to be correct). A single set of government-assured coded rules would also be a boon to the private sector. They wouldn’t have to devote resources into translating the rules into a form their systems could use — saving money, increasing productivity and proTts and, therefore, increasing the tax base.
The user continued:
As our Kiwi colleagues are currently ably demonstrating, effective test driven regulation and legislation means firstly assembling a multidisciplinary group of policy, drafting and rules consumers (service designers and developers) to understand and agree the purpose, concept and logic behind a piece of legislation with an accompanying coded ruleset. By collocating with drafters and coders, this group can then simultaneously co-draft human and machine readable versions of the rules for testing — with humans and machines. This allows for more holistic modelling of impacts, and provides and the opportunity to test the coded rules with end users (regulated entities, service providers, etc.) before publication. Ideally, if dealing with a legislation ruleset, the draft legislation would be published for consultation together with an API enabling access to the draft coded rules, and stakeholders could test the rules and use the code to inform their submissions. Once enacted by Parliament, the machine readable form (the API) could be publicly available immediately. Regulated entities could link their systems to the ruleset instantly, reducing the time and cost to implement and reducing the risk of mistranslation or variability in interpretations. We still need human-readable rules Of course, this doesn’t mean that we should only write legislation or policy rules in code. Humans still need to be able to read and interpret rules. Further, machines can’t do nuance or interpretation. They only deal with absolutes. The rules we can currently code effectively are prescriptive — black or white, yes or no. Many of our laws are not prescriptive, but require subjective perspectives and nuance, consideration of the various circumstances of the case. That is, we need humans — administrators, regulators, lawyers, judges — to interpret and apply them. Even in those scenarios, coded rules can help — by automating the black and white aspects of the question, we can escalate the parts that require nuance for human consideration. This will allow us to dedicate our human resources to the difficult and complex work, leaving the process-driven drudgery to our robot friends.
Another user on the same date replies:
It’s definitely been our experience that when you build code/products off previously drafted legislation, it really limits how customer-friendly you can make it. So if we can do service delivery at the same time as policy/legislation development, and make the service the law rather than an interpretation and simplification of the law, that will be transformational.
On 25 October 2019, a user wrote the following paragraph as part of a wider reply:
Here’s my point. “Rules as Code,” as I understand it, is the idea that the legal logic, and only the legal logic, can be made machine usable, and more reliable than the interpretations we have now because we choose to write the natural language laws in the same semantics the encoded version uses, or a very similar one. So we know the two representations mean the same thing, and the interpretation only needs to be done once. THEN you build applications with it.
In reply, the original poster said, as one paragraph of a wider reply:
People quickly get into what the tool should then be for the rules, and I would suggest we don’t need to solve that problem immediately, but we do need to ensure this model of rules provided by gov and consumed by others is maintained, because the alternative is where we are now, which is myriad and variable interpretations of the rules applied in myriad (and often non compliant) ways, often with no traceability or explainability of authority for the decisions or actions taken on the back of the applied rules.
On 26 November 2018 a user wrote, in relation to the question of what is meant by “authoritative” rules as code:
- authoritative v government-endorsed. The distinction is about the way that in Commonwealth countries (and in USA primary legislation), the government may drive the process but the Parliament does the enacting and the court interprets what the Parliament enacted, not what the government thought it was getting the Parliament to enact. So the government’s view of what a piece of legislation actually means is just one view, with no more legal force than anyone else’s, even if the government sponsored the legislation. By authoritative I mean forming part of the enactment itself, as passed by the Parliament and then independently interpreted by the court (so it does have legal weight) - whereas by government-endorsed I mean something that could be wrong. A schedule is part of the legislation, on an equal footing with the main text, and that is why you need to know the status of the “executable item” in the schedule. It is a principle of drafting that you don’t say the same thing twice unless there is a good reason, and that if you do then you make clear what the relative status is of the 2 versions. You cannot be certain no errors will creep in, so you cannot assume the code part will perfectly match the natural language part. So I think you mean the code is subordinate to the natural language - if there is a discrepancy the natural language version is the law and the code is just a faulty explanation.
In theory it could be set up the other way around - the legislature could say the natural language is subordinate to the code. Then if there is a discrepancy the code is the law and should be followed, with the natural language being treated as just a faulty explanation (in the way that Explanatory Notes currently are). But as you say, it is unrealistic to expect the legislature to be able to understand code (or perhaps we should just say it is much more unrealistic than expecting them to understand legislative “natural” language).
Equally in theory the natural language and the code could be given equal status - as is often done with legislation enacted in 2 natural languages (as in Canada or Wales) or in one brave case (EU) 23 languages - but again there are drawbacks (especially if there is complete uncertainty as to which of 2 a court will follow). Coming back to the coding being subordinate - in Commonwealth drafting traditionally we would not put merely explanatory material in an enacted piece of legislation at all, not even in a Schedule. It would go in a separate document, like an Explanatory Note, that has no legal status and is not voted on by the Parliament (but can in some circumstances be used by a court as one source of help to resolve ambiguity in the enacted natural language, along with statements in Parliament by the enactment’s sponsor and so on). I was just trying to see whether anyone is looking at making the code part of the enactment, as then the legislative drafter is more directly involved, or whether it is running in parallel through the policy development, into the instructions given to the drafter, then as a supplement to the explanations given to the Parliament, and then out the other end as a supplement to the legislation as enacted.
I will post a reply in a minute, but what I think he is talking about is a model in which the code is subordinate to the legislation and is separate from it.
In reply, a user states on 28 November 2018:
Traditionally, we have drafted legislation and then published it so as to make it available for the world to interface with as they wish. In the past, the main users were lawyers and the courts, who are trained to interpret legislation.
Now, with advances in technology, the rules in legislation are integrated into tools - primarily computers - to assist people to do all sorts of things. This may simply be a website that sets out information, or may be a company’s business rules which it uses to ensure regulatory compliance, or by a government department to work out people’s eligibility for a benefit, or enforcement officers to determine whether people have complied with the rules, and so on. The uses are endless.
The one thing that all of the above have in common, however, is that they operate using software. So, the question is, what is the best way of replicating legislative rules in software? How do we do this easily, and ensure there are not gaps between the legislation and the software?
It seems to me that fundamentally there are 4 options (some of which have variations, but let’s keep it simple): … 4. take the Better Rules approach in which we take a different approach to the development of policy and legislation. The primary outputs of the Better Rules approach are concept, decision and flow diagrams. These are in effect a common language that are then used as the instructions used by legislative drafters, business rules folk, and software developers, all of whom can then draft their particular outputs using their current, usual tools and processes. The outputs all need to be checked and validated against each other, but as all parties have contributed to the development and creation of the concept, decision, and flow diagrams, everyone should be speaking the same language - conceptually and literally - from the outset. For a whole bunch of reasons (which I am happy to expand on in another post), I believe that option 4 is the most viable, the best, and the most forward-looking approach. At least for the foreseeable future.
The OECD has published a primer on Rules as Code.146 The OECD primer does not purport to offer an authoritative definition of Rules as Code:
… Being a new concept, debate continues over the concept’s precise definition and scope. Accordingly, while the following section does not seek to provide a conclusive definition of RaC, it does suggest a definition that best captures the focus of this primer and RaC in the public sector context. This is intended as a working definition.
The primer also notes that actual application of the techniques will better illustrate some of the ambiguities in the concept. It notes that law-as-code applications as well as automated compliance have “featured in the conversation”.
Like many innovative approaches, it draws and builds upon considerable thought from a diverse and wide range of thinkers and practitioners. As a result, many terms have been used in connection with the RaC concept. Computational law, digital legislation, digital regulatory reporting, automated compliance and model driven regulation have all featured in the conversation. … It should be noted that there is a long history of related efforts in the concept’s broader domain, with a commensurately large amount of research and insights (see Other preceding and related efforts). At the same time, how RaC is conceptualised is changing rapidly as teams and individuals experiment with, and test, various approaches. Consequently, the following discussion should be regarded as trying to set some parameters without prescriptively defining every component, something that will only come as the concept is more widely explored and adopted in a public sector context.
It is clear that the interpretation of rules is anticipated as an aspect of the topic being discussed:
RaC envisions a fundamental transformation of the rulemaking process itself and of the application, interpretation, review and revision of the rules it generates.
The OECD primer adopts a useful distinction between Rules as Code as an output, and Rules as Code as a process, however subsequently, it blurs these distinctions by analysing the benefits of rules as code as a process primarily in terms of the ability to implement rules as code as an output.
This definition of RaC, i.e. as an output, can encompass, for example, business rules written in software code, such as those that firms use to comply with regulation governing their commercial activities. Indeed, many software companies already exist to take rules written in natural language and convert them into code for use as operational business rules by specific entities. … Understood in this way, RaC as an output is not completely new and has been subject to significant and extensive examination, something that will be explored later in the primer.
Rules as code as an output is contrasted with rules as code as a process:
There is a second and additional component of RaC, however, which is where the focus of this primer lies. This dimension has been opened up by the work of several public sector teams, often with private sector or academic involvement. Pioneered by the New Zealand Government, especially through the Better Rules work (see Box 2.4), RaC is increasingly seen as representing a strategic and deliberate approach to rulemaking, as well as an output. Taking de Sousa’s definition from the Rules as Code Handbook (2019a), RaC can therefore be understood as: ‘the process of drafting rules in legislation, regulation, and policy in machine-consumable languages (code) so they can be read and used by computers.’ RaC, conceptualised in this way, is about changing when, how, by and for whom rules are made. It moves beyond enhancing existing workflows and processes, and requires deeper and deliberate examination of the rulemaking process.
One of the benefits of rules as code is said to be that publishing rules as code will mean that end users are not required to form their own interpretation of the law prior to encoding it in machine languages.
Currently, rules are made available in human-readable form; that is, they are presented in natural language in the form of legislation, regulation or policy documents. End-users of rules, such as regulated entities or government agencies, take these rules and interpret them into ‘machine- consumable’ versions (see Box 2.2). That is, they take rules written in natural language and translate and reformulate them into code that can be used by the machines (i.e. computers) in a way that is relevant for their specific context and allows them to be enacted at scale (e.g. across the welfare system or ensuring compliance with taxation requirements). By contrast, RaC proposes that governments create an official and machine-consumable version of coded rules from the outset, which compliments and mirrors the natural language version, and which can be published and consumed by interested third parties.
The OECD primer proceeds on the basis that “rules” and “rule-making” can act as umbrella terms for describing all forms of law and rarely fails to stop and consider the way that different kinds of “rules” (better understood as laws or regulation) require to be treated differently. The following is an example of the way that all legislation, a very specific kind of rule with constitutional significance, is reduced to “rule-making” (p 26):
For the OECD (2019b: 211), public sector ‘governance’ refers to the ‘exercise of political, economic and administrative authority’. This authority gives governments the power and ability to create and enforce rules. In turn, these rules, which are manifested in various forms including laws and regulations, shape the societies over which governments have jurisdiction. These rules not only govern the actions of people, businesses and societies, but also how governments themselves operate. This is a central and long- established aspect of democratic systems and is most explicitly linked to Magna Carta (1215). This document, issued by King John of England, placed constraints upon the governing executive and thus ‘established for the first time the principle that everybody, including the king, was subject to the law’ (Breay and Harrison, 2014). Crucially, the example of Magna Carta underlines that governments are not only creators of, but also subject to, rules. These rules are perhaps the most fundamental, in that they place limits on government and its ability to act, and help to reduce the risk that citizens will be subject to the arbitrary exercise of the coercive power of the state.
The nature of rules and laws has evolved over time, becoming more refined as legal systems have become more sophisticated. Moreover, at an ever-increasing pace, digital technologies are requiring widespread changes to the rules themselves (for example, the modification of aviation law to account for the use of drones). Governments have also been long engaged in deep, extensive examinations of what and how many rules to make. In the wake of crises, this trend typically becomes pronounced. Following the Global Financial Crisis of 2007-08, for example, many governments assessed to what extent the regulatory frameworks and compliance measures governing the financial sector were sufficient. Many countries have also made changes to the ways they make certain rules, for instance, through the introduction of regulatory impact statements into the law-making process. Yet, despite all these changes, the basic, most foundational methods by which governments design, create and implement rules have remained largely immune to comprehensive transformation.
In the next paragraph, there is some recognition of the way that these “rules” can include taboos and customs which are unwritten, but this obscures important differences between particular rules: (p 26)
Rules are part of a constellation of components that shape and govern society. For North (1991: 97), institutions are ‘the humanly devised constraints that structure political, economic and social interaction’. They constitute ‘informal constraints (sanctions, taboos, customs, traditions, and code of conduct) and formal rules (constitutions, laws, property rights)’ (North, 1991: 97). In this way, rules can be both specific things but also embodied in structures and processes. A democratic government functions on the basis of rules – i.e. the non-arbitrary use of the state’s coercive power. Formal rules particularly, such as those contained in constitutions, enable the state to govern for or on behalf of its people.
Later, it becomes clear that “rules” in the primer should be interpreted as “law” or even “regulation” or “norms” in the broadest possible sense (pp 27-28):
Governments are simultaneously administrators of, and subject to, rules. Once in force, government rules, for example those contained in legislation, need to be interpreted and implemented by non-elected members of the government, such as public servants. In such cases, governments may adopt operational guidelines that public servants must follow. An example would be operational guidelines for the application of eligibility criteria to determine if individuals can access state-funded grants or loans. Public sector leaders can also be required to comply with internal budgeting rules, created by government, for the purpose of administering and managing agencies. Rules can therefore be legal obligations or formalised accepted or expected practices.
As the ultimate form of rules in a nation, a constitution establishes the obligations, freedoms and powers of a government. One of these powers is the ability to create, modify and enforce rules. Typically, the rules created by governments are thought of as residing primarily in legislation. Indeed, while legislation often houses a significant portion of the rules created by government, many are also contained in regulation, policy documents and operating guidelines. While these and other instruments seek to set out precise and unambiguous rules, their implementation will often require interpretation or the exercise of discretion as to how a rule should be implemented in specific circumstances. In this regard, the application of rules by individual public servants can be affected by the depth of their knowledge and expertise, among other things. It can be further influenced by the degree to which the rules are established and enforced and the extent to which parameters and guidance are detailed and meaningful.
While not the focus of this primer, the judiciary and courts are another key actor in the creation, interpretation and enforcement of rules. Their role differs across countries depending on a range of factors, including the type of legal system in place (across OECD countries, civil law, common law and mixed systems predominate (see Box 3.1)). The judiciary and courts’ role may be relevant when considering RaC for a number of reasons and the differences between them can matter because of their impacts on the nature, effect and operation of rules made by governments. The level of detail in various forms of government rules might vary from country to country, as may the extent to which the courts shape the rules after their adoption. Even in cases where the role of the courts in this regard is more limited or where government rules do not require the exercise of discretion (for example, in some instances of sentencing), courts will still play a crucial role in interpreting how and to which cases the rules apply, thereby shaping how government rules are implemented in practice. It is therefore important to consider the role of courts when determining how and where RaC could be most effective. In this, rule makers should also consider the types of rules to which RaC is best suited (see What rules should be coded?).
Later, the role of interpretation in relation to “rules” (which can be understood as including legislation and case law, as well as every other form of rule embraced in the earlier definition) is identified as one of “three related problems” which rules as code approaches can help to, presumably, solve. Notably, translation here is used both in relation to internal policy development processes (in the way understood in our discussion of a better rules approach), but also in “implementation”, meaning enforcement outside of a policy development process: (p 31)
Interpretation and translation of intent: In requiring repeated interpretation multiple times and in multiple stages throughout rule creation and implementation, the current process risks misunderstanding. This can create a gap between policy intent and implementation, as well as uncertainty and costs for consumers of the rules. This is magnified when happening at speed, as the ability to compare a rule’s intent with feedback about its in-practice implementation and its application to unanticipated contexts is hampered by ongoing, often irregular change.
Finally, on p 32, the circle is closed completely between “policy intent”, ie original executive intention, through to implementation and enforcement, again, by framing the crucial constitutional role of interpreting natural language as a problem to be solved through “rules”, including “legislation”, “as code”: (p 32)
Interpretation and translation of intent: The current way of creating, distributing and consuming rules carries an inherent risk of discord between the original policy intent and the eventual effects of the policy. In the model outlined above, each stage of the policy-to-implementation process can occur almost independently from the others, with distinct groups of actors responsible for specific aspects. Policy professionals and subject matter experts, along with elected politicians, may cooperate to create an initial policy document. This is then communicated to legislative drafters, for example, via drafting instructions, who transform the policy into the form required by the parliament. If there are implications for people, the policy will also be passed to agencies responsible for implementation, who create operational guides and business rules.
Even in this simplified example, there are multiple opportunities for the misinterpretation of the original policy intent. … The disintegrated nature of the process can thus result in misunderstanding and gaps between policy intent and implementation. This is suboptimal for the creators of policy, as well as for those who are subject to the policy’s effects.
The current process also necessitates translation and makes certain actors crucial in the processes of rule-creation, implementation and use. As NZ’s Better Rules team noted, once a law is enacted, the current model positions ‘lawyers as modems’ who, along with other types of advisors and analysts, are necessary to interpret and translate the law into operational policies and business rules (Andrews in OPSI, 2019: 106). Subsequently, these outputs are again expressed by others, including technologists, in a variety of information systems. This requires translation that, in turn, requires human judgment and therefore has the potential to skew the original intent of the rule through misunderstanding and errors. Such (mis)interpretations are often not explicit and may be operationalised, for example, by coding workflows, decision models and calculations into software.”
Subsequently, one of the main benefits of “rules” (including legislation) as code is the removal of interpretation, exclusion of the requirement for lawyers and legal advice on what the law is, removal of variability in the way law is interpreted, operationalising those coded non-interpretable rule sets at all levels of government (and internationally): (p 39)
Better policy outcomes and enhanced service delivery: By reducing the need for interpretation and translation of rules between their human-readable and machine-consumable forms, and by making these interpretations more visible and explicit, RaC could minimise the gap between policy intent and implementation. This could deliver better policy outcomes and enhance service delivery.
Disintermediation and agile government: RaC extends the trend towards disintermediation enabled by digital technologies into the domain of the law and, by extension, public administration. By making rules more accessible and comprehensible (for both humans and machines), users of rules will have less need to rely on (costly) experts (such as lawyers) to understand their rights and responsibilities
Improved consistency and fairness: An official set of machine-consumable rules, made available to be consumed by third parties, is likely to increase the consistency of their application. This could improve fairness and confidence in the rules.
Interoperability and efficiency: Creating a set of shared and consumable rules could drive greater interoperability between all levels of government (and potentially even between nations). Additionally, the reduced need for manual translation of rules by individual actors, manual updating of rules and time between policy development and service delivery could deliver efficiency gains for governments and third parties alike.
The role of lawyers and interpretation is clarified subsequently, but it still proposes that the increased use of non-interpretable laws is desirable: (p 42)
By reducing the need for lawyers, policy experts, software developers or government officials to interpret and translate laws, RaC could also enhance the ability of people, businesses and delivery partners to understand and navigate relevant government rules. Of course, RaC does not presume that the elimination of experts and intermediaries (such as lawyers) is possible, nor even preferable. Rather, it suggests a different role, where their expertise is redirected to those instances of the highest value. beta.gouv.fr observed that instead of eliminating the role of mediators, the availability of RaC tools to solve basic problems opens up more time for experts to solve more complex edge cases (Quiroga and Denoix, 2020). RaC could enable the largest possible number of individuals to understand (or at least be able to act upon) their rights and obligations, while freeing up resources (government or otherwise) to direct attention to more complex cases.
Further, the complete removal of interpretation comes to represent one of the most significant benefits of rules as code because “the best policy is not a good policy at all if it fails to realise its stated objectives in practice” (p 39), which takes for granted that the policy in question is lawful and democratically supportable. The goal is to implement executive intent through “rules” (including law and legislation) as code as rapidly as possible with as little interpretation or institutional separation between intent and implementation. (p 39 and 40)
The gap between identification of rapidly emerging issues and an appropriate set of responses must be reduced. A vital component of this will be ensuring that actions taken – the policy implementation – accurately meet government objectives and citizen needs. This depends upon reducing the interpretation and translation gap that can emerge between policy intent and outcomes. By reducing the number of opportunities for misinterpretation between the designers and implementers of policy, RaC can deliver policy outcomes more true to their original intent. This should mean better outcomes for people, businesses and governments themselves. An ability to ‘push’ updates to machine- consumable rules delivered via API is just one example of how RaC could help achieve this. By minimising the opportunity for misinterpretation, it will not only be easier to see if the rules are having the desired effect, but also if or where any implementation issues with those rules may lie.
When law is expressed as code, conversely, the authors claim it will be more contestable and accessible than natural language legal instruments are now. Instead of “code” being presented as the unknowable black box, a term traditionally used in relation unexplainable neural networks or incomprehensibly complex machine learning algorithms, natural language legal instruments and regulation are framed as being the inscrutable black box. The authors adopt the view that rules as code outputs are superior because they will allow people to know exactly what their obligations are, but there is no recognition of the way that people may wish to contest the precise boundaries of these obligations, or the legal justification of a government’s authority to impose them (whether in a digital self-executing system, or at all).
The Primer goes on to explain how there could be greater citizen input into drafting of rules as code, but only use examples of machine-readable natural language rules, not machine consumable code-as-law, thereby obscuring the crucial difference between law that is interpretable and contestable, and law that is incapable of interpretation and self-executing.
Greater transparency: RaC has the potential to drive greater transparency in terms of the laws, rules and regulations of government. By making rules available in a way that is open, accessible and contestable, rather than in a ‘black box’, RaC may serve to enhance the transparency associated with the development and use of government rules. The provision of official, machine-consumable rules may also better facilitate the development of new or improved tools and services that assist individuals to understand their entitlements and obligations in relation to government rules. Some reforms are always likely to be resisted (even while others are welcomed or demanded). Ensuring rules are more visible could also encourage more objective public debate and help reform efforts attain a greater degree of legitimacy when implemented.
To be fair, there is occasional recognition of the way that legislation has a superior role, over, for example, operational requirements, but these recognitions do not sit comfortably with other comments as previously quoted above. (p 43)
…the simultaneous design and creation of legislation and the rules could significantly decrease the time required for service implementation and delivery. By designing the rules concurrently, both parties can be sure that they meet operational requirements. To note, this does not mean that the intent or legislation should become subservient to operational requirements, which would place undemocratic and unsatisfactory restraints on the policy and/or legislative process. Instead, it is about creating the opportunity for upfront and shared dialogue that enables the policy to be implemented rapidly and in the way most true to its original intent. Determining the extent to which efficiency gains can be realised from this process at scale could be a focus of future research.
It is clear that one benefit from rules as code outputs is the direct provision of “interpretation” as a coded rule-set. After discussing business rule systems, fintech and regtech, the authors discuss the way that coded rule sets are implemented in software systems. (p 59)
Some companies are also working on solutions that ensure, for example, ‘Compliance by design’ at the code level. Compliance by design seeks to embed legal, regulatory, ethical principles directly into entities’ software. Nonetheless, it should be noted that this remains possible only through the repeated act of interpretation and translation from the natural language version of government rules. As Andrews (2020a: 15) identifies ‘most products in this space were interpretation engines that assume legislation is drafted only in human form’. A key problem with this is that the independent creation of distinct rule sets risks ‘creating new translation mistakes, or of perpetuating existing mistakes if elements are copied’ (Waddington, 2019: 24). Many of these solutions, then, do not appear to overcome the issues associated with the absence of a single provider of official, machine-consumable rules.
It continues by clearly anticipating that governments would be responsible for creating “interpretation as code” that is applied as law: (p 59)
Overall, while such approaches may go some way to addressing the issue of replication of rule sets, there are legitimate questions as to how they might work when viewed from a whole-of-system level, where having numerous, presumably different, approaches may add to, rather than reduce, complexity. As conceived of here, RaC suggests that the actor best placed to provide a single and official source of rules is the government. This represents more than the development of a new technical approach or technocratic ‘fix’ to an existing problem. It represents a potentially paradigmatic shift in the way the governments design, implement and provide rules.
The role of interpretation is covered by reference to comment by McIntyre,147 although the role of the judiciary and the concept of statutory interpretation does not feature strongly.
This concern should not be ignored. Protecting the correct function of the law and the role of the judiciary as a vital pillar of the democratic system of government is of crucial importance. What it also exposes, however, is the need to clearly define the RaC concept and when it should be used: both goals of this primer. To reiterate, RaC (as understood here) does not aim to replace judges or legislators. Instead, its goal is to augment the rule-development process through the government’s creation of a machine-consumable ruleset that mirrors its existing, human-readable counterpart. In this sense, RaC would be an improvement of a process that already exists, but with the potential for greater transparency and openness.
This currently happens, but it is not done well. Every business rule system designed and employed by businesses or government agencies has interpreted and coded aspects of the law. RaC proposes to rethink this process and, in so doing, make these renderings more consistent, transparent and consumable by all people. Not only that, early efforts seem to suggest that in the development of legislation which supports service delivery, the experience of creating machine-consumable rules actually brings greater rigour to the drafting of the laws themselves. In other words, the rules created are better able to fulfil their intended function. In this sense, while RaC does aim for ‘legislation [that] could be directly applied by machines’, it more precisely seeks a better application of the law by machines. By assigning the responsibility for machine-consumable rule sets to government, the function and effectiveness of the laws created may therefore be enhanced, rather than eroded.
The OECD primer notes that errors in interpretation incorporated into a coded model will exist. It also acknowledges that some jurisdictions may treat the code as having “the force of law”:
Of course, errors will inevitably arise in the coding of rules. Accordingly, there also must be mechanisms that allow the coded version to be corrected or appealed. Further, to the extent that a jurisdiction chooses to treat the coded version as having the force of law, the importance of mechanisms that allow the subject of the decision to seek a review (undertaken by a human actor) will rise. Options and mechanisms for people to contribute a correction of a faulty rule may also be beneficial. For example, this may be because an error has been made in the interpretation of a rule and its subsequent application. In instances where coded rules are used to support straight through processing or automated decision making, this may also be a legal requirement. For example, the GDPR only allows for fully automated decision making without human involvement in limited circumstances. Ensuring that a RaC approach is appropriate and that there are avenues for appeal should enhance trust in machine-consumable rules and reduce concern over potential misuse.
At other points, there are indications that the pervasiveness of interpretation is not fully considered. Focusing on prescriptive rules does not remove the need for interpretation, it only increases the chance that the interpretation is reliable on the text’s plain and ordinary meaning:
Requiring little discretion, prescriptive rules leave little ambiguity about the course of action that must be taken. The prescriptive criterion naturally lends itself to certain types of rules, such as those relating to eligibility and calculation. Such rules are also conducive to the development of IF-THEN statements. While some initiatives are now challenging the encoding of only (or mostly) prescriptive rules, most RaC experimentation to date has focused on this type. Focusing on prescriptive rules may also help reduce concerns about automated decision making, that is, by avoiding the codification of rules that substantively require subjective (and therefore human) interpretation.
The suggestion that it is possible to “[avoid] the codification of rules that substantively require subjective (and therefore human) interpretation” anticipates that there are rules where no interpretation is required. We do not agree that any such rules in natural language exist.
It also mistakes interpretation as being subjective, rather than being a highly tailored, constrained and specialised exercise performed by lawyers and the judiciary according to principles and practices that lend greater predictability and certainty to interpretation than the word “subjective” fairly captures.
In a summary table on p 69, “potential considerations for Rules as Code” are identified:
Legal implications: Creating an official set of machine-consumable government rules raises a number of legal questions that must be carefully considered by governments.
The authors do acknowledge: (p 94)
Appropriateness and Appealability – Appropriateness requires that consideration be given to the question of if a RaC approach is suitable for a given area or problem. This will include determining if generating machine-consumable rules will create value, as well as if available technology solutions possess the required capability. Of course, errors will inevitably arise in the coding of rules. Accordingly, there also must be mechanisms that allow the coded version to be corrected or appealed. Further, to the extent that a jurisdiction chooses to treat the coded version as having the force of law, the importance of mechanisms that allow the subject of the decision to seek a review (undertaken by a human actor) will rise. Options and mechanisms for people to contribute a correction of a faulty rule may also be beneficial. For example, this may be because an error has been made in the interpretation of a rule and its subsequent application. In instances where coded rules are used to support straight through processing or automated decision making, this may also be a legal requirement. For example, the GDPR only allows for fully automated decision making without human involvement in limited circumstances. Ensuring that a RaC approach is appropriate and that there are avenues for appeal should enhance trust in machine- consumable rules and reduce concern over potential misuse.
The orientation of the report toward Executive government actors is exemplified by the inclusion of a checklist toward the end of the report that relates to the needs of policymakers and regulators, “those involved in the legislative process”, service design and delivery experts, and technologists, but not lawyers or citizens. Further, the actual checklist created only anticipates the inclusion of these four groups (pp 95-98).
The authors acknowledge that many legal or jurisprudential questions raised by RAC are outside the scope of their report. They identify the following questions as requiring investigation and resolution:
If compliance by third parties is undertaken on the basis of the coded regulations delivered by government, but a mistake has been made in their drafting, is the government liable?
How would the treatment of mistakes made in machine-readable legislation differ from mistakes made in human-consumable form?
Is it appropriate to use coded rules to make decisions about all topics?
Is the misuse of rules coded by government possible and, if so, what could be done to guard against it?
Toward the conclusion of the report, the authors include the following anecdote:
In the course of the research for this primer, an individual with experience in the legislative process described an almost unthinkable situation. He painted a picture of a Minister seeking to develop amendments to a complex law (relating to digital topics), who was hidden behind mountains of paper scattered across a gigantic table. With her, a group of advisors stood discussing the merits of the proposed changes and desperately trying to work out their potential implications for other national and international pieces of legislation. To achieve this, they were physically searching for relevant clauses across documents, that is, across literally hundreds of pieces of paper. Her question: ‘How can we possibly still be doing it like this?’ When we have the technologies available to improve the effectiveness of the rulemaking process and the rules themselves, remaining wedded to incumbent ways of working seems wasteful or even irresponsible.
The answer to this scenario is not for that Minister to create coded interpretations of legislation, which may be incorrect, simply making the task more difficult. If the policy area cannot be understood, that would suggest it also should not be being amended without careful scrutiny. It is not at all clear how requiring that Minister or those advisors to conduct the same exercise in (potentially legally incorrect) machine-executable languages would be any improvement: this is because it substitutes language that is accessible to those groups with language which is not; but further, not just one language but a practically limitless array of machine-executable languages. The answer is to do what has already been done, which is to use keyword searching and other forms of sophisticated indexing through extensible markup languages to identify “the right piece of paper” using digital computers.
Other notable statements include:
In a diagram explaining “the chain of reasoning behind Rules as Code”, the following quotes are notable.148
The authors articulate six “fundamental principles, or core notions”. Within those six principles, we point to the following statements:
See for example Bench-Capon and Coenen (1992). ↩︎
Brenda Wallace “”When software and law are the same thing” 4 August 2019 (PyCon AU 2019) <https://www.youtube.com/watch?v=_IUOgen7VjI&feature=youtu.be>. ↩︎
J. Mohun and A. Roberts, “Cracking the code: Rulemaking for humans and machines,” OECD Working Papers on Public Governance, No. 42, Paris: OECD Publishing (2020) ↩︎
Cracking the code, Mohun & Roberts, at p 24, 80. ↩︎
Pim Willemstein and Ronald G. Ross, “The Distilled Principles of Rules as Code (RaC): How to Produce Better Rules” Business Rules Journal Vol. 22, No. 2, (Feb. 2021): <https://www.brcommunity.com/articles.php?id=c059>. ↩︎