“Rules as Code” is a label adopted by people in governments working on the idea of encoding (or just marking up) legislation while it is being drafted, so that the logic of the resulting legislation can be “read” (and checked) by a computer, to improve the manner in which legislation is produced and the way in which it is available digitally. The idea is currently attracting attention in the legal community, particularly on the question of whether it will lead to automation replacing human interpretation of the law. This note briefly describes Rules as Code, at least as conceived by a legislative drafter. It argues that this conception of Rules as Code does not have the over-reaching ambitions that it may sometimes appear to harbour, and in particular does not trespass into removing key interpretative functions.
“Rules as Code” is great to apply while drafting is happening, but isn’t restricted to just that context. It can be applied to existing law too. (In fact, for many policy simulation/analyses for new law, you’d want to compare or build on rules for the new law to rules for existing law, so even by its own lights the limited view of Rules as Code as only being for drafting new law wouldn’t work out in practice.)
I suppose it depends whether you want to get hung up on labels. If you encode existing legislation then you are just doing normal “computational law” which has been around for many decades. I would be interested to hear what you would see as the difference that would be captured by labelling it as RaC instead.
If you want the advantages of doing it while there is still time to change the legislation, or of being able to say the legislators saw it before they passed it, then it needs to be done during the drafting. But you are right that at some point we will need to work out the best ways to tackle older legislation, and any legislative drafter would confirm that all new legislation is built into the existing statute book & surrounding non-statutory law.
RaC might inspire some govts to revisit, consolidate, rationalise & re-enact some of their older/ropier key legislation, which would be good, and would mean the RaC approach could be used. For the older legislation we might also end up using tools that are very different from RaC, such as https://www.regulatorygenome.com/ . It may also help with tackling older law if the govt product is limited to the slim version of RaC, just capturing what is in each piece of legislation, not adding material for ontologies that there is no authority for (bearing in mind that courts, not govts, are the ones with the authority to interpret the legislation once it has been made).
I also agree that we do need to look at what will work out in practice, but I would see that as contrasting with the idea that it is just about hunting for a tech tool to code law in general. Part of that is about moving away from the idea that we can start by encoding all of the law on a topic - even in social security there are criminal offences and public law duties & discretions, neither of which can be fully spelled out without heading into mazes of case-law. A focus on new legislation helps if we accept that the job needs doing one piece at a time, and will produce useful results even if we never code all of the statute book (never mind all of the law).
The first sentence of your abstract starts by defining a label, so it seems fair game to comment on it! Sometimes definitions do matter - definitions in the law certainly matter a lot when writing Rules as Code models for them.
I think there’s so much potential for Rules as Code beyond the narrow exclusionary view that it’s only to be done by governments and only while co-drafting new law. This narrow view is not-infrequently promoted in the RaC movement. My guess is it’s pushed for rhetorical purposes, to argue for the special importance of RaC that narrow context, and to emphasise that it’s not just a technical/computational issue but also needs other methodological foundations (and perhaps policy foundations). You can agree with both of those points (I do!) without excluding other useful applications of Rules as Code. I agree computational law is traditionally very focussed on technical issues, tools, logic, … and the RaC movement usefully emphasises the broader issues related to using those technological elements in practice.
I agree a narrow focus helps, but new legislation won’t narrow your focus in the right way in my view. One reason for that is that new legislation frequently amends or references old legislation to build on it. Another reason is that the expected interpretation of new legislation is normally impacted by the same “maze” you mention, even if there’s no case law established on it specifically. I think a better approach is to narrow focus by targeting a specific purpose for each RaC model - focus on narrow slices of law (new law, old law, case law, consensus expert views, …) that collectively bear on specific business/personal problems or policy questions.
Finally, while it would be great for government to create and publish RaC models (and we have argued for that in submissions to goverment), there is sometimes naive thinking in the RaC movement about the kind of authority that those models would have. I think it is unlikely that RaC models will in our lifetimes be published by governments as law or with the force of law. In general, it’s best to think of RaC models as tentative descriptive models of the law. Even governments don’t always get the interpretation of their own laws right! This is demonstrated when governments lose court cases for this reason. Businesses/citizens often have an interpretation of the law that is different to governments’. The RaC approach may help to reduce ambiguity, but it won’t eliminate fundamental interpretative differences. If a court later tells you that the interpretation you have modelled is wrong, or if your model has conclusions that are legally invalid, then you try to correct your model. Rinse, repeat.
This is one major reason why RaC is not just for governments. It’s also for businesses/citizens, so that they can express their legal viewpoint, and perhaps more clearly compare it to that of government.
Great conversation. Could not agree more. To support an end-to-end approach, we need to keep one eye firmly pealed on the ultimate “consumer” (businesses and citizens). Asking questions around how, when and why our customers consume law, regs etc, will lead to the most critical, and often surprising, insights in driving RaC. How can we do this better?
I should say though, that the article is generally great. Particularly nice to see it tackle the myth that RaC is only for “prescriptive” legislation/regulation. I thought related comments by Guido in the recent AUSCL panel on this issue were also nice - i.e. (paraphrasing) that principle-based law can be easier to model, but harder to automate, whereas more prescriptive law can be harder to model (more detail, etc) but easier to automate. And as Matthew argues in his paper, the automation here is probably best not seen as trying to apply the law as part of a legal process or judgement, but maybe instead to support other kinds of analysis and assistance.