About ›

What is Rules as Code?

What are the sorts of things people mean when they call their approach Rules as Code?

Rules as Code (RaC) is essentially about coding legislation. But that is not the whole story. A longer answer is given by an RaC Wiki, saying RaC is about “drafting and publishing rules in legislation, regulation, and policy in both human and machine-consumable languages (code) so they can be read and used by computers”, “ideally” through “simultaneous co-drafting of the human-readable and machine-readable versions of the ruleset, to enable the alignment of the intent of policy drafters and the logical constraints of coding” so that the “two versions can then be published together”.

What complicates any answer is that RaC is a movement or general idea rather than a specific tool, and the term is used by different people to cover a broad range of approaches which sometimes are not compatible with each other. Some people use RaC to mean almost any effort to digitise the rules in any legislation (or even any government policy or regulator’s guidance). But that dilutes it to the point where it is the same as “computational law” (see below), or even where it covers the computer programs that all tax and social security departments have already been using for decades to run their calculations.

  • As legislative drafters, we are naturally drawn to the idea that what makes RaC different is doing the coding at the same time as the drafting, before the legislation is enacted. But we wouldn’t want to insist on reserving the label RaC for that.
  • A major player in RaC initiatives in the Australian government (and worldwide through the “RaC Guild”) is Salsa Digital. They give explanations of what RaC is and how to turn legislation into RaC, but those do not mention using it on draft legislation.

One way to make sense of this, when looking at an approach described as RaC, is to try to find what makes that approach different from existing coding or wider computational law. There is not just a single magic test for that difference. But there are some common themes shared by most people who use the term, each of which forms a spectrum along which different people position their different takes on what they mean by RaC.

  • Computer-readable/consumable/executable - Perhaps the most commonly agreed aspect is that the point of the coding or mark-up is seen as being so that in some way a computer can “read”, “consume” or even “execute”, some or most aspects of the legislation. The spectrum for this runs from the computer just reading the if-then structures to guide a human reader who wants to understand the text, to the computer program producing compliance with the legislation directly, as in a social security program making an electronic bank transfer to pay a person’s benefits or a self-driving car having a speed-limiter that enforces relevant speed limits. At that end of the spectrum it is related to the EU idea of “digital-ready policymaking”, which itself covers a spectrum from avoiding problems with policy and legislation that are already intended to be automatedly executed, to suggesting that all policy and legislation should as far as possible be designed to be automatedly executed.
  • Prescriptive/discretionary provisions - Many accounts of RaC (but not ours) suggest that the RaC approach is best suited to what they call “prescriptive” legislation, and that it does not work with “discretionary” or “evaluative” provisions. That is often accompanied by a view that standards-based legislation is a bad thing (where the legislation prescribes the outcomes to be achieved, rather than the means that the legislator thinks are best to achieve them) because it blocks automation. But this view is tied to the point above, in that it goes with an assumption that RaC is only worthwhile if it leads to legislation becoming automatically executable without needing to call on any human decision-maker or interpreter. If instead RaC is used to help a human reader of the legislation to understand it and to work out how it applies to their situation, then a provision giving discretion (or calling for human evaluation) is just another input point like any other and the coding maps what is the next input point depending on the input given at this one (“if the jury accept the force you used was reasonable, they will acquit you, otherwise they will convict you”). The most obvious cases of discretion are where the legislation says something like “The Minister may…”, but the need for human input also applies to assessing whether a given fact matches the ordinary use of an undefined English word in the legislation. That is why much RaC work is on benefits and tax, where many of the inputs are from computerised registers, with relatively few needing human input (see this explanation of how human input can be seen as normal if RaC is extended beyond tax and benefits).
  • Open publication - People who use the expression RaC commonly also mean that the coding will be published in some way, to some degree and for some purposes. Some who have a strong tech focus will see this as an afterthought rather than a defining feature of RaC. Others see RaC as having a mission to enhance democracy, and believe open source principles and full publication will enable the public to comment more easily during policy formation and suggest changes after enactment.
  • Authoritative/explanatory - The publication issue is also linked to the question of what authoritative or supplementary status the coding should have. Attitudes on that vary from a minority saying it should be the official source of the law (from which expressions in English or other human languages could be automatically generated - see level 5.3 of Meng Weng Wong’s “Rules as code: Seven levels of digitisation”), through to most people in RaC seeing the human language version as still the one that is enacted, with the coded or marked-up version being merely explanatory (with no more legal force than any other official explanatory material).
  • Before/after enactment - Another common element, not as widely shared, is to see RaC as including the idea that the coding should, at least ideally, happen before the legislation is enacted. This was the approach taken in New Zealand, and then Australia, when the expression RaC was invented in 2018-19. But many of the people who now say they are working on RaC are focussed on the tech side and are most interested in finding efficient ways to code the large body of existing legislation, rather than focussing on new legislation.
  • Rules separated from operation - Another common element, perhaps more widely shared but more rarely expressed, is the idea that RaC involves keeping the expression of the rules separate from the coding for the operational and procedural elements. Often this is in terms of using logic programming languages, such as Prolog, instead of traditional programming languages, such as Python. This is partly also intended to make updating a program easier when the legislated rules are changed - so that the new rule can be fed in to the program (potentially automatically through an “API” or application programming interface) without having to write the whole program from scratch again or work out which bits of the program depended on the old rule.
  • Isomorphism/citations - Connected with separate representation of rules is the idea that a RaC encoding should identify the source in the legislation for each coded rule (or even for conditions or other elements inside a rule), ideally in a way that enables it to be correctly cited (as in “s4(3)(a)(ii) of the XYZ Act 2010, as amended from 1/1/2015 to 1/1/2016”). This is both so that any output from the coding can be checked against the text of the legislation (giving transparency and reliable “explainability” that AI systems inevitably cannot match) and so that the right parts of the code can be idenitified (possibly automatically) for updating when the legislation is subsequently amended (see above on use of APIs for automatic updating).

