Better Rules for Government Discovery Report

From late January 2018, the Service Innovation Lab (LabPlus) facilitated a cross-agency and multidisciplinary team in a 3 week Discovery Sprint exploring the challenges and opportunities of developing human and machine consumable legislation for effective and efficient service delivery.

This report details the findings from the discovery sprint and outlines an approach to the policy development and implementation process that generates a core and common understanding across disciplines, which can be iteratively refined at each stage to provide consistency across the whole process.

Download Better Rules for Government Discovery Report (PDF 2.4MB)

Summary

Introduction

The traditional models of creating, managing, using and improving the 'rules' of government (policy, legislation, regulation and business rules) were developed for use in a non-digital environment, and can result in a mismatch between policy intent and implementation. New digital technologies and the effective use of government data present opportunities to better deliver to people’s needs. To fully realise these opportunities, however, policy and rules need to be developed in a manner that recognises the context of impacted people and systems, and enables digital service delivery where appropriate.

Making government rules machine consumable so they can be used by service delivery systems is fast becoming a key component in the digital transformation of governments, particularly as we seek to integrate service delivery, automate information exchange and some decision making, while also ensuring government transparency, responsiveness and accountability.

‘Machine consumable’ for the purpose of this report means having particular types of rules available in a code or code-like form that software can understand and interact with, such as a calculation, the eligibility criteria for a benefit (e.g. see the financial assistance eligibility tool for SmartStart, which is powered by a digital rules engine) or automated financial reporting obligations for compliance.

“Legislation-as-code is the most transformative idea we got from the 2018 D5 Summit” -- Estonian Government CIO, Siim Sikkut

Approach

The Service Innovation Lab team (LabPlus) facilitated a small multidisciplinary group of people from Inland Revenue (IR), Ministry of Business, Innovation and Employment (MBIE), Parliamentary Counsel Office (PCO) and a private sector software company in a 3 week exploration to identify the opportunities and challenges of creating human and machine consumable rules for effective and efficient service delivery.

We applied a service design approach to understand the current state, propose a future state and approach and test our assumptions against two existing pieces of New Zealand legislation. For most of the team, the approach was a new experience. The multidisciplinary nature of the team required a lot of work to reach mutual understanding, and was also a valuable part of the process.

This 3 week discovery was the first step on our journey to understand the opportunities and challenges of creating human and machine consumable rules, and where to direct future efforts. We also recognised that not all rules are suitable for machine consumption. Part of this work was understanding what features of legislation are suitable to be made available in machine consumable format.

Key questions

What does the development of human and machine consumable rules mean for the way we develop policy and legislation?
What options are there for the production of machine consumable rules?
How do we ensure we have consistency between human readable rules and their machine consumable equivalent
How do we develop policy and legislation
in a user centred way - one that takes into consideration that people often need to interact with multiple rules at once, especially when these rules have been developed in isolation from each other?
in a way that considers the most effective service delivery approach from the outset?
- in a way that enables the use of digital technology, but is future-proofed by being technology agnostic
- How do we effectively and genuinely enable interested and affected people to help shape these rules?
What would a set of principles for the development of human and machine consumable legislation for effective and efficient service delivery look like?

Key findings

It is difficult to produce machine consumable rules if the policy and legislation has not been developed with this output in mind.
An effective way of developing such policy and legislation is for multidisciplinary teams of policy analysts, legislative drafters, service designers and software developers to co-design the policy and legislation, taking a user-centric approach that focuses on how the service could most effectively be delivered. In this case, ‘user’ can mean people and technology systems as the end users of machine consumable rules.
Co-designing rules with policy and service design increases the chances of the policy being implemented effectively and as intended, and can reduce the time it takes to deliver on the policy intent.
Machine consumable legislation that is co-developed:
- enables legislation, business rules, and service delivery software to be developed in parallel, ensuring consistency of application, and significantly speeding up the service delivery to people
- increases the opportunities to automate and integrate service delivery (including through the use of artificial intelligence).
Common frameworks, reference points and data points (like concept and decision models and ontologies(1)) will assist multi-disciplinary teams to co-design policy and legislation and, once developed, can be used as blueprints for the development of human and machine consumable rules without the need for further translation of the intent and logic (which, in turn, reduces the time and resources required and the chances of errors).
Not all legislation is suitable for machine consumption, but a multi-disciplinary approach will assist in making better rules.

Our proposed approach to the development of equivalent human and machine consumable rules could help support:

faster and better delivery of policy intent
services that are designed to be delivered in the most effective and user-centered manner
modelling and testing of outcomes
digital transformation of government
legislative reform
accountability of public and private measures and decision-making.

Recommendations

There are multiple and overlapping areas of interest in this space. For example, the DIA Service Innovation Team is primarily interested in people-centric integrated service delivery. The Department of Prime Minister and Cabinet’s (DPMC) Policy Project is interested in the policy implications. PCO has an interest in high quality and accessible legislation. IR’s Business Rules Centre actively shares with other agencies best practice on rules capability including the approaches outlined in this Discovery. And some government agencies are considering purchasing digital rules management systems.

Tackled collectively, there are opportunities for the government to save time, effort and money, and avoid future IT and legislative problems that are costly and hard to change.

There are opportunities to leverage off existing work programmes for some early wins. There are also more difficult, multifaceted aspects that would require broader changes to embedded processes. These will require a longer term approach and more significant work.

We recommend the development of an agreed cross-agency, coordinated programme of work supported by cross agency executive oversight, and a multi-disciplinary team to undertake further work in this area.

Opportunities we have right now:

Socialise the findings of this work as widely as possible, including with international partners
Collaboration across the New Zealand government:
- identify legislative barriers to data and digital transformation to inform the development of standard clauses, drafting guidance materials, and potential future amendments (working with PCO, DPMC Policy Project, and Stats NZ)
- look for other opportunities to road test this approach in a real world piece of legislation
- develop the suggested approach in this report further and integrate across the 7 Regulatory Stewardship Strategies (working with Treasury and responsible agencies)
- promote this approach across the policy community and its integration into agency policy methods (working with the Policy Project)
- develop standards for developing digital rules and outputs (work with MBIE’s Better for Business Programme)
- explore how artificial intelligence might use digital rules (work with the AI Forum)
- explore opportunities with the Government Rules Group.
Collaboration with Digital 7 and other nations:
- develop standards and frameworks for development and delivery of human and machine consumable rules
- exploration of open source tools that can be shared.

In this context we define ‘ontology’ as a set of terms or concepts, their definitions and their relationships with other concepts. This can be a thought of as a non-hierarchical categorisation of concepts that conveys more meaning than just the definition of terms.

Problem

The traditional models of creating, managing, using and improving the 'rules' of government (policy, legislation, regulation and business rules) were developed for use in a non-digital environment, and can result in a mismatch between policy intent and implementation. The traditional model can create some challenges to people-centred and digital service delivery, and open, transparent and responsive government. People can find the rules of government difficult to understand and navigate. Not all rules are easily accessible, and some are not publicly available. This can make it hard for people to understand their rights, obligations and entitlements, and how government decision-making affects them. Often the effort required to understand and follow the rules is disproportionate to the benefit of compliance.

Increasingly policy and legislation need to be interpreted and transformed into business or operational rules that are then programmatically coded to support service delivery. This rework is inefficient and allows misinterpretation and error to creep in.

When applying a people-centred and digital service delivery lens, some challenges with the current policy development and implementation system are:

can take a long time to respond to change
is fragmented and inconsistent, including the capture and maintenance of the rules and any associated knowledge assets, and how and when impacted people are involved
is inefficient for delivery of rules for use in business systems, because:
- there is a lot of work in analysing legislation to cleanly extract all of its first order logic (see the attached case studies on Eliciting business rules from legislation and policy for business use and Statute as code).
- the policy intent and rules logic are not always clear just from the published material. There are often hidden aspects to rule sets that are not apparent and have come about due to constraints of legacy systems (see the attached case study on Exploring a cross agency eligibility engine)
can create unintended complexities, inefficiencies, and missed opportunities for implementation when the service delivery model is not considered from the outset, as part of the policy development process.

Opportunity

New approaches to people-centred service delivery, including digitally enabled service integration and proactive delivery, present an opportunity to reimagine how government constructs rules, delivers on policy intent and manages for continuous improvement of service delivery and outcomes.

There are opportunities if we consider how we might make policy, legislation, and the business rules of government not just human and machine readable (like the XML, or Extensible Markup Language version of New Zealand’s legislation on legislation.govt.nz), but machine understandable. Turning the logic of these rules into reusable, machine consumable programmatic logic at source (rather than through translation) supports service innovation by both government and, where appropriate, by third parties (including artificial intelligence). However, we must remember that ensuring human and machine consumable rules have equivalence and are openly accessible is essential for transparency of government and algorithmic decision-making.

