We have been working with the New South Wales Government on applying Rules as Code to the Energy Security Safeguard in a bid to drive sustainable energy use throughout the state — here’s what you need to know.
We are Sindhu, Yuguang and Ram. Sindhu is a Designer, Yuguang is a Data Scientist and Ram is a Software Developer. We are a close-knit team of three doing wonderful work together. Check out our last blog post to find out a bit more about us.
We’re currently doing a Fellowship with Code for Australia wherein we’re paired with a government team who are exploring new ways of working. We identify, prototype and test ways that technology can improve service delivery and citizen engagement. Through this, we build not only useful and impactful technology, but also capability for our partners.
We have been working with the NSW Government on applying Rules as Code to the Safeguard. The Safeguard is a broad and complex scheme which aims to incentivise households and businesses making energy-savings improvements.
In a bid to make the Safeguard as successful as possible, we’ve been utilising a concept called ‘Rules as Code’ to make these rules easier to access and understand.
What is ‘Rules as Code’?
Rules as Code is an approach to create and publish policies in a machine readable way. What this means is that legislation can be coded, and through that, be used to build digital services.
This makes policies and legislation more accessible and updatable, and also makes it easier for government departments to improve digital service delivery, with the aim to better integrate with other services and stakeholders.
What do we mean by ‘Rules’?
‘Rules’ in this case doesn’t mean the entirety of a piece of legislation. Instead, it can be thought of as specific parts of legislation, regulations and policies that are a little more ‘black and white’.
Rules as Code is especially well suited to ‘yes/no’ questions, ‘if this, then that’ decisions or statements and calculations.
For that reason, in the past it’s primarily been used for determining eligibility for certain services, or understanding complex numerical calculations, such as tax benefits and reforms.
What Rules as Code is NOT.
Since Rules as Code is still a fairly new and experimental concept, there are a lot of misconceptions around it.
It’s important to understand the distinctions between what Rules as Code is, and what it isn’t.
Here are four things that Rules as Code is not:
- Robots taking over policy
It’s important to note that the code written is not randomly making decisions based on legislation. Creating Rules as Code projects involves a huge amount of discussion between policy makers, lawyers, designers and developers.
These multidisciplinary groups ensure that there is a well-rounded understanding, and reasonable definition of all concepts and rules that would need to be coded. These definitions are also stored and key decisions made by these groups are tracked to ensure transparency and visibility.
The code merely holds the rules that have been created and specified by these teams.
2. Automated policy making
Rules as Code in no way has any algorithm or Artificial Intelligence. It’s not about machines writing new policies or creating new rules.
What it is, is an approach that policy writing teams can use to look at how best to present or define rules to fit a digital approach.
3. A specific technology or platform
Rules as Code is a process, not a specific piece of technology or software that everyone has to use. It can use many different platforms or technologies but the primary goal of all Rules as Code projects is to ensure the transformation and transparent delivery of rules.
4. It’s just another government project?
Rules as Code holds a huge amount of potential for the future and could change the way a lot of processes work within government, from service delivery to policy making. Its focus on ensuring that rules are logical enough to code means that rules and policy will also generally be improved in terms of clarity and understandability.
All of this means that Rules as Code really is the future of governance.
What Rules as Code looks like around the world
Rules as Code has been used around the world for many different reasons. For example — France has created a site that allows the simulation of tax reforms and benefits, a project from New Zealand communicates a ruleset to stakeholders, and in New South Wales we have a project that assesses eligibility and increases compliance for running community games (a project that Code for Australia worked on as well!).
Why are people talking about it?
The concept of Rules as Code has this incredible long term vision of all appropriate legislation being coded, accessible, continually updated, and acting as a base layer for other applications to be built on top of.
What that means is that there really needs to be a shift in mindset to consider and develop rules from a digital perspective, and to understand that rules might have numerous potential uses.
This requires a huge amount of discussion between everyone from policy makers, to legal experts, to tech experts, to end users.
Rules as Code is an approach that really can have an impact on everyone, especially as it will inform how rules are delivered — making sure that these important discussions are being had is a meaningful and necessary part of the process.
It’s also safe to say there are many, many questions being asked around Rules as Code and what it means for the world. Since it’s still such an experimental and iterative process, unfortunately a lot of these questions don’t have definite answers yet which can make people a little uneasy.
It’s important to remember though that asking these questions earlier rather than later, and continuing to ask them, is extremely important.
As Rules as Code gains more momentum and popularity, and as the benefits become more realised, we’re certainly going to get more answers for these questions, and ultimately, be able to create better policies and better services!
How are we using Rules as Code at NSW Government?
For the NSW Government, we were tasked with creating a frontend dashboard for communicating the Safeguard.
The Safeguard is a certificate trading scheme, which creates financial incentives for households and businesses to conduct energy savings and peak demand reduction activities.
It spans a wide variety of technologies, and each of those technologies is handled differently and has different calculation methodologies. The Safeguard is increasing in both scope and complexity through to 2030.
Due to its complexity, it has become difficult to communicate to internal and external stakeholders, and difficult to review and amend.
To address this problem, we were tasked with creating a coded version of some of the Safeguard’s rules, participating in the development of new Safeguard rules and developing a frontend dashboard which will:
- Allow users to navigate through the Safeguard in an intuitive way.
- Allow users to perform theoretical calculations, thus allowing them to see the outcome of certain clauses and calculations.
- Shed light on any structural inefficiencies in how the rule text is written, such as areas where rules might overlap or be inconsistent.
Development of the rules dashboard is ongoing, but has already provided valuable insight into the value of the Better Rules process, and the challenges associated with encoding a complex ruleset.
What was the biggest challenge?
The biggest challenge was balancing machine readability with human readability. Machine readability simply refers to the ability to do computation — this is the absolute baseline expectation of Rules as Code.
However, imparting human readability is more complex, because it requires defining context and structure.
These concepts are often quite separate to the logical operations (the IF/THEN/AND/OR/ELSE statements) of the coded ruleset. A lot of original rule text is dedicated to providing context and structure.
The challenge lies in replicating that context and structure in the coded ruleset, so that the code is traceable back to the legislation.
If the coded ruleset looks like the desktop on the right, then it will not be human readable. It will likely also not be maintainable either. Simply put: if we code rules like this, they will not be used!
To address this challenge we created a methodology for coding rulesets which applies a hierarchical structure of inputs (e.g. user inputs) leading to outputs (answers to specific clauses in the rule text).
We have found that not only is this methodology understandable and maintainable (from a software development perspective), but it also provides insights about how policymakers should draft rules, and how we can present those rules to users in an accessible manner.
How else can this coded ruleset be used?
The rules dashboard is not the only use case for the Safeguard’s coded ruleset. The existence of the coded ruleset unlocks a number of opportunities for the NSW Government to deliver digital services.
Here are three examples:
- Having a machine-readable counterpart for the rule text unlocks the potential to communicate the rules in many different formats (not just as a policy document written in legalese). Consider the difficulty involved with reading and fully understanding the 200-page policy document!
- It allows the NSW Government to streamline its digital service delivery by providing friendly web forms that allow users to interact with the rules. Furthermore, these web forms can be directly linked to the ruleset, rather than being something additional created by a frontend development team. This means that future changes to the ruleset will be automatically reflected in those frontend services. A living example of this can be found in the NSW Government’s Community Gaming Check web form.
- It allows stakeholders (both internal and external) to review and test changes to the rules. Assessing the impact of such changes can be difficult when all you have to rely upon is the written rule text. Conversely, multiple versions of a coded ruleset can be released, allowing stakeholders to compare and empirically benchmark versions against each other. This is a hugely valuable step in the consultation process!
What are we working on specifically with the Energy Security Safeguard team?
We started with the existing Energy Savings Scheme (ESS) rules, which aim to incentivise energy saving activities. Some of these rules have been already translated into code. However translation is not all there is to “Rules as Code”. What we do with the translated code is critical to any Rules as Code project.
In this case, we built a dashboard that combines the logic and formulae from the codebase and the rules ‘context’ (clauses and schedules) from the policy documents. This dashboard captures the essential ingredients of the ESS rules for user interaction.
We have in mind two groups of users for the dashboard.
One group is the ‘consumers’ of the rules, which in our case is the Accredited Certificate Providers (ACPs) who need to apply the rules for eligible energy saving activities.
Another group is the ‘creators’ of the rules, who work within the Department to ensure the successful delivery of the Safeguard . By having this dashboard, we would be able to achieve timely and automatic delivery of rules whenever the rules get updated.
One thing the two groups agree on is that some of the rules can be very complicated. Hence in this fellowship, we’re also focusing on making ‘Better Rules’, i.e. Rules that are simpler and easier to understand, while also effective in encouraging energy saving behaviours on the ground.
Recently, we have been invited to be part of a co-drafting/co-designing process for the Peak Demand Reduction Scheme — a new component of the Safeguard.
We hope to provide an effective feedback loop by creating features in our dashboard that allow policy makers to ‘see’ the rules, ‘play’ with the rules, and ‘experiment’ with different scenarios, and potentially be able to compare different versions of the rules.
We are only halfway into our Fellowship and have made tremendous progress in building up the technical infrastructure and understanding behind the ‘Better Rules’ process.