Photo by israel palacio on Unsplash

Towards a definition of Rules as Code

‘Rules as Code’ is not a single technology, component, or practice — it includes many different aspects beyond merely coding rulesets.

Tim de Sousa
3 min readMar 25, 2021

--

What is ‘Rules as Code’? is the wrong question

As digital transformation continues to gain pace within governments and the legal industry, “what is Rules as Code?” is becoming an increasingly common question.

It’s also the wrong question.

Let’s step back a bit. In the Observatory of Public Sector Innovation’s 2020 report on RaC — Cracking the Code — the OPSI went into some detail trying to define Rules as Code (RaC). They had some interesting observations on the intended outcomes of RaC:

“RaC does not simply aim to improve or enhance what already exists. Rather, RaC envisions a fundamental transformation of the rulemaking process itself and of the application, interpretation, review and revision of the rules it generates”.

However, the OPSI ultimately concluded that “consensus around what RaC actually is, or may represent, is not yet settled…the RaC concept is still at the earliest stages of interest and adoption”.

Similarly, the Brainbox Institute noted in their March 2021 report on Legislation as Code in New Zealand that, at present, there’s “no specific authoritative definition of “rules as code””, and that the term “is mostly used as a rallying point… to encourage a wider conversation engaging the many perspectives and practices that surround the practice of putting these two fields (“rules” and “code”) together”. As Brainbox observes, much ink has been spilled on what RaC is not, rather than defining what it is.

So, what’s the right question?

Perhaps the right question, right now, is not “what is Rules as Code” but “what do we want Rules as Code to do”? We can then structure our concept of what Rules as Code is around what we want it to help us accomplish.

Critically, we need to look beyond the foundational work of just coding rules, and think more holistically. To paraphrase Heather Burns, if you add digital on top of a thing that is broken, you will just have a broken digital thing. For that reason, it’s important that RaC isn’t boiled down to ‘code the rules — rules are coded — job done’. If we’re going to apply RaC to a problem, we need to be sure that it’s a problem that RaC is suited to solve. If a policy issue would not be well served by prescriptive rules, there’s no point applying prescriptive rules just so we can code them - coding suboptimal rules will only allow you to deliver suboptimal results faster.

Rather, my vision of an optimal Rules as Code implementation is a holistic, end-to-end approach. An ideal implementation:

  • begins when the policy is proposed
  • identifies a policy problem that is appropriately addressed by a prescriptive rules (wholly or partially)
  • recognises machines and systems are rules users, and thereby publishes machine-consumable rules
  • meets certain key criteria to ensure integrity (such as isomorphism, transparency, and availability of rules), and
  • ultimately, is focused on enabling better outcomes (not just digital outcomes) for citizens and organisations.

I find it easier to lay out visually:

A diagram of the Rules as Code approach, setting out sources of rules, implementation criteria, applications, benefits and objections.

High res version here.

So what is Rules as Code?

I’d argue that RaC is an approach, with many different components. It’s underpinned by the recognition that the users of rules include machines and systems (so, therefore, rules need to be machine-consumable), and by certain key criteria which are required to ensure optimal outcomes. Importantly, it’s not magic — it’s a tool. Like all tools, it’s only going to work if it’s used correctly and to solve the problems it’s adapted to solve. You don’t use a screwdriver to hammer in nails, after all (and you really shouldn’t try).

But more than that, it’s a means to an end — RaC is merely the means to achieving better, more accountable decisions, cheaper and more efficient services and compliance systems, and greater ease and understanding in applying rules. The components of an optimal RaC approach and the technologies that we use may (and likely will) change and evolve — but those objectives will stay the same.

--

--

Tim de Sousa
Tim de Sousa

Written by Tim de Sousa

I’m an Australian privacy and information governance policy specialist with a focus on innovation and emerging technologies. @timdesousa

Responses (1)