Many governments and private organisations around the world(2) are investigating the concept of delivering machine consumable rules, because they see it as the next big step to underpin the digital transformation of government. Likewise, it is recognised as an essential component for existing pieces of work within the New Zealand government’s Service Innovation Work Programme, including proactive and integrated service delivery for Rates Rebate, and entitlement rules that support integrated service delivery for the birth of a child life event service SmartStart (see the attached case study on Exploring a cross agency eligibility engine and the resultant financial assistance eligibility tool). It is also of value to the Better for Business work programme particularly with respect to making business compliance easier and more transparent, and the Inland Revenue’s Business Transformation Programme (see the attached case study on the Accounting Income Method (AIM)).

Key questions

What does the development of human and machine consumable legislation mean for the way we develop policy and legislation?
What options are there for the production of machine consumable legislation?
How do we ensure we have consistency between human-readable rules and their machine consumable equivalent?
How do we develop policy and legislation
in a user centred way - one that takes into consideration that people often need to interact with multiple rules at once, especially when these rules have been developed in isolation from each other?
- in a way that considers the most effective service delivery approach from the outset?
- in a way that enables the use of digital technology, but is future-proofed by being technology agnostic?
How do we effectively and genuinely enable interested and affected people to help shape these rules?
What would a set of principles for the development of human and machine consumable legislation for
effective and efficient service delivery look like?

(2) The governments of Scotland, Singapore, and Israel (amongst others), academic institutions (e.g. Stanford, and the University of Aberdeen) and private sector software providers are actively working on projects to understand how to effectively turn legislation into reusable software code to power digital service delivery and artificial intelligence.

These questions have system-wide implications, and therefore require a system approach. A collective of interested people from across and outside of government gained support to conduct a small piece of work to explore some of these questions.

From late January 2018, the Service Innovation Lab team (LabPlus) facilitated a 3 week Discovery Sprint(3) to explore the "user journey" of policy intent, from policy and legislative development, through to operational or service implementation in government, to identify the gaps, challenges and major pain points in achieving outcomes that best meet the policy intent. This included developing an idealised future state and testing it against two different types of existing legislation in order to understand the benefits and limitations of the model.

Who was involved

The Discovery Sprint was held at the Service Innovation Lab, and the core team included:

3 people from the Inland Revenue (IR) Business Rules Team
1 IR service designer
1 IR legislative drafter
1 policy analyst from the Ministry of Business, Innovation and Employment (MBIE)
1 strategic advisor for Better for Business (MBIE)
1 legislative drafter from the Parliamentary Counsel Office (PCO)
1 software developer on loan from the private sector
Support and facilitation from the LabPlus team, including service design, strategic, technical, open and transparent government expertise.

In addition, workshops and open sessions held during the 3 weeks included people from:

The Policy Project (Department of Prime Minister and Cabinet)
Office of the Clerk (Parliament)
Treasury Regulatory Quality team
The New Zealand Initiative
the legal profession
Ministry for Primary Industries
the Wellington tech industry.

What we did

We applied a service design approach to understand the current state, propose a future state and test our key assumptions. Given the short timeframe of the Discovery Sprint, these ideas were only explored at a relatively shallow level, with just enough depth to uncover useful insights that could be explored further. Our approach to problem solving reflected the experience and expertise of the team, and we acknowledge that there could be other solutions we did not consider.

In the Discovery Sprint we:

examined the current policy development and implementation system
considered what ‘good’ looks like for a future state where both human and machine consumable rules are produced that enable effective delivery of services
identified the essential components needed to achieve the future state and how they need to work
identified where and how a digital rules approach can add value as part of the policy development process
identified what features of legislation are suitable to be made available in machine consumable format
undertook two brief experiments using existing legislation to test the following hypotheses:
1. Using a digital rules approach could lead to better outcomes by incorporating service design and rules logic thinking
2. Legislation can be drafted as human-readable and machine-consumable rules at the same time
identified areas for further investigation.

Current state

We started by gathering input from a broader range of people to map out the “user journey” of policy intent. This resulted in the development of a simplified ‘current state’ policy development and implementation system. In this we focussed on the particular challenges to the development of rules for service delivery.

A key problem is that with the current linear approach it takes a long time to deliver impact or achieve the desired policy outcomes, and there is limited flexibility to change direction given new evidence or insights.

See a larger version of the current state diagram (JPG 90KB)

Read detailed description of the diagram

With the current state it takes a long time to deliver impact or achieve the desired policy outcomes, and there is limited flexibility to change direction given new evidence or insights.

The current approach is relatively linear as Policy Development iterates with Ministerial Decision making and then moves to Legislative Development, before throwing the set rules over the fence for operational implementation by Service Design and Delivery. If the policy is Operational then it skips the Legislative Development stages and goes straight into implementation.

Discreet, static knowledge assets produced at each stage are inconsistently shared between stages, use domain specific language and are created for a paper based world.

Policy intent is not always clearly defined and discoverable by service designers.

Few post- implementation feedback loops to inform improvements.

While there are opportunities to engage at each stage, the inconsistencies with how impacted people are involved results in a disjointed evidence base.

Impacted people and service designers are involved too little, too late.

There are few post-implementation feedback loops to inform improvements.

We explored the issues around the work of translating rules so they could be used by business systems to deliver services. It became apparent that all the different groups involved in the policy to service delivery process use a structured language, have standards and frameworks and use manuals and guidelines. However, the language and the tools and materials are unique to each of the different groups and are largely not shared. The different groups work more or less in silos. This means that each group next in the production and consumption chain has to translate the output from the previous step without full knowledge of that step, and without having had input into that step. The translation process is inefficient, opens up the process for errors and there is limited sharing of knowledge and experience across the groups (see the case study Exploring a cross agency eligibility engine). Inefficiencies are amplified as business systems with embedded, or hard coded, rules rely on being notified of upstream changes and must replicate the change process.

Because many different people are involved in the translation of rules from one information silo to the next, the time to implement a change becomes much longer. The work done in each silo is visible, but the information assets are not always known by the people and business systems that are impacted by the rule change.

See a larger version of the current state translation gap diagram (JPG 96KB)

Read detailed description of the diagram

There are three main groups involved in the policy production and consumption. Each uses domain specific structured language underpinnned by their own standards, frameworks, models, manuals and guides. Policy analysts and drafters write legislation, that is:
- Human readable documents & webpages
- Inconsistent definitions
- Hard to interpret & model
- Hard to detect changes
Rules analysts and lawyers translate legislation into rules speak. Legislation is interpreted according to organisational or personal priorities. Accountable only to their organisation.
Software developers translate rules speak into code Directions from the “business” is interpreted into programmatic terms for business systems.
Ultimately the business systems have the rules embedded within them.
When a policy change happens this change has to be translated by each group, so Change A becomes, Change A1, then Change A2, then Change A3 (within the business system).

Future state

We started with our future state in mind, which was to have human and machine consumable versions of rules for effective and efficient delivery of services

We defined the characteristics of this future state as:

We know what the rules are
- The current status of the rules is transparent
- Rules are easily accessible and understandable
- The rule set is responsive: it recognises change, can respond effectively and quickly to change, and can be iterated
The policy is effective
- The policy intent is transparent: people know it, can find it, and it is able to be clearly understood
- The policy intent can be given effect to consistently
- The models developed to create the rules can be reused: to contribute to modelling and measurement of the real impact of the policy/rules on people, economy and government
The process and outcome of rules development reflect the values of open and transparent government
- It provides certainty, clarity and consistency
- Diversity: rules are informed by diverse parties all along the journey
- Rules are just and a fair reflection of values and principles
- The rules and their development process is transparent and support accountability
- Reducing re-work/duplication
- The process has integrity
Efficient and effective implementation of policy and service delivery
- A clean set of rules based on an open standard consistently used across government
- The policy and rules are future proofed ie, they are technology agnostic and framed around the outcome sought, rather than the specifics of the process
- We remove the need for translation of the rule
- A relationship between policy, drafting, and implementation reduces rework and waste, and enables the policy intent to be realised
- Decision makers have better information
End users have a better experience
- End users can easily understand their rights and obligations
- The rules of any one piece of policy integrate with the digital ecosystem (better than now)
- People (end users, policy analysts, drafters, developers) have a better experience of using the rules
- It’s easier to develop tools that take a human-centred view
- End users make better decisions

We defined the users of these human and machine consumable rules as:

Direct consumers (impacted by the content of the rules)
- People (members of the public) and businesses who use the rules when:
  - finding out about their rights and obligations
  - checking the source of truth for the products, advice and services they use
  - consuming products and services that are driven by government rules (including artificial intelligence)
  - engaging with government policy change.
- Regulators (including government departments, judiciary, policy analysts, legislative drafters, select committees, Treasury, and international groups) who use the rules when:
  - monitoring compliance with the rules
  - understanding how the rules are being used
  - developing, testing and modelling changes to the rules, and validating the quality of this modelling.
Intermediaries (not directly impacted by the content of the rules)
- Advisory services (including lawyers, accountants, unions, advocates) who use the rules when:
  - developing meaningful guidance and advice for the application of the rules
- Government service designers and deliverers (including business architects) who use the rules when:
  - designing and delivering products and services from a single source of truth
- Entrepreneurs and social innovators (including civic tech) who use the rules when:
  - creating new products and services from a single source of truth