A screenshot of the RaC Wiki Handbook stating what RaC is

How does CRLP see Rules as Code?

Our idea of RaC is that it is more specifically about -

  • digitising at least the logical structure of new legislation while the policy is being formulated and the legislation is being drafted (when any mistakes that are uncovered can still be corrected, because the legislation has not yet been enacted); and
  • then publishing that digitised element in tandem with publishing the legislation, but with only explanatory status.

We take a view at the low end of the spectrum on how much should be coded, to what level of sophistication, and so for what purposes -

  • To us the digitisation can be as little as re-casting the English text (or marking it up) into a form in which a computer can read its if-then logical structure of conditions linked by “and”, “or” and “not”.
  • We see the purpose as being both to help people to read the proposed legislation and check its effect on particular scenarios, and to form a shared reliable base that other people can use to code the legislation in more depth for their own purposes (instead of having to make their own guesses about the logical structure).
  • We do not see the whole or main purpose as being to enable the legislation to be automatically “executed” to achieve compliance with it. But we do see a key element of RaC as being to enable an automated system to guide a human decision-maker to the right question that they need to decide in order to work out how the legislation (on its face) applies to a given set of facts, and then to the next right question, depending on the answer to the last one, and so on.
  • At this end, the coding is adding the minimum to what is on the face of the text, and is following the principles on which the legislative drafter wrote the text, so that the chances of a court disagreeing should be minimised. However, this is at the price of saying the the coding is only attempting to capture what is on the face of the legislation, not any of the supplementary material that is needed to be certain about a particular individual’s legal position. That means it does not attempt to capture case-law or general principles that are left implicit in Commonwealth legislation. For instance the legislation will say that a person who does a particular type of act commits an offence, but will not say on its face that a person under a certain age would not count as committing any offence, or that there are general defences of duress and so on.

For more on CRLP’s vision of RaC and related technology and drafting issues, see these longer explanations by our lead, Matthew Waddington -

How do we see a drafting office version of RaC fitting in to different levels of coding by different agencies?

We see this as just the lowest end, at which a legislative drafting office would operate. We then see a set of layers built up from that low end, each in turn based on further assumptions that are each increasingly vulnerable to challenge in court.

  • So a government department would take the basic if-then produced by the drafting office and add more coding to reflect its view of what the legislation means. Many tech folk talk of “government regulations” without spotting that legislation, even when made by the government, is for the courts to interpret not for the government (at least in Commonwealth countries as opposed to USA, although even there the doctrine of “Chevron deference” has been rolled back recently).
  • Then an independent regulator might add further coding to reflect how it interprets the law and the guidance that it has issued.
  • Lastly a business or advice agency might add further coding to reflect how it sees that law and guidance, but also mixed with its own business rules or knowledge base and some operational elements, so that it can produce an executable program to carry on its business or support its advice.

The common example given is of the rules for banks vetting customers. The legislative drafting office could produce an if-then formalisaton of the legislation, which the sponsoring government department would use to produce a more fully coded version reflecting its view. Then the regulator would use that to add elements reflecting its guidance, codes of practice and so on. Finally each bank would want to obtain software that incorporates the legislation and guidance, along with its business rules, and can be executed by its staff to handle taking on new customers. So the banks would commission developers to create that software by buidling on the published material from the drafting office, government department and regulator, to give the banks and developers more confidence that they were correctly capturing the rules that come from outside the bank.

A quick history of RaC and our involvement

The RaC movement started in 2018 in New Zealand as a spin-off from their “Better Rules” initiative. From there it quickly spread to Australia, particularly because of the work of Pia Andrews (who then also moved to Canada). In Jersey’s Legislative Drafting Office we became aware of this in 2019 and started work on the idea from our perspective straight away - see our 2019 paper for the Commonwealth Association of Legislative Counsel. We have consistently contributed the perspective of legislative drafters on how legislation is actually constructed, which is crucial both to keeping RaC within constitutional limits and to giving it the chance to produce results in the real world.

RaC’s global spread was given a particular boost in 2020 when the OECD produced a report on it “Cracking the code: Rulemaking for humans and machines”, calling RaC “more than simply a technocratic solution” and saying “RaC represents a transformational shift in how governments create rules, and how third parties consume them”.

  • The RaC movement has since spread to Canada (see below), UK, France and elsewhere. In Jersey in 2022 we obtained funding for this Computer-Readable Legislation Project, which started in 2023.
  • Particular progress has been made in Canada, where they have used Blawx by Jason Morris, and legislative drafters have been involved - see their December 2024 article comparing AI with Blawx in the Loophole (journal of the Commonwealth Association of Legislative Counsel). For more on their work see these slides, this video and this OECD report.
  • A particularly active group now is the “RaC Guild” who have a very useful set of videos of their monthly “townhall” meetings where different groups from across the world present updates on their RaC work.

For a set of links on the history of the wider “computational law” concept (and the older “legal expert systems” idea), see this list and this one, both from Legalese. Other useful sources of information are -

Other perspectives on RaC

For external perspectives on RaC and related issues, see the work of Australian academics Dr Lisa Burton Crawford, Prof Lyria Bennett Moses and Dr Janina Boughey, particularly -

For a perspective more opposed to RaC, see the work of COHUBICOL led by Mireille Hildebrandt (author of the free online book Law for Computer Scientists and Other Folk. In particular see -