Don’t forget to subscribe to our to stay up-to-date.
A comprehensive introduction to Rules as Code
This video covers an introduction to Rules as Code, Rules as Code in action (demos), the GovCMS and Salsa RaC framework, and how to get from rules to a finished product, using the BenefitMe website as an example.
Video sections
0:00 – 1:37 - Introduction and agenda
1:38 – 2:39 - What is Rules as Code, OpenFisca and Drupal
2:40 – 3:58 - Why Rules as Code?
3:59 – 5:26 - Rules as Code is recognised globally
5:27 – 6:38 - Rules as Code around the world and policy twins
6:39-8:41 – Rules as Code examples and PolicyEngine demo
8:42-11.15 - BenefitMe demo
11:16-12.24 - Rules as Code framework
12:25-14:28 - Rules as Code process
14.29-16:19 - Solution architecture, OpenFisca and Drupal
16:20-16:46 - Next steps
Resource links
OECD paper, Cracking the Code: Rulemaking for Humans and
OECD paper, Global Trends in Government Innovation
Transcript
Hi, and welcome to the second video in our five-part series about rules as code. My name is Philipa Martin, and I'm the Rules as Code lead at Salsa Digital, an open-source digital innovation company based in Melbourne, Australia.
Today I'm here to talk to you about Rules as Code or RaC for short on behalf of GovCMS. GovCMS is a whole-of-government content management system and web hosting platform built by government for government.
In this video, we're going to cover eight main areas. The first two sections are about introductions. A quick intro to me and an introduction to Rules as Code. Next, I'm going to show you some Rules as Code examples, websites where you can see Rules as Code in action right now. Then, I'll give you a brief overview of our Rules as Code framework before doing a deep dive into a website called BenefitMe. For that one, I'll show you the finished product, but more importantly, how we go from legislation to a Rules as Code interface. I'll also show you very briefly the technology behind our implementations of Rules as Code.
So, first introductions. I have a background in content with an interest in the law. I started in Rules as Code in January 2022, working with a larger project team to convert the New Zealand Social Security Act into an interactive Rules as Code experience. Since then, I've continued working in the Rules as Code space as a business analyst. In this second video in the GVCMS Rules as Code series, we take a deeper dive into Rules as Code. So hopefully you have a really good overview in less than 20 minutes.
What is Rules as Code? Simply put, Rules as Code is about taking legislation, rules, and policies and turning them into code. Users can then
easily interact with the rules via direct user experiences such as a website or voice interaction.
Alternatively, the rules can be integrated with multiple systems and websites via an API. Salsa and GovCMS are currently using OpenFisca to implement Rules as Code. OpenFisca is an open-source Rules as Code platform that can be used to encode and serve legislation and regulation as code. It's a lightweight, modular, and scalable Python-based rules engine. OpenFisca was initially developed by the French Government in 2011 to codify their social security benefits.
Our solution combines OpenFisca for rules coding and Drupal for content management via the Rules as Code Drupal module that Salsa built in 2022. In government, Rules as Code can lead to better citizen interaction. Rules as Code implementations provide one source of truth that's easily accessible for citizens and customer service representatives. Importantly, Rules as Code removes the barrier of dense legal jargon and makes legislation and rules easy to understand and easy for users to engage with. Of course, Rules as Code can be used in many industries to deliver benefits and make it easier for users to interact with rules.
This diagram shows how Rules as Code can deliver a better citizen experience. Although citizens could be coming in through multiple entry points such as in person, online or on the phone, they interact with one digital system. Online, people can explore the rules themselves and even experiment with the variables. This creates an experience that's also dignified. Perhaps they're on a benefit and their part-time income is going to go up or down. Using Rules as Code, they can explore how that would affect their benefit quickly, easily, and privately. Because Rules as Code can provide a single source of truth for citizens and public sector staff, this removes ambiguity. In addition, the ability to self-serve reduces the burden of inbound calls and/or email inquiries.
Rules as Code is also globally recognised as an area for transformative growth for government. In 2020, the Organization for Economic Cooperation and Development via its Observatory of Public Sector Innovation released a paper Cracking the Code: Rulemaking for Humans and Machines. One quote from that paper is "by creating a machine consumable version of government rules alongside the existing natural language form, governments may be able to drive better policy outcomes, increase efficiencies, and open up new avenues for innovation". The paper includes six principles for a successful rules as code approach: transparency, traceability, accountability, appropriateness and appealability, availability and interoperability, and security. More recently, the OECD’s Observatory of Public Sector Innovation released a report on trends in government innovation. This report looks at a number of areas for innovation across government and includes information and case study on rules as code, including the GovCMS proof of concept on COVID vaccinations. The paper specifically mentioned Rules as Code’s transformative power and how it can make government more transparent.
Hopefully now that you have a high-level idea about what Rules as Code is and its benefits. But I think the easiest way to show you the power of rules as code is to demonstrate Rules as Code in action. So here we can see a handful of real-world use cases using rules as code to improve the citizen experience. As you can see, it's being used in the US by Benefits Launch Express and PolicyEngine which also has implementations in the UK and Canada. In Belgium, we have the aviation portal and in France, Mes Aides, the original Rules as Code application. In Australia, we have the GovCMS sandpits and in New Zealand we have SmartStart.
One of the most powerful uses for Rules as Code is constructing policy twins. Ideally, while creating legislation, you also create a policy twin. While digital twins of cities help model urban planning, infrastructure changes and more, digital policy twins let citizens interact with rules quickly and easily while also allowing government and policymakers the ability to experiment with policy changes and see how they'll affect government and citizens. Rules as Code for policy twins has the power to revolutionise the way we draft and implement policy.
Here are three examples of Rules as Code in action. The first one is a social security benefits checker in New Zealand. I won't look at this one in detail now as I'll be doing a deep dive on this one shortly. The next one is PolicyEngine, which combines benefits eligibility with policy modelling and simulations. It shows you the power of a digital twin. I'll give you a quick demo of this one. But before I do that, our third example that I'd like to bring your attention to is the New South Wales community gaming check, which is a good example of a more simple type of experience.
PolicyEngine, as you can see on screen, includes compute my taxes or policy reform impacts. In this case, we're going to have a look at one from the Internal Revenue Service. So we select that from the menu here of government departments and we're going to have a look at income. Specifically, we're going to change the rate of individual income tax rates for bracket two from 12% to 10%. On the left-hand side you can see that it's telling you what the policy change is and then we have a look at what the results are. On the right-hand side of the screen is the overall results and overview showing you for example here it's going to cost 79.3 billion, lower poverty by 2%, and raise net income for 71.5% of people. We can break these down and drill down even more looking at things like the distributional impact by income, winners and losers by income decile, and poverty impact. You also have the ability to generate a summary using ChatGPT and to view the Python code that's behind it. So that gives you a quick overview of PolicyEngine. I suggest you have a look at that one yourself.
Next, I'd like to look at BenefitMe. BenefitMe is about the New Zealand social security benefits. We worked on this project with the Digital Aotearoa collective including Pia Andrews. We created a Drupal webform that integrates with OpenFisca to check eligibility for social security benefits using the Drupal Rules as Code module. It includes calculation logic. This one has since been expanded out, but let's have a little look at one. So, let's look at BenefitMe in action. Here we have the homepage. Go to get started, have a little bit of introductory information, and then we can see the webform. In this case, the user is going to fill out that:
- They're a New Zealand citizen or resident
- Going to put in an age, in this case we'll put in 35
- They're currently without work
- They don't have an injury or disability and they're single
- If they were to put independent children, you'll see the form produces some additional fields
- Also about their situation
- How much they earn
- If they're currently receiving specific benefits
- Finally receiving family tax for that section.
- Next section is about accommodation, entering accommodation costs
- The postcode because one of the benefits, the accommodation supplement, is different depending on the postcode.
After hitting submit you'll see information summarising what the inputs were and then the eligibility itself. In here you can see you have the overall of $319 per week after tax and then the breakdown of jobseeker support of $309 and an accommodation supplement of $10. We also have information about payments you're not eligible for and also payments that you might be eligible for just because in this particular example there were only four benefits coded at this time.
So that gives you a good example of BenefitMe. BenefitMe is one longer web form with some areas that expand out if you select certain items. You can also create separate webform screens to group information or show a logical user journey. As you can see on screen here, this is the one for the COVID vaccination. You can see it's broken down into you, your health, your COVID vaccinations, and then the results.
So, how do we get from legislation to those final products? To show you that I'm going to take you through the process focusing on BenefitMe. But first, let's look at the broader context of the overall Rules as Code framework and the Rules as Code process. To explain how it works, we thought it would be useful to frame it around a Rules as Code delivery framework. As shown in the illustration, the framework is broken into three streams: governance, implementation, and operations.
The governance stream, mostly non-technical and arguably the hardest, is all of the considerations around custodianship, access, change management, and standards. Implementation is a stream of actually converting the rules into code and building related and relevant user experiences. It covers rules logic, the code repository with open API, systems integration such as with the Drupal content management system, and user experience. The operations stream is concerned with enterprise-grade themes required to make the solution secure, sovereign, and resilient as well as general maintenance. I'm going to focus on the implementation stream for the rest of this video.
The high-level process is the rules analysis and mapping, OpenFisca configuration, coding, building the Drupal webform, and setting up the results pages. Let's have a look at BenefitMe rules mapping. We start with rules analysis, extracting the rules in plain English and rewriting them as rule statements. Next, we look at the rule logic using a user journey flow or eligibility logic. At this stage, we're also writing the questions that we need to get inputs to check against the rules legislation. Finally, we write test cases. On screen is a screenshot showing some of the eligibility logic in a visual flowchart. To show you how it's done, I wanted to show you this screenshot for supported living payment. This is operating from a Miro board. You can see on the left we have actual screenshots that have been inserted from the legislation into the Miro board for easy reference. Then we start mapping out again using the visual logic of the person and what will make them eligible. Going through each point from the act including legislative references which are in those little yellow boxes above the pink post-it notes and in the yellow post-it notes is actually the OpenFisca code.
A quick note about rule statements. Rule statements provide simple plain English statements of the rules. Salsa's process usually includes formal rule statements as the first step in rules analysis. They're a good way to interpret the rules legislation into simple concepts and statements which can then be more easily mapped. They're especially important if the person mapping the rules is not a subject matter expert as they allow the business analyst to fully understand the rules. Content from the rule statements can also be used in the questions, possible responses, and sometimes in the results pages. They're also the starting point for our actual eligibility logic.
Now, let's have a look at some of the technical details. This diagram shows you the rules as code architecture GovCMS and Salsa are currently using. In the bottom right, we have the legislation which gets coded in OpenFisca and integrated with Drupal GovCMS. Users interact with the system via websites, mobile apps, voice devices, and other system interfaces. Inputs go into OpenFisca, which then produces the outputs and calculations.
Okay. Now let's look at the OpenFisca part of the puzzle. OpenFisca coding follows a five-stage process of writing test scenarios for test-driven development, creating entities, creating parameters, creating input variables, and then creating formula and output variables. We'll provide more information about OpenFisca in our dedicated OpenFisca video.
Next, Drupal, our content management system. In Drupal, we use webforms. Our Drupal OpenFisca module allows us to map webform fields to the corresponding OpenFisca API. We also use nodes to add in the rules for branching. For each webform, we define where the user needs to be redirected based on the response from the OpenFisca API. Finally, we also use Drupal to display the results pages, which can use tokens and/or blocks to show tailored information. Here is the example of the web form from BenefitMe, which you saw in action before and this is a sample result. In this particular implementation, there is one result page. Each of the benefits has two content blocks, one for if you are eligible for the benefit and another for when you are not eligible for the benefit. We also use tokens from the responses. These blocks are shown or hidden on the page based on the response from the API.
So what's next? Where to from here? If you're a GovCMS customer, please contact GovCMS to discuss your Rules as Code use case and organise a sample project to give Rules as Code a test run. You may also like to look at some of the Rules as Code implementations demoed during this video or join the Rules as Code Guild Slack channel to ask questions. And if you're not a GovCMS customer, we still hope you dive into Rules as Code. Thank you.