- Software developers (public and private sector) who use the rules when:
  - building products and services from a single source of truth
  - automating software updates to account for rule changes
- Computer systems (including artificial intelligence) who can use the rules to:
  - provide real-time feedback on use of rules, including edge cases.

Building backwards from our future state we mapped out the process we thought would be required to deliver it, including the activities, actors, capabilities and components required. This was a challenging activity that brought the team’s thinking together and revealed some key implications of a future state approach on the policy development and implementation system.

We concluded that the initial impact of policy intent can be delivered faster, and the ability to respond to change is greater, with:

Multidisciplinary teams that use open standards and frameworks, share and make openly available ‘living’ knowledge assets, and work early and meaningfully with impacted people.
The output is machine and human consumable rules that are consistent, traceable, have equivalent reliance and are easy to manage.
Early drafts of machine consumable rules can be used to do scenario and user testing for meaningful and early engagement with Ministers and impacted people or systems.
Use of machine consumable rules by automated systems can provide feedback into the policy development system for continuous improvement.

See a larger version of the future state diagram (JPG 163KB)

Read detailed description of the diagram

By taking a collaborative and co-design approach to the process we could achieve a shorter time to deliver impact and more opportunity to change direction based on evidence.

This would involve a multidisciplinary team (including policy, legislation, service design and delivery people) that works together iterating from initiation to service delivery using open standards and standardised frameworks.

Multidisciplinary team works meaningfully with impacted people to define the problem and co-design solutions.

Multidisciplinary team co-creates and iterates shared, living knowledge assets, rules, models and metrics and makes them all openly available for reuse by others.

The output would be machine and human consumable rules that are consistent, traceable, have equivalent reliance and are easy to manage.

This would enable early scenario and user testing using machine consumable rules provides evidence for implementation options.

And would enable continuous feedback from automated systems that use the machine consumable rules informs improvements to rules.

This system of policy development also interacts with other systems, for example measurement systems, political systems, government data and analytics, auditing and accountability systems.

We hypothesised that this future state approach would reduce or negate the translation gaps in policy production and consumption and lead to more timely and reliable delivery of the rules to humans and systems.

We envisaged that the policy analysts, legislative drafters, rules analysts, and developers would work a lot closer together and would require:

Multi-disciplinary (including multi-agency) teams that collaborate on a rule change through the entire process.
Standards (or principles) developed to support the policy development and drafting process should take into account the standards used in the downstream parts of the policy production process. For example standards used in the rules space should inform standards or principles for drafting when it is relevant, and vice versa.
Some of the frameworks and models would be adopted as a shared point of reference.
All groups would start using a common or shared repository or knowledge asset to capture (1) standards, frameworks, models, manuals and guides and (2) outputs from the policy production process.

This basis of consistency and automation would mean rule changes are reliably replicated in human readable form and within business systems.

See a larger verions of the future state translation gap diagram (JPG 96KB)

Read detailed description of the diagram

The future state approach would mean there was no translation gap in the policy production and consumption.

Drafters, rules analysts and developers would work together to write legislation, rules and code. Resulting in human and machine consumable rules that are be consistent, traceable, have equivalent reliance and are easy to manage.

The structured language of each group would be more consistent and underpinned by aligned standards, with some frameworks & models that are common and shared across the policy lifecycle, shared knowledge assets, i.e. manuals and guides, and artefacts related to policy lifecycle.

Human and machine consumable rules would be made publicly available via the web and as APIs. The rules would be human readable, so anyone can read and understand the rules and policy intent. The machine consumable rules would be used by business systems (with the rules drawn directly from government, embellished with business rules), and also made available for use by Artificial Intelligence.

Changes would be reliably replicated, so Change A would be the same Change A implemented into business systems.

(3) A Discovery Sprint is a necessarily constrained exploration of key ideas or concepts. The intent is to understand the problem and opportunity space without investing too much effort too soon.

To test out our ideas about the future state we broke into two teams, each seeking to understand the benefits and challenges of applying our future state to an existing piece of legislation that has known issues with its current implementation. Our intent was to use these Acts as instruments of exploration, not to suggest changes to this specific legislation.

We postulated that by using the identified future state processes and capabilities we could: help the delivery of the policy intent and create better outcomes for people create machine consumable rules to support service delivery.

One team looked at the Rates Rebate Act (administered by the Department of Internal Affairs), and referred to the previous work of the Rates Rebate Discovery within the Service Innovation Work Programme where the applicant, council and central government pain points were uncovered.

The other team used the Holidays Act (administered by the Ministry of Business, Innovation and Employment), and leveraged their knowledge of the implementation issues of this Act, particularly for providers of payroll systems.

Service delivery problems of the legislation

Rates Rebate Act

The Rates Rebate Act was first enacted in 1973 and was designed for a paper based world. While the policy intent is to lower the burden of home ownership for people on low incomes, the scheme is undersubscribed across New Zealand. The service delivery of the policy intent is complicated by prescribed interactions between ratepayers, local authorities, and central government. The complexity of the policy implementation is disproportionate to the benefit to any individual, i.e. the maximum rate rebate for any ratepayer is $620 per rating year.

A recent amendment to the Act added a further complicating factor by treating residents of retirement villages as though they were ratepayers, presumably because the same calculation is used to determined the amount of the rebate they are entitled to. However, residents of retirement villages interact with different people and provide different information.

Holidays Act

To keep the problem (reasonably) discrete the team looking at the Holidays Act chose to focus solely on the provision of the annual holidays entitlement. This centres on understanding an employee's entitlement balance, the proportion of the entitlement being taken as holidays, and determining how much they should be paid.

The policy intent is for employees to have a guaranteed and predictable 4 calendar weeks of paid leave each year. However, this fundamental unit of a ‘week’ causes problems if not clearly defined. Not all people work a standard, Monday to Friday 40 hour week, though this is assumed by the use of the term ‘week’ in the legislation. There are difficulties determining what an employee’s entitlement balance is, and what portion of the entitlement has been used when leave is requested, when the employee works a non-standard work pattern. This creates problems and uncertainty of employees, employers and in accounting and payroll software. There is a need for all parties to agree if it is not obvious, which imposes unrealistic obligations and compliance costs on employers.

Approach to experiments

Each team followed the approach the IR Business Rules team takes when mapping out rules by creating a concept model that describes the discrete concepts of the Act (or part thereof) and the relationships between the concepts, i.e. the concept of 'ratepayer' and its relationship with 'rates', or 'application'. Then we developed decision models where the eligibility or entitlement criteria are clearly mapped. The concept and decision models were iterated as the teams either refined the rules (in the case of the Holidays Act) or better understood the rules and their logic (in the case of the Rates Rebate Act).

Each team used the models they had created as a basis for common understanding and from which they could generate:

pseudocode, or rule statements that detail the logic of the rules in a human readable format
human readable legislation
software code.

The Rates Rebate team also used the decision model to generate a process flow, which communicates the priority or logical order of the questions and rules.

The Holidays Act team first worked with the current state concept and decision models. An insight generated from the recognition of potential links between these and other pieces of entitlement based legislation (in this case, Working For Families) – highlighting the advantages of a multidisciplinary group – suggested a way that the current concept and decision models could be reshaped and subsequent iterations evolved to include these new ideas.

As with the Rates Rebate team, the Holidays Act team then developed human readable legislation and software code based on these developments. However, because these were based on a speculative reshaping of annual holidays that were not fully explored (and because it was not in the team’s brief to be looking for new approaches to the Act), it is inappropriate to publish the drafting and code in this report.

Concept models

The concept model ties together all the key concepts and the relationships between them.

Rates Rebate concept model

See a larger version of the Rates Rebate concept model diagram (JPG 62KB)

Read detailed description of the diagram

The concept of 'Ratepayer' is related to the concepts of:

'Taxable income' by a relationship of 'Has'
'Dependant' by a relationship of 'cares for'
'Government' by a relationship of 'Applies to'
'Residential property' by a relationship of 'Owns'
'Retirement village' by a relationship of 'Lives in'
'Rates' by a relationship of 'Pays' 'Application' by a relationship of 'Makes'
'Rates subsidy' by a relationship of 'Eligible for'

Scope note: reference to "retirement village" applies from the Rates Rebate Amendment 2018

The concept of 'Government' is related to the concepts of:

'Local government'
'Central government'

The concept of "Application' is related to the concepts of:

'Rates subsidy' by the relationship of 'Is for'
'Approved witness' by the relationship 'Witnesses'

The concept of 'Rates subsidy' is related to the concept of 'Eligibility'

Paid annual leave concept model

See a larger version of this paid annual leave concept model diagram (JPG 626KB)

Read detailed description of the diagram

The concept of "Employer' is related to the concepts of:

'Employee' by the relationship of 'employs'
'Paid annual leave' by the relationship 'is liable for'
'Leave application' by the relationship 'approves'
'Pay' by the relationship 'is liable for'

The concept of 'Employs' is related to the concepts of

'Employment agreement', which has a relationship to the concept of 'paid annual leave' by the relationship of 'states entitlement to'

The concept of 'Employee' is related to the concepts:

