Media Suite Developer Ersin Buckley recently participated in a project for digitalising legislation. The working group included specialists from across government and the private sector. Media Suite loves sending our crew out for these real-world learning experiences. Here’s more about what he learned.
The concept of digital legislation is one I have been investigating for some time. In 2017 I was having a lot of fun experimenting with prolog, so development of expert systems seemed to be an ideal use-case for using the language. When I stumbled into the regulation as a platform (RAAP) product, it piqued my interest in how expert systems could be applied to the domain of law. RAAP proposes that implementing digital standards for law would empower people to better understand how the law impacts them. I could really get behind the social good this kind of system could provide people. On another level, I really enjoy learning about new problem domains that technology can be applied to. Law and regulation is something I was a complete beginner in.
After my initial investigation, I determined the next most important thing was to start testing ideas with policy and legal drafting experts. Fortunately the perfect opportunity came up with the service innovation lab’s Better Rules for Government design sprint. Going into the investigation I hoped to learn about how legislation is developed, and how the process and tools could be used to better support digital service implementation.
The core team involved people from MBIE, IRD, PCO and DIA. We had representatives from the business rules analysts, to law experts and service designers. The input I provided was software expertise and experience implementing digital services from legislation. Outside of the core team we attracted a diverse tribe of stakeholders who joined us for a demonstration of the work done at the end of each week.
One of the areas where I learned the most was about the actual process and people involved in making a new rule. I was excited to find many similarities between legal drafting and writing code. During the sprint we experimented with co-creation of a legal draft with a cross functional team involving policy, law, service design and software people. We looked at the Rates Rebate Act to create a new draft that meets the same intent. The theory was that a co-creation team would produce a solution that is well set up for digital service delivery. I found the process of co-creation to have many of the same positive features that Agile software delivery has.
In the software world we refactor code to reduce technical debt and make a maintainable system. Within government the same thing is done with law. When a rule is implemented, there is an opportunity to improve other parts of the act. Continuous improvement happens to make the law more maintainable and improve quality. These changes do not alter the intent of the law, but they make it easier to use and understand.
When I’m writing code, despite feeling like a genius when it starts working, I can never trust that the code is ‘correct’. At Media Suite we do code review to improve the quality of our code. Legal drafting has an analogous process where peers can test and provide suggestions for better structure of the law. This means when it gets enacted, there is less chance of it requiring amendments.
The structure of an Act has a ‘interpretation’ section. In software thinking, this reads like a description of the data-structures in a system. It includes the definitions of nouns and actions that will be in subsequent sections of the text. You can see an example of this in the interpretations section of the Rates Rebate Act.
I’m constantly reminded of functions when I read a section of the Act. Each section will mention a number of terms from the interpretation section, these are the parameters to a function. A return type for the function can be thought of as the conclusion of the term. Sometimes that may be a numerical value such as “amount of money”. Other times it may be a boolean such as “the person is entitled to the rebate”. In the law, clauses may depend on other clauses, this is like a function that composes other functions to achieve your desired result.
One day during the sprint we sat down side by side to experiment with the idea of implementing legislation as code. My weapon of choice for our legislation as code experiment was a simple jupyter notebook. I wanted to test if I could implement the rules alongside the legal draft in parallel. We delivered the digital legislation with three supporting components, pseudocode, legal text and python code. You can check out the python code on my Github here.
In the future, a common framework for law development would enable a business to import the rules into their own systems. This means that when a law has been scheduled for change, organisations will be able to test the change and model the impact of the change. An open standard for the interpretation and definition of digital legislation will enable this. The first step towards digital legislation is to form co-creation teams to implement law. This means that service delivery, software developers, law experts, policy people and subject matter experts will be working together. At Media suite, this is an area where we have some experience. We bring Agile to a lot of challenges not related to software, our business is as much about creating behaviour change in organisations as it is about delivering technical goodness.
On a personal level, I really believe that the digital legislation will bring better information to people. By implementing law that is machine consumable, there are many opportunities to build tools that can inform people about the impact of policy. In addition to this, the new style of legislation will reduce the cost of implementation and compliance. By taking the first step of creating the co-creation team, solutions will be well suited for service and software implementation.
