Rules-as-Code: Encoding Rules in a Government Context — Part 2

I am a developer fellow for Code for Canada, a non-profit organization that works with government agencies to deliver better digital services to the public. I am part of a team of three that is working with Employment and Social Development Canada (ESDC) for a 9-month fellowship. We have been working on a prototype for a tool called a Policy Difference Engine (PDE). The purpose of this tool is to measure how a change to a rule may impact a population. The key component of a PDE is a reliable encoding of the “rule”, which here refers mainly to a piece of government policy/regulation/legislation. In this series, we’ll introduce the concept of Rules-as-Code, discuss the value behind it, and show you what it looks like in practice using an example from our fellowship.

In the previous post, we presented a working definition of Rules-as-Code (RaC). In this post we will discuss the value it has in a government context. The third and final post will present a high-level walkthrough of a RaC project that our team participated in during the fellowship.

Value of RaC

Now that we have a working definition of RaC, let’s use an example to understand the value that it can have in a government context. For our example, we will use the Motor Vehicle Operator Hours of Work Regulations (MVOWR). These regulations are primarily responsible for describing how much overtime a motor vehicle operator is entitled to. Overtime hours for general employees are outlined in the Canada Labour Code. This regulation overrides that situation specifically for motor vehicle operators. In order to do this, it must first define what is meant by a motor vehicle operator. So already, we can start to pull out some key questions that are addressed by this rule. These are the questions that we should be encoding into our RaC engine. The main question is: Given a particular schedule, how much time is a motor vehicle operator entitled to? The answer depends on many different factors related to the nature of their work and the number of hours they work, so it isn’t exactly back-of-the-napkin math. While this question seems to be the main one, other questions can also be extracted from this rule, such as:

• What classification of motor vehicle operator am I?
• What are the maximum hours that a highway motor vehicle operator can work per week before being entitled to overtime?

Questions like this can be valuable to a variety of stakeholders:

• Motor vehicle operators themselves, who want to know how much overtime they are legally entitled to
• These operators may also deal with service agents who need to know important information such as this, in order to help address unique situations that are affected by other government rules
• Employers will need to know this information for HR and accounting purposes
• Policy researchers may want to use this to understand how this regulation may intersect with other rules related to motor vehicle operators
• Social researchers may want to test scenarios with real data to identify if any particular groups of motor vehicle operators are being disproportionately affected under the existing system
• Economists may want to use the information to estimate the costs associated with the rule

Note that some of these use cases align very closely with the idea of the policy difference engine mentioned in the introduction. These examples are specific to this regulation, but you can imagine how a similar line of thinking could lead to many use cases for many other government rules. Based on these use cases, we may need mobile apps, chatbots, web applications, business software, and research tools that all need to make use of the same set of rules. Many of these rules may have never been scrutinized under a technical lens alongside policy experts. And if they have, then they may be sitting inside a blackbox and therefore unusable to anyone else.

It may also be the case that some obligations are inferred or implied by the rule, rather than being written explicitly. So if you ask 10 product teams to interpret and implement these coded rules, you can end up with 10 completely different systems. So the accounting software may have different rules than a user-friendly chatbot, and both of these may be different interpretations than a research tool that is using the rule to inform policy. Next, Imagine that a change is made to the regulation. Now those 10 different applications need to interpret the change, leading to even greater possible variation in functionality. This all has potential to create major blockages in the implementation, delivery, and improvement of the rule.

This is where Rules-as-Code comes in as an approach to help alleviate issues such as this. Suppose we had a single system that is being used under the hood (maybe exposed as an API) by all of these motor vehicle-related applications. This makes the development of these applications much easier, and it helps ensure a consistent experience. This system was developed, is maintained, is tested by, and is iterated upon by a cross-disciplinary team of technical, legal, policy, and design experts. This gives us reliability and accuracy on the rules. The source code for the system is available for all to see so people are able to understand exactly how these decisions are made for them. This system could also be a single component of a larger system that contains many more government rules.

In the final post in this series, we will present a high-level walkthrough of a RaC project that we participated in as part of our fellowship.