'Pay' by the relationship of 'earns'
'Leave application' by the relationship 'submits'
'Leave' by the relationship 'applies for' 'Paid annual leave' by the relationships 'is entitled to' and 'accumulates'

An 'Employee' has a work pattern, annual leave balance, anniversary date, and length of service

The concept of "Paid annual leave' is related to the concepts of:

'Employee' by the relationship of 'employs'
'Paid annual leave' by the relationship 'is liable for'
'Leave application' by the relationship 'approves'
'Pay' by the relationship 'is liable for'

The concept of 'Labour inspector' is related to the concepts of 'paid annual leave' by the relationship of 'monitors fairness'

The concept of "Pay' is related to the concepts of:

'Paid annual leave' by the relationship of 'determines amount of'
'Average weekly earnings' (for 52 weeks) by the relationship 'type of pay'
'Gross earning' (for last 12 months) by the relationship 'type of pay'
'Ordinary weekly pay' by the relationship 'type of pay'

Decision models

The decision model looks at the key questions that need to be answered and looks at the ‘considerations’ associated with each question, i.e. all the things you need to know to be able to answer that question. It sets out the questions, but does not identify their relative timing or order.

Rates Rebate decision model

See a larger version of the Rates Rebate decision model diagram (JPG 115KB)

Read detailed description of the diagram

Scope notes:

excludes the 2018 amendment to include residents of retirement villages
all this applies to the circumstances as at the commencement of the rating year
for social security benefit: Superannuation is not a social security benefit defined under the Social Security Act 1964 and does not apply in this case.

The ultimate question to be answered is: What is the amount of rates subsidy a person is entitled to? To answer this the following questions need to be answered:

The pre-qualifying question is: Does the ratepayer qualify to receive a rates subsidy? This is answered by answering the following questions:
- Is the person a ratepayer?
- Is the property residential property? which is dependent on: Is the property the usual place of residence?
What is the amount of rates? which is dependent on: What is the amount of listed rates from the property?
What is the ratepayer’s income? Which is dependent on:
- What is the joint homeowner’s taxable income? Which is dependent on: Is there a joint homeowner ordinarily resident?
- What is the ratepayer’s taxable income?
- What is the spouse/partner’s taxable income? Which is dependent on: Is there a spouse/partner ordinarily resident?
What is the number of dependents the ratepayer has? Which is dependent on:
- What is the number of dependent children the ratepayer has? Which is determined by:
  - A dependant child is: Under 18, Unmarried etc., Ordinarily resident at the property, Whose care is primarily by the ratepayer, Maintained as a member of the family, Financially dependent on the ratepayer, Is not subject to payments under s 363 of the Oranga Tamariki Act (Child is in care/under guardianship/custody as determined by the CE of Oranga Tamariki)
- What is the number of dependant relatives the ratepayer has? A dependant relative is:
  - A person who receives a social security benefit under the Social Security Act 1964, Not a child, Not a spouse or partner, Ordinarily resident at the property, Relationships must be by: Blood, Marriage, Civil union, De facto, Adoption.

Paid annual leave decision model

See a larger version of this paid annual leave decision model diagram (JPG 34KB)

Read detailed description of the diagram

The ultimate question to be answered is: What is the amount paid out to an employee for the employee's approved portion of paid annual leave? To answer this the following questions need to be answered:

What portion of the employee's paid annual leave request has been approved by the employee's employer? which is dependent on:
- What is the employee's current accumulated paid annual leave balance?
What is the employee's ordinary weekly pay amount?

Paid annual leave rules statements

See a larger version of this paid annual leave rules statements diagram (JPG 1MB)

Read detailed description of the diagram

The questions in the decision model can be broken down further to explore their considerations and outcomes.

For the question: What is the amount paid out to an employee for the employee's approved portion of paid annual leave?

The considerations are:
- What portion of the employee's paid annual leave request has been approved by the employee's employer?
- What is the employee's ordinary weekly pays amount?
- What is the employee's average weekly earnings amount?
- There are no exceptions for this consideration
The outcome is:
- Amount paid for approved portion of paid annual leave

For the question: What portion of an employee's paid annual leave request has been approved by the employee's employer?

The considerations are:
- Employee's work pattern in days and hours
- Number of days and/or hours requested by the employee in the week they have chosen to take leave
- What is the employee's current accumulated paid annual leave balance?
- The related exception for this consideration is: The employee's work pattern is unpredictable
The outcome is:
- Number of days and/or hours approved for paid annual leave
- A question remains: Will there be a different or set outcome for the exceptional circumstances?

For the question: What is an employee's current accumulated paid annual leave balance?

The considerations are:
- Number of hours the employee has worked for the employer for the calendar year to date
- There are no exceptions for this consideration
The outcome is:
- Number of hours accumulated for paid annual leave

The concept and decision models were iterated as new understanding and possible new approaches or solutions to legislative problems were discussed. They were also used for sense checking by testing out use cases and scenarios.

Flow model

The flow diagram models decisions and actions taken over time, which inform the service delivery model and the sequencing of information to be gathered. It’s key features are that it does not contain the sort of detail that is contained in the decision model, and it maps the order (or timing, relative to each other) of events.

Rates Rebate flow model

See a larger version of the Rates Rebate flow model diagram (JPG 40KB)

Read detailed description of the diagram

Under the Rates Rebate Amendment 2018 there are now two process flows:

If a person is a resident of a retirement village:
- Determine if a person may apply for a rates subsidy for their retirement village contribution.
  - If no, then stop
  - If yes, then collect retirement subsidy information
- Then: Determine the amount of subsidy
If a person is a ratepayer of a property:
- Determine if a person may apply for a rates subsidy for their property
  - If no, then stop
  - If yes, then collect rates subsidy information, then determine the amount of subsidy.
- Then: Determine the amount of subsidy

Examples of legislation, pseudocode and software code

The Rates Rebate team chose the three most important sections from the Rates Rebate Act and used the concept, decision and flow models to co-develop legislative text, pseudocode and software code in parallel. These sections of the Rates Rebate Act demonstrate the kinds of definitions and calculations that are common in legislation and the problems that surface when we look at the service delivery model when comparing two different user groups.

Pseudocode is an accepted industry standard for communicating software requirements. It is a structured form of English organised in a way that makes implementing software easier. The pseudocode, legislative text, decision model and concept model provide all the pieces required for implementing digital services. If a software developer had not been part of the team, they would have been able to use these outputs to create software code without the need for translation.

We used a very simplistic software model of this as a proof of concept that co-creation of legislation in human and machine consumable formats is possible. The actual implementation happened in python using the jupyter notebook tool. The source code from our experiment is hosted on github under the MIT license.

Visit Github

We believe that co-creation of software and legislation is possible today, and with the addition of the right software tools, there is an opportunity to have an isomorphic output that can generate the knowledge assets which convey the policy intent and legislative meaning to all interested and affected parties.

Determining if a person is eligible for a rates subsidy

Legislation

A person is eligible for a rates subsidy if, on the relevant date:

the person is a ratepayer; and
the property for which the rates are paid is a residential property; and
the property is the usual place of residence of the ratepayer.

Pseudocode

(bold text denotes defined terms)

A person is eligible for a rates subsidy for a property only if all of the following is true at the relevant date:

The person is a ratepayer of the property.
The property is a residential property.
The property is the usual place of residence of the person.

Software code

is_eligible = False

if is_ratepayer and is_residential_property and usual_place_of_residence:

is_retirement_subsidy = False

is_eligible = True

Determining if a person is eligible for a retirement village subsidy

Legislation

A person is eligible for a retirement village subsidy if, on the relevant date, the person:

is a resident of a retirement village; and
has a residential unit in the retirement village that is not separately rated; and
contributes to the outgoings of the retirement village.

Pseudocode

(bold text denotes defined terms)

A person is eligible for a retirement village subsidy for a retirement village only if all of the following are true:

The person is a resident of the retirement village.
The person has a residential unit in the retirement village that is not separately rated.
The person ontributes to the outgoings of the retirement village.

Software code

has_residential_unit = False

if is_retirement_vilage_resident and has_residential_unit and contributes_to_outgoings_of_retirement_village:

is_eligible = True

is_retirement_subsidy = True

Calculation of a subsidy

(The formula used here is a simplified version of the real calculation)

Legislation

The amount of subsidy a person is entitled to is calculated in accordance with the following formula:

subsidy = income - base-rate / number of dependants x 10% x payment made

where:

base-rate means $15,000; and
dependants means:
- dependant children [see paragraph (a) of the definition of dependant in the Act]; and
- dependant relatives [see paragraph (b) of the definition of dependant in the Act]; and
income means:
- for a ratepayer, [see definition of income in the Act, and add section 4 to it]:
- for a resident of a retirement village, [see definition of income in the Act, and add section 7A(3) to it]; and
payment made means the amount of rates payable for the rating year.

Pseudocode

(italicised text denotes defined terms)

A subsidy equals (income - base-rate / number of dependants x 10% x payment made).

Base-rate equals $15,000.

A dependant is a person who is ordinarily resident at a ratepayer’s property on the relevant date and is a child who is under 18 years of age.

A dependant is a person who is ordinarily resident at a ratepayer’s property on the relevant date and is a person for whom all of the following is true:

The person is related to the ratepayer by blood or marriage.
The person receives a social security benefit under the Social Security Act 1964.
The person is not a child, spouse or partner of the ratepayer.

Income is defined in section 2(1) of the Rates Rebate Act 1973 for a ratepayer.

Income is defined in section 2(1) of the Rates Rebate Act 1973, but amended as set out in section 7A(3) of that Act for a resident of a retirement village.

Software code

base_rate = 15000

def rate_subsidy_calculation(household_income, dependants_number, rate):

# don't divide by 0

rate = max(1, rate)

dependants_number = max(1, dependants_number)

return (household_income - base_rate) / (dependants_number * 0.1 * rate)

All members of the team saw great value in the work we achieved in only 3 weeks. Some have changed the way they think about their job and plan to include new methods, or broader groups of people, in their day to day work. We valued the diversity of the team and learnt to trust in the service design approach and the discovery process, even though it meant there were times we had to work hard to understand each other and lacked clarity about the way forward.

The key lessons learned have been broken down into their component parts:

Process

Value of multidisciplinary teams and co-design

Multi-disciplinary teams (including multi-agency) speak quite different languages, but also bring a diverse range of ideas and perspectives to a problem. You can make good progress if you draw on the respective strengths of the different team members.
Increase mutual understanding and awareness of the impacts of policy decisions on service delivery and check that the service delivery model and the rules both match the policy intent.
- A small step toward this would be for policy teams to engage early with service delivery/operational teams when preparing for the legislative bid process, or for unscheduled changes to policy. This enables the service delivery model to be built in to the policy from the outset, and for the policy to change and adapt (if necessary) to accommodate it.
- Ensure that all parties have the necessary understanding of the needs and realities of impacted people and systems
  - The Accounting Income Method (AIM) case study showed that co-creating from the start with key implementers is hard work, but can deliver a much better and more sustainable outcome
  - Decisions that don’t seem to have much impact might in fact do so when looked at within the practical realities and complexities of service delivery, particularly when there are multiple organisations involved, like there are for the Rates Rebate Act.
Other agencies may have similar problems in quite a different context and approaches to those problems can be drawn on. For example, we drew on some of the issues around changing entitlements in the Working For Families tax credit scheme when thinking about the Holidays Act.
Empathy and understanding of what is involved in the work done by team members from diverse skill-sets and backgrounds.

Value of a people-centric approach

The way you phrase your questions can have a big influence on the answers you get. We could be more deliberate in the policy process about how we do this. Policy analysts tend to phrase questions in a neutral way, framed by the problem definition. It is important to think which framework/perspective you are asking the question from, e.g. frame the policy and the legislation so as to answer the question that the end-user is ultimately trying to answer. Ie, what are my rights, what do I have to do, what I am entitled to, and so on.

Value of a digital rules approach

Overall, the value of a digital rules approach to policy design is that it generates a core set of rules/definitions etc that can (a) be iteratively refined at each stage of the process, and (b) provides consistency across the whole process from policy design, through legislative design to service design, delivery and maintenance (i.e. covers the whole policy life cycle).
Rules don’t have to be simple, they just have to be programmable. There can be more “considerations” that give you a fairer result, but involve a more complex decision-model with more rules. This is not necessarily a problem, as machines can deal with more complex decision-models than humans, as long as the input data is available.
This approach could help with the structuring of legislation if some parts of are more suitable to be delivered as machine consumable (e.g. eligibility criteria, calculations).

Inputs

Value of common frameworks, reference and data points

A diverse group of people from diverse disciplines will have diverse understandings of problems, ideas and terms.
Developing the concept, decision and flow models creates a common reference point, but requires finding common language through understanding different points of view. It also helps with maintaining group focus on understanding the problem state before trying to find a solution.
Keeping a focus on figuring out the problem (and not jumping to solutions too early) can help flush-out the various facets of the issue. The more perspectives you can see a problem from, the better the solution will be.
To ensure line of sight to policy intent, we had to toggle between the models and the reality of service delivery. Iterating the concept and decision models helped with shared understanding across the team and increased awareness of the need to care about the people who design, deliver and use the resultant services.
A global (government wide) ontology that describes commonly used concepts, terms, their definitions and their relationships with other concepts would be a useful way of leveraging common data points and fast tracking the development of concept and decision models. For example, a commonly used definition for the concept 'child' could be: a person who is under 18 years of age. There might need to be local modifications of this concept for specific pieces of legislation.
- Definitions need to be granular enough to be meaningful without having to always create a new definition. Definitions would form the basis of the ontology, which would be used as the source for terms and their reuse across the legislative body.
- Ideally you would be able to aggregate definitions and obligations for the particular circumstances you are interested in. Having legislation in a digitally consumable format would allow users to aggregate answers to their specific questions.
All of these knowledge assets (models and a global ontology) need to be underpinned by principles, standards and guidance if they are to be consistently used across government. They also need to be managed as system assets, rather than the sole responsibility of each agency.

Outputs

Value of multidisciplinary co-design to produce outputs

By using the common reference points (concept, decision and flow models) and developing the human readable legislation, pseudocode and software code in unison we ensured they were in alignment, eliminating translation errors and quickly identifying omissions and gaps.
- This method can be applied now without the need for specific technology solutions.
- To enable greater flexibility for rules delivery and use standards for developing code should be independent of specific technology solutions.

Value of machine consumable legislation

Making legislation or business rules machine consumable at the creation of rulesets would enable:
- enable faster implementation of policy
- enable policies to be modelled through scenario and user testing before they are implemented
- remove the "translation gap" that currently exists between policy and legislative intent, and the software that is developed to support service delivery
- lead to greater innovation and service integration as it would make machine consumable versions of legislation openly available for public use
- focus attention on the need for policy and legislation to be developed with knowledge of the service delivery method and through multi-disciplinary teams, and the value of common data points across government
- programmatic subscription to rule changes so software systems can be automatically notified.
Sometimes the calculations determined for subsidies are highly complex to reflect the complexity of differing costs of living and circumstances. The power of digital legislation is not to simplify and thus remove this nuanced response to complexity, but rather to clarify, and make the implementation more streamlined and consistent. It also enables a more agile approach to modelling, or testing and iteration.
Machine consumable legislation may support advanced querying of the rules. For example questions like “show me the 10 most complicated acts” or “show me all entitlements that may apply to me if I was born before 1985”.

Parts of legislation suitable to be machine consumable

We consider that incorporating a digital rules approach in multi-disciplinary teams using user-centred service design methods, as both teams did, will benefit most scenarios because it will enable better services and outcomes. However, not all legislation need be made available in a machine consumable format. Some legislation has a one-off consequence that is delivered by the legislation itself. For example, the establishment of a statutory entity. There would be no value in making legislation of this nature machine consumable.

There are also different drivers for making various types of legislation machine consumable. For example, one Part of an Act might set out eligibility and calculations. The value in making that Part machine consumable is that it can be integrated into service delivery systems so as to enable eligibility to be determined and calculations to be made.

Another Part of that Act might set out how a payment is authorised and paid for by an agency. The value in making that Part machine consumable is that it enables processes to be recorded, integrated and confirmed. For example, if 5 things need to occur before a payment can be authorised, that list can be integrated into the business systems of the agency to ensure that the agency knows what it must do, complies, and collects evidence that it has complied.

The features of legislation that we identified that are likely to mean that it would be of value to make it available in a machine consumable format are, if the legislation:

involves a calculation
involves a process that requires factual information to determine application, eligibility, entitlements, or coverage
prescribes a process that is used repeatedly
prescribes a compliance process or obligation (for example, regulations that set out 14 different steps that must take place before raw milk can be certified as being fit for human consumption)
prescribes a process or system that can be delivered digitally.

Considerations for legislative drafting

Considerations for legislative drafting potentially include:

ensuring the content of legislation enables the digital delivery of services, including:
- (as far as possible), specify “what” outcome is sought, not “how” to achieve it (leave that to administrative processes, or secondary legislation if need be)
- avoid prescriptive procedural processes that are out of kilter with the benefit sought or the practicalities of the service delivery method (see, for example, the differences between the requirements of the Rates Rebate Act and DIA’s application form)
- avoid requiring a person to do or obtain something in person (like signing a document in front of someone) whenever possible
- separate the process and the information sought, from the obligation to do it, so as to enable:
  - the pro-active delivery of services by government to people
  - the delivery of services by technology (for example, personalised robo-advice services under the Financial Advisers Act)
  - policy approaches to digital services, such as verifiable claims(4), and “we will ask only once”
- be technology agnostic and avoid specifying means of communication (for example, “in-writing”, a fax, emails, websites, and so on). If this is unavoidable, do so in secondary legislation
- recognise the difference between legal conditions (ie, reasonableness) and factual conditions (ie, age, gender), and the problems that can cause for provability and certainty
- avoid prescribing forms or formats.
reflect and enable the service delivery methods that will be used, including:
- the different entities that a user interfaces with, and the different ways in which those interfaces may occur (for example, the Rates Rebate Act was originally developed from a singular ratepayer perspective. Additional applicants have been added by treating ratepayers and residents of retirement villages the same. But the former interacts with local authorities, and the latter with retirement village owners, and they each provide different information)
- recognising the differing purposes of each step in a process (for example, the Rates Rebate Act merges eligibility criteria with the calculation process. The result is that every ratepayer is eligible for a rates rebate, but for most of them, their rebate entitlement will be nil)
user-centred design, involving framing legislation around:
- the end user (human or software system), the questions they are seeking to answer, and the way in which they will interact with the rules that concern them
- life events and business life cycles
- the roles of different users (for example, provisions that concern a person’s eligibility for an entitlement, versus provisions that set out the process and compliance procedures an agency must follow)
grouping legislative provisions that will be made machine consumable together (for clarity and ease of consumption)
structuring legislative provisions to mirror the way they will be coded into software, including:
- reflect decision and flow models in the ordering of, and connections between, clauses
- set out obligations in hierarchical order
- put non-binary elements as low down the decision model as possible (so that uncertain elements do not create prior uncertainty for subsequent certain elements)
- consider placing the most exclusive element first to narrow the application as much as possible from the outset (for example, in the definition of dependent relative in the Rates Rebate Act, the first element listed should be that it is a person who is receiving a social security benefit under the Social Security Act 1964)
each definition is a data point, and so:
- do not put obligations in definitions
- avoid nested definitions as much as possible
consider presenting information in non-English formats if that would be equally clear and simple for human consumption (for example, enact parts of decision models, or algorithms).

(4) Verifiable claims are where a pre-defined query is asked rather than sharing (often personal) information, such as proof of age or an income means test. See more at https://www.w3.org/TR/verifiable-claims-use-cases/

Making government rules machine consumable so they can be integrated directly into service delivery systems is fast becoming a key component in the digital transformation of governments, particularly as we seek to automate information exchange and some decision making while ensuring government transparency and accountability. This 3 week discovery was the first step on our journey to understand the opportunities and challenges, and where to direct our efforts.

Key findings

It is difficult to produce machine consumable rules if the policy and legislation has not been developed with this output in mind.
An effective way of developing such policy and legislation is for multidisciplinary teams of policy analysts, legislative drafters, service designers and software developers to co-design the policy and legislation, taking a user-centric approach that focuses on how the service could most effectively be delivered. In this case ‘user’ can mean people and technology systems as the end users of machine consumable rules.
Co-designing rules with policy and service design increases the chances of the policy being implemented effectively and as intended, and can reduce the time it takes to deliver on the policy intent.
Machine consumable legislation that is co-developed:
- enables legislation, business rules, and service delivery software to be developed in parallel, ensuring consistency of application, and significantly speeding up the service delivery to people
- increases the opportunities to automate and integrate service delivery (including through the use of artificial intelligence).
Common frameworks, reference points and data points (like concept and decision models and ontologies(5)) will assist multi-disciplinary teams to co-design policy and legislation and, once developed, can be used as blueprints for the development of human and machine consumable rules without the need for further translation of the intent and logic (which, in turn, reduces the time and resources required and the chances of errors).
Not all legislation is suitable for machine consumption, but a multi-disciplinary approach will assist in making better rules.

We did not have time to test the following hypotheses:

that draft machine consumable rules could be used for early stage scenario and user testing through a simple user interface
that continuous feedback from automated systems that use the machine consumable rules could inform improvements to the rules.

There are things we can do right now that do not require specific technology solutions to produce legislation in machine consumable format. By working in a multi-disciplinary way and including the service delivery model from the outset, we were able to produce a decision model that formed a common understanding and acted as a common blueprint, from which the legislation, pseudocode, and software could all be drafted using our usual processes and tools.

While we haven’t yet investigated all aspects of the model, we believe that the following proposed approach could support:

faster and better delivery of policy intent
services that are designed to be delivered in the most effective and user-centered manner
modelling of outcomes
digital transformation of government
support legislative reform
accountability of public and private measures.

See a larger version of the future approach diagram (PDF 188KB)

Read detailed description of the diagram

A new approach to policy and legislative development results in agreed, clearly defined and communicated policy intent.

By combing:

Multidisciplinary team co-designs
Understanding the needs of impacted people and systems

That deliver a concept model, which takes and contributes concepts from a global ontology (Concepts with terms, and definitions and described relationships with other concepts, e.g. the relationship between the concepts ‘parent’ and ‘child’)

This is iterated with the development of commonly understood models used as the basis for human and machine readable rules. Delivering:

Decision model
Process flow

This is iterated with the development of human and machine consumable rules that are consistent, traceable, have equivalent reliance and are easy to manage.

Which is underpinned by principles, standards and guidance that enable consistency and interoperability

To deliver:

Human readable rules, where appropriate, definitions are taken from (e.g. 'Child') or added to (e.g. 'Ratepayer') global ontology, or created specifically for this Act only (e.g. 'Relevant date')
Pseudocode version of the rules, which only includes definitions necessary for decisions
Machine consumable rules, which references definitions from pseudocode

The Machine consumable rules can then be used for scenario and user testing using machine consumable rules provides evidence for implementation options, through a simple digital interface that enables people to interact with draft rules to test out scenarios and consider trade-offs

This evidence can then be used to inform the next iteration of the rules

(5) In this context we define ‘ontology’ as a set of terms or concepts, their definitions and their relationships with other concepts. This can be a thought of as a non-hierarchical categorisation of concepts that conveys more meaning than just the definition of terms.

Tackled collectively, there are opportunities for the government to save time, effort and money, and avoid future IT and legislative problems that are costly and hard to change.

Opportunities we have right now

Socialise the findings of this work as widely as possible, including with international partners
Collaboration across the New Zealand government:
- identify legislative barriers to data and digital transformation to inform the development of standard clauses, drafting guidance materials, and potential future amendments (working with PCO, DPMC Policy Project, and Stats NZ)
- look for other opportunities to road test this approach in a real world piece of legislation
- develop the suggested approach in this report further and integrate across the 7 Regulatory Stewardship Strategies (working with Treasury and responsible agencies)
- promote this approach across the policy community and its integration into agency policy methods (working with the Policy Project)
- develop standards for developing digital rules and outputs (work with MBIE’s Better for Business Programme)
- explore how artificial intelligence might use digital rules (work with the AI Forum)
- explore opportunities with the Government Rules Group.
Collaboration with Digital 7 and other nations:
- develop standards and frameworks for development and delivery of human and machine consumable rules
- exploration of open source tools that can be shared.

Areas to investigate further

The general applicability of this approach.
- Would the same process run with different types of people get a similar outcome, but with different artefacts?
- What stage in the policy and legislative development lifecycle is this approach most valuable?
- How would this approach be integrated into the current policy and legislative approval process?
How to create, manage and interlink cross system knowledge assets (like concept and decision models)
What is the best method of producing machine consumable rules? This may depend on the answers to question 4 (what is made publicly available)? Options include:
- Parallel production of rules using existing systems
  - Multidisciplinary team uses the concept, decision and flow models to draft the legislation, pseudocode, and software code in parallel
- Standardised outputs of machine consumable rules using a range of products
  - Rules created using the openly available concept, decision and flow models, but all outputting as open data in a standard format to enable reuse and integration
Which knowledge assets should be made publicly available, enacted or otherwise provided as authoritative sources? Options include:
- Human consumable rules only
  - which would result in siloed logic as we have now, and would not enable digital use of the rules from an authoritative source
- Human consumable rules concept, decision and flow models (or pseudocode)
  - which would help people to understand the logic, but would not enable digital use of the rules from an authoritative source
- Human and machine consumable rules
  - enables digital use of the rules from an authoritative single source
  - provides the opportunity to have semantic linking across all legislation, which would:
    - enable querying across all rules to find the aspects of rules relevant to a particular scenario, e.g. becoming a parent
    - expose the complexity, enabling better management of legislation through an accessible evidence base that shows how consistently, or inconsistently the terms or concepts are being used.
Principles for legislative drafting to better enable digital service delivery and be fit for machine consumption. We uncovered some potential principles in this discovery, but further investigation and experimentation with the method we developed would likely uncover further useful principles.
How to incorporate automated feedback loops (e.g. all of government service analytics), into the policy development lifecycle.
Challenges and opportunities of having a global (government wide) ontology to describe commonly used concepts, terms, their definitions and their relationships with other concepts.
- For example, it could help multidisciplinary teams come to common understandings faster through reusing common, defined concepts, but it would need to allow for some flexibility in the way terms can be used.
- It could enable the semantic linking of conceptual models across rule sets, enabling better rule management across government.
- It could be challenging to come to consensus on what terms should be included, what their definitions should be, and to manage the growing complexity across government, particularly as we currently use terms in different ways across different domains. How would we identify and manage complexity?
What standards should we be using/applying to the use of language, code, ontologies to ensure the delivery of unambiguous and interoperable machine consumable rules? To find the right frameworks/standards will require:
- Research i.e. what are other countries using or looking into
- Experimentation
Could draft machine consumable rules be used for early stage scenario and user testing? Would this add value into the policy and legislative development processes, particularly through a better understanding of the impact on people and systems and the most effective service delivery model?

Case studies: lessons learned in applying government rules for delivery

This is a short overview of six case studies in applying the rules of government in real life. For each we captured the context of the example, the lessons learned, and the core components identified as necessary for applying the rules in a consistent way for consideration in developing a future state.

These case studies were drafted in February 2018.

Eliciting business rules from legislation and policy for business use

Author: Business Rules Team, Inland Revenue

The Business Rules Centre (BRC) was established at Inland Revenue (IR) to enable IR and its customers to make consistently accurate decisions that are compliant with legislation and policies.

Why we do what we do

Any system is only as good as the information that goes into it. Decisions can be inconsistent or inaccurate, not because they cannot be made accurately, but because the information needed to do so is unstructured and dispersed. Here at the BRC we employ some standardised Business Techniques/Methods that allow us to be able to structure information in a consistent format. It helps us to bring together legislation and the business’s interpretation of it (business knowledge) in the form of rule statements that present the law in a logical way making them easier and quicker to apply.

See large version of diagram (JPG 46KB)

Read detailed description of the diagram

All businesses are governed by rules that are influenced by:

Internal analysis and advice
Contracts Internal policies and processes
Undocumented knowledge
Legislation and policy
Published statements
Social and cultural norms

The BRC (Business Rules Centre) elicits rules from many sources and brings them together into one place, delivering explicit, documented, and validated rules that can be easily updated and reused in a wide variety of systems and tools.

The approach

A business rule is a statement that defines or constrains some aspect of business:

Definition rules - classify or compute something using known facts.
Constraining rules - a business rule whose purpose is to shape (govern) day-to-day business activity and prevent undesirable situations that could occur at any point in time. It is a rule that can be violated directly because there is an obligation concerning conduct, action, practice, or procedure.

So when structuring the information we capture the ‘what’, ‘how’, ‘where’, ‘who’ and ‘when’ of doing business into these simple logical rule statements.

To arrive at these business rules, the first thing we do is to understand the Business Architecture for the area of business in question. To help us do this we develop a concept model which shows the key concepts at play and the relationships between them. This is a thinking tool that helps us capture the current state of the business strategy, policy settings, etc in effect and provides a basis for envisioning the opportunities available for future states.

Example of a Concept Model

See a larger version of this example concept model diagram (JPG 834KB)

Read detailed description of the diagram

This example of a concept model shows the relationships between concepts, e.g.:

the concept of 'Person' relates to the concept 'Penalty' through the relationship 'liable to pay'.
the concept 'Tax residency status' relates to the concept 'Person' through the relationship 'is assigned to'

Then we create a structured business vocabulary in line with the concept model. The definitions are agreed to upfront so everyone is on the same page from square one. Using this structured business vocabulary mitigates the risk of misinterpretation of rules later on. We then use these terms, and their definitions throughout our analysis.

Next is decision modelling. Every operational business decision will have business rules guiding it. We align these rules with the decision so that consistent logical decision making is possible. The artefacts we produce are:

Question charts – these are visualisations of decision structures, showing the questions that need to be answered and also any dependencies between each question.
Q-COEs – these add the next level of detail for each Question in the decision structure. They state the facts (Considerations) that need to be obtained to arrive at an optimal answer (Outcomes) for the question and identify any Exceptions that may apply for the given question.

Example of a Decision Model

See a larger version of this example decision model diagram (JPG 1MB)

Read detailed description of the diagram

This example of a decision model shows the dependent questions for the ultimate question of: What is an employer's PAYE obligation amount for an employee? These dependent questions include:

What is the employee's PAYE deduction rate?
What is the employee's student loan deduction rate?
What is the employee's rate of Kiwisaver deduction?

The diagram also shows some of the considerations and outcomes of questions, e.g. for the question What is the employee's rate of Kiwisaver deduction?

the considerations are:
- Is the employee on a Kiwisaver contributions holiday?
- What Kiwisaver rate has the employee elected?
the outcome is a percentage

Once we have a list of agreed terms and understanding of how the given area of the business operates, we are then ready to form business rule statements. These statements reduce ambiguity and are presented in structured English that is readily understood by the business.

As the logic contained in the rules is used to structure the decisions, accurate decisions are made and, wherever reused, the application of the decision will be consistent. This is how we achieve consistently accurate decisions.

We arrive at this outcome by understanding the business language and knowledge in order to structure this logic into practicable business rules.

We maintain the artefacts (models and rules) produced with a proper source of traceability, legal/business sign-off and other relevant metadata. We use them as living knowledge assets that we reference and reuse as starting points for future changes.

Lessons learned

The business rules approach brings together and retains understanding of how legislation and policies work. Once this is done and there is access to this knowledge then it improves the consistency of technical decision making.
The business rules also allow the staff of the business to apply legislation more efficiently as some of the interpretation is already done.

To apply the approach there needs to be:

An appetite for learning
A culture of trying new things to overcome the challenges

Common or core capabilities identified

The BRC has a cross-disciplinary team, ranging from lawyers, accountants, business analysts, business designers and customer representatives. The key thing we’ve focused on in building the team is having people with very strong analytical capabilities.
Standards and Frameworks:
- Business Rules Analysis Framework (PDF, 108KB) (or see the text only version)
- Decision Analysis Framework (PDF, 107KB) (or see the text only version)
Agile working methodology:
- Working in Sprints, having daily stand ups and retrospectives at end of sprints
- Team involvement in the whole end-to-end process
- Team owning the delivery as a team not individuals
- Team feeling empowered to make changes and challenge current states
- Team having constant opportunities for continuous improvement
- Team thinking of how we can deliver value to the organisation better
- Team making decisions on their work
- Focus on providing quality output that is relevant to the specific customer
Digital awareness
Digital workflow management to overcome challenge of not being co-located

Statute as code

Author: Adrian Kelly, Legislative Drafter, Inland Revenue (IR)

Introduction

My project set out to model a statute in computer code, using first order logic and maintaining legal sense.

Here is a working model, with a ‘draft preliminary paper’: smartstatute.net

A more complete paper, and source code, etc is available on request.

The approach

I approached the problem using C/C++ functional style programming. This worked well initially, with data structures containing functional logic calling other data structures (also containing logic), the return of which triggered more functional logic! C/C++ functional style programming is not very easy (for me, anyway).

Once I thought about user functionality, I realised Javascript was better suited. The approach of functional logic as data is more easily implemented in Javascript modules, I found, running on a node.js server. The way I did it was to have a stack of Javascript objects filled with logic as data. It was much easier to use than the initial C/C++ call and return system I came up with.

Lessons learned

There is a lot of work in analysing legislation to cleanly extract all of its first order logic, and to preserve, in the data points, the legal sense of a statute. That is the biggest lesson.

Secondly, don’t even think about a simple client/server web-based user experience using C/C++.

Also, maybe it was just me, but I found functional style programming in Javascript a lot easier than C/C++. Objects in Javascript are really easy to work with, and functional logic as data seems a lot easier to me in Javascript.

Common or core capabilities identified

Legal analysis, being a legally correct ‘map’ of the statute, is the first step. Then, translation into a standardised rights/obligation framework of subject/predicate-object-action/condition.

Legal analysis and translation into a standardised framework both inform a decision tree model, with conditions as data-points further broken down as required.

This is further translated into / mined for formal first order logic and then finally translated into Javascript source code.

A high level diagrammatic representation of this, in the context of a policy drafting assignment might be:

What this diagram does not directly illustrate is the preservation of legal sense as between the Javascript source code and the English statute. The complex transformation process briefly outlined above is hidden by the diagram, but it is through that process that verification of “legal sense preservation” as between code and statute can be achieved.

How much of the complex transformation process can be automated is a very interesting question and the subject of ongoing research.

Exploring a cross agency eligibility engine

Author: Pia Andrews, Service Innovation team, DIA

The Service Innovation team at Department of Internal Affairs (DIA) experimented in mid 2017 with understanding user needs across a life event independently of an agency or sector lens. The results of this user research resulted in identifying three future state modes of service delivery that users prefer for interacting with government at different times. One of these modes of delivery was called “Help me plan” which involved a cross government view of services, benefits and tax credits to help people plan their life and understand what government provides which might be relevant to them. A mockup service was created in a few weeks and tested with users with promising results.

One of the key outcomes of the work was interest from multiple agencies to have a “help me plan” style functionality. We agreed to work with the DIA SmartStart team to build a proof of concept “eligibility engine” which was limited in scope to the benefits and tax credits related to the life event of “having a child”, which is only about 18 benefits across two agencies (Ministry of Social Development (MSD) and Inland Revenue (IR)), with whom we engaged to find out how their rules engines work internally, whether anything was publicly available to reuse (no), and we continue to collaborate with to validate and test our experimental application of the rules for eligibility. The hypothesis was that if the “rules” (or at least a majority) of eligibility were mostly found in legislation, then legislation as machine readable code would provide clearer, more integratable across agencies, more consistent application of the rules for service delivery, which then also enables many pathways into the same answers (in govt and from outside govt). At the same time, we could provide something of actual value to real people by testing the concept with SmartStart users.

The approach

Because we wanted to both create something of value to end users, and test our hypothesis of machine consumable rules providing value to service delivery. As such, we worked with the SmartStart team and used the user research to identify the shortlist of benefits and tax credits to include in the prototype. We then took a first pass of reading the legislation and trying to encode what was encodable (prescriptive logic a machine can understand, leaving human interpretive rules articulated more in definitions and user support text). We tried to take a user centric approach to how we described the rules, rather than making the rules product centric. The second pass was to look at the rules for the benefits on the relevant websites, so identify any gaps. We found for many benefits around 80-90% of the rules appeared to derive directly from legislation, but some of the rules on the websites was not explicitly in the legislation, so we coded what was codable and inferred these rules are derived from agency policies. There ends up being three key parts to our eligibility engine:

The conditions of eligibility - basically all the eligibility conditions captured in a usefully machine readable way. Many were boolean questions, but also numeric (for conditions like age) and interrelations between conditions (if eligible for a, not eligible for b). We used an experimental tool which outputs a JSON API and file that we can use independently of the tool we experimented with.
The business/user logic - the actual questions and how conditions were answered was captured in the service itself, in our case, SmartStart.
The benefit metadata - the descriptive information about the benefits which we extracted from the relevant websites, including URLs to direct users to more authoritative information about benefits, and how they would go about applying.

Once we had a second pass, we threw use cases at the rules to see if we roughly got what we expected. We built a first draft business logic for questions to ask users that would most rapidly get them an answer for benefits they were definitely eligible for, definitely not eligible for, and any ambiguous benefits. This logic and indeed the rules themselves had to be iterated several times through testing with users, with business analysts, with MSD and IR and the service designers. We had developers (in our team and in the contracting company), BAs, helpdesk and testers, UX and user research folk involved from SmartStart (DIA), Catalyst and the Service Innovation Lab (DIA). The first version of this went live in early March 2018:

https://smartstart.services.govt.nz/financial-help

Lessons learned

Common variables (attributes, definitions of conditions) for eligibility across all legislation would be really helpful. For simple things like Age having common brackets would be useful. For less simple things like Income, it’d be great to have common definitions rather than the one term having so many different definitions depending on the legislation (income for some benefits included child support payments, but not others, as one small example we found). Definitions like “single” are also tricky because the definition used in MSD of “financial, emotional and physical support” is still not clear for single people who are dating for instance.

Other lessons include the need to improve traceability of decision making or authority (legislation, policy, elsewhere).

Common or core capabilities identified

Common variables, terms (including ones that can be rolled up into aggregate definitions).
A catalogue approach including benefits or categories of types of rules.
Success criteria and original policy intent of benefits/entitlements so we ensure we build that into the design and delivery.
We propose that a starting point for legislation that lends itself nicely to programmatic code would include: benefits/entitlements/services (eligibility, calculations, rates, exclusions, definitions, interdependencies); compliance activities (obligations, conditions, triggers for action), functions/delegations of authority of agencies/Ministers/CEs. Plus semantic linking of definitions, names, benefits/obligations and other things that need referring across systems.

Private sector implementation of the utilities act

Author: Ersin Buckley, Media Suite

After the 2011 earthquake, Christchurch City Council and the New Zealand Transport Agency (NZTA) urgently needed a system for controlling access to the road corridors. TMP for Christchurch (TMPforchch.co.nz) was implemented and delivered into production to solve their urgent demand. Media Suite saw the success of TMP for Christchurch and decided that this was a project that could be brought to all road controlling authorities in NZ. In 2016 when we began a generalized implementation of TMPforCHCH called MyWorksites. MyWorksites is currently being used by Auckland Transport, Auckland Motorways, NZTA and Christchurch City Council. A wider national roll out is currently being planned.

The approach

MyWorksites is a product that is steered by a cross functional group involving LINZ, NZTA, Media Suite and various Road Controlling Authorities (RCAs = councils) that are participating or onboarding with the product.

By bringing this group of agencies together and involving them in the design process, we found that there is important knowledge sharing that happens. This highlighted particular differences in the processes used between the RCAs. Additionally, when a new feature is developed, design input is taken from the entire group ensuring it can be made available to all parties involved in the product.

MyWorksites is a complex system being used in production right now. We can take you through how it works if you email us at studio@mediasuite.co.nz

Lessons learned

A steering committee enables improved decision making for RCAs by providing visibility into the various implementations of this service.
A common data model for corridor access provides an opportunity for improved reporting and intelligence.
A shared product and pooled budget allows everyone to benefit from improvements.
Product champions within RCA’s (operational level) have been easy find as they are directly impacted by the solution. Product champions within central government have been harder to identify because the benefits to them are less tangible.
Co-design of a product does not mean a common process for all customers.

Common or core capabilities identified

The most important capability is an openness to sharing and learning from peers, a steering committee helped greatly with this.

Central government and local government organizations should be co-designing solutions.

Private sector building on the Resource Management Act (RMA)

Author: Ersin Buckley, Media Suite

The resource consent system is a collaboration between the Marlborough district council, Ministry for Environment and Media Suite. It is an effort to close the loop on policy objectives and environmental outcomes administered through the Resource Management Act (RMA) and District Plans.

The RMA is a complex piece of legislation. In practice this has resulted in the necessity of people engaging with specialists in the RMA and District Plans.

Using technology we can alleviate or remove the burden of people engaging with specialist agents. People will be empowered to complete their own resource consent agent with the guidance of artificial intelligent agents.

The public will be more informed about the impact that changes in the RMA or district plan have on them. As a result, we believe the public will have better information to provide feedback during the public notification and public consultation process.

At the central government level, better measurement of policy objectives will be achieved. A key opportunity is the ability to report on the impact specific clauses have on the environment.

Improved decision making will be enabled for resource consent officers and court hearings. Artificial intelligence, better data access and a flexible reporting system support this on a technical level.

Common or core capabilities identified

A common digital language for representing district plan and RMA rules.
A standard for environmental data which can be applied to the RMA rules.

Lessons learned

Managing changes in rules and legislation. Supporting concurrent implementations of different rule-sets.
Understanding the interaction and hierarchy of sets of rules is challenging in this space.

This project is currently in development, a demo is available if you contact studio@mediasuite.co.nz

Accounting Income Method (AIM)

Author: Penny Cooper, Service Design Lead, Inland Revenue (IR)

AIM is a project that makes it easier for businesses to pay provisional tax.

Over the last 18 months, we have worked with a very wide group of parties to develop policy, legislation and software to develop a world-first solution for business owners.

The approach - how can you innovate in a complex, rule-focused environment?

We have developed pragmatic approach based on the following principles:

Customer proximity. Recognise who is closest to the end user. Software developers are the delivery solution and are closer to the customer base than IR. This meant we could partner with the private sector to provide innovative outcomes as AIM uses new functionality included in accounting software.
Timelines that work for all. We had be very cognisant of private sector resource constraints and time expectations (which are not aligned to government).
Relentless focus on defining success. At the start of the project we put a lot of time into defining “what success would look like”. This is more energising for people than a focus on problem definition.
Involve users early and often. We involved software developers early and often in co-design. This resulted in building a common understanding throughout the project. It was particularly helpful during the consultation and legislative phases where we shared draft discussion documents and legislation early, resulting in supportive submissions.
Form a dynamic & diverse team. Early on in the process we set up a multi-disciplinary team (included policy, service design, software developers, subject experts (within IR), service delivery, drafters etc. It is important to refresh membership and get the right expertise as project progresses (i.e. testing resources drop away when appropriate and marketing/communication expertise joins the team).
Cultivate an ‘external brain’ - we built a community of practitioners from across industry and government that we used to quickly test ideas. This ranged from 1:1 phone calls to groups of 3-5.
Invite challenge. We tried to create an environment that allowed software developers to challenge from the beginning because they know their customers and acknowledge that developers operate in a competitive market and must deliver for their customers.
Progress over perfection. In many instances, close enough is good enough and it was important to accept variances! Iterative design involved testing ideas and refining these quickly.
Give industry room to move. It was important to not restrict software through traditional prescriptive drafting techniques because their environment is constantly changing. We achieved this by using determinations (a more flexible legal instrument) and also legislating for outcomes not process. This helped to build trust with software developers by consulting, sharing and actively seeking views/opinions - this included transparency with software developer on what was not agreed on.
Constant communication. We aimed to develop a constant flow of information to the accounting industry, using existing channels and events wherever possible. Through the use of webinars we were able to engage directly with 10,000 accountants and small business owners over a 3 month period.

JavaScript is currently turned off in your browser — this means you cannot submit the feedback form. It's easy to turn on JavaScript — Learn how to turn on JavaScript in your web browser.

If you're unable to turn on JavaScript — email your feedback to govt.nz@dia.govt.nz .

Was this page helpful?

Yes No Partly

Thanks, do you want to tell us more?

Do not enter personal information. All fields are optional.

What did you come here to do?

How can we improve this information?

Last updated 08 February 2022