A housing-benefit applicant enters the same income, rent and family details into two government calculators. One says the household qualifies; the other says it does not. A caseworker later finds that one system uses the amended income threshold while the other still applies last year’s figure. The law did not issue two answers. Its software translations did.
This is the strongest case for rules as code: public rules are already being converted into software, usually many times and often behind closed doors. A shared, testable model could expose those translations and reduce preventable inconsistency. But the model should be a traceable companion to law, not a hidden executable substitute for it. Code can calculate a threshold; it cannot silently decide what “reasonable hardship” means, which evidence deserves weight, or when lawful discretion should be exercised.
The translation that already governs
Legislatures enact text. Departments produce guidance. Policy specialists explain the intended operation. Business analysts turn that explanation into decision tables. Developers implement conditions, calculations and data fields. Vendors may then reproduce the same interpretation in separate products. By the time a person receives an answer, the operative rule may sit several translations away from the authoritative source.
That chain is not inherently illegitimate. General language must be applied to specific circumstances, and service systems need precise instructions. The problem is that translation choices can become invisible. A programmer must decide whether a deadline is inclusive, which date controls a person’s age, how income is rounded, what happens when information is missing, and whether two conditions are alternatives or cumulative. Each choice may be small; together they determine who is paid, licensed, taxed or refused.
The OECD’s 2020 working paper Cracking the Code described rules as code as the creation of an official, machine-consumable version of rules that could be used consistently by computer systems. The report was an analytical working paper, not proof that an authoritative executable statute had become routine government practice. Its enduring contribution is to shift attention from the final application to the rulemaking process that feeds it.
The proposal is therefore not simply “publish the algorithm”. It is to create a common intermediate representation between legal text and service software: concepts, definitions, decision logic, parameters, provenance and examples that legal drafters, policy officials, service designers and developers can inspect together. The executable form may then be generated or maintained from that shared model.
Four layers, four different kinds of authority
A human-centred system keeps four layers distinct. The first is the authoritative legal source: the enacted provision, regulation, binding instrument or other rule recognised by the jurisdiction. The second is an interpretation model that maps terms, dependencies and decision paths to exact sources. The third is executable code that evaluates determinate conditions and calculations. The fourth is the operational service, which gathers evidence, applies process rules and routes cases to people.
Collapsing these layers creates government by code. If a service treats its implementation as the law, an error in a formula acquires false authority. If a machine-consumable model carries no status at all, however, every vendor may reinterpret the text independently and the public gains little from its publication. The practical answer is explicit status: the code should state whether it is an official implementation, a validated administrative interpretation, a simulation model or an experimental prototype. It should also state which human-readable source prevails when they conflict.
This is more than labelling. Every rule element should carry a source reference, responsible owner, effective period and version. A rate should not appear as an unexplained number inside a formula. It should be a dated parameter linked to the provision or instrument that sets it. OpenFisca, an open-source engine for modelling taxes and benefits, separates time-varying legislative parameters from formulas and recommends references for parameter values. Its training material is also admirably restrained: the task is to produce highly reliable interpretations, not to pretend that the interpretation itself is authoritative. That distinction appears in OpenFisca’s own Rules as Code guidance.
The same discipline must govern inputs. “Income” is not a neutral database field if different schemes include different payments, periods or household members. “Child”, “resident” and “partner” may have local statutory meanings. A shared vocabulary can help, but it must allow the same everyday word to resolve to different legal definitions in different contexts. Otherwise standardisation merely hides a conflict.
What machines can make visible
Some rules are unusually suitable for execution. Dates, thresholds, rates, arithmetic, dependency chains and mutually exclusive conditions can be represented precisely. Once represented, they can be tested across thousands of situations. Policy teams can compare a proposed threshold with the current one, estimate distributional effects, find discontinuities and identify combinations the drafters did not anticipate.
New Zealand’s Better Rules for Government discovery report documented a three-week, cross-agency exploration in 2018. Policy analysts, legislative drafters, service designers and developers built concept and decision models around existing legislation. The report described parallel work on human-readable legislation, pseudocode and software, and concluded that the shared models helped reveal gaps and reduce translation errors. It also explicitly recognised that not all rules are suitable for machine consumption. That was a discovery exercise and proof of concept, not a declaration that its code carried legal force.
Its most useful lesson is procedural. The model was valuable before automation because it forced disciplines to confront ambiguous terms and operational consequences together. A policy that seems clear in prose may lack an answer for a household that changes composition mid-month. A formula may expose an accidental cliff edge. A data requirement may reveal that the proposed decision cannot be made from information the state can lawfully or reliably obtain.
Executable modelling can thus improve legislation without becoming legislation. It provides a second surface on which contradictions, missing cases and unintended consequences can appear. The benefit is not that code eliminates interpretation; it makes parts of the interpretation inspectable.
The open-textured boundary
Public law deliberately uses terms that cannot be reduced to a universal table. “Reasonable”, “proportionate”, “best interests”, “exceptional circumstances” and “undue hardship” ask a decision-maker to connect a norm to a context. Discretion may also exist so that officials can respond to facts the legislature could not enumerate in advance.
An executable companion can support those decisions without completing them. It can identify the relevant provision, collect the evidence normally required, show prior procedural steps, expose missing information and record reasons. It can distinguish a standard case from one that reaches an interpretive boundary. What it should not do is replace that boundary with a proxy—such as a risk score, keyword count or inferred category—and then present the result as if the law compelled it.
The danger is false precision. Code demands a branch, a value or an exception handler. Under delivery pressure, an unresolved legal question can become a default value. Missing evidence may be converted into “false”; an ambiguous date may be assigned to the earliest convenient period; a discretionary power may be implemented as a mandatory refusal. These are policy decisions made in the syntax of engineering.
The stopping condition must therefore be part of the rule model. When a term requires judgement, evidence conflicts, an exception may apply or the model lacks an authorised interpretation, execution should return a reasoned referral state rather than a substantive outcome. The human decision-maker must see the relevant source and the path that brought the case there, and must have authority to disagree with the system.
Public tests are a form of democratic evidence
A machine-consumable rule is only as trustworthy as the situations against which it has been checked. Software teams already write tests: given particular inputs, the formula should return an expected result. OpenFisca’s documentation shows legislation tests expressed as cases with a period, inputs and expected outputs. That method becomes more valuable when the tests are treated as public policy artefacts rather than private developer fixtures.
A public test suite should contain ordinary cases, boundary values and designed counterexamples. It should show what happens one day before and after an age threshold, when income sits exactly on a limit, when information is unknown, when amendments overlap and when an exception is invoked. Each expected result should cite the rule and identify who approved the interpretation. A test should also be able to expect “human determination required”.
These are synthetic scenarios, not people’s case files. They can be discussed openly without exposing personal data. Legal-aid organisations, frontline staff, businesses and affected communities can propose cases that the official authors missed. Courts, tribunals and internal review bodies can trigger new tests when an interpretation changes. A public authority can run the same suite against its own service, a contractor’s product and an independent implementation.
Passing the tests does not prove that the rule is lawful, fair or complete. Tests encode expectations and can reproduce the authors’ blind spots. They do, however, make disagreement concrete. A critic can point to a scenario, a source and an output rather than arguing against an inaccessible system. That is a substantial improvement in contestability.
Versions must travel with decisions
Rules change. Amendments commence on different dates; transitional provisions preserve an earlier regime for some people; judicial interpretations alter the meaning without editing the statutory text; local rules interact with national ones. An API that always returns “the latest answer” can be wrong for a decision made last year.
Every calculation should therefore bind together the rule-set version, effective date, source versions, parameters, input assumptions and engine release. A person challenging a decision needs to reproduce the rule that was actually applied, not today’s corrected version. When an error is found, the authority must be able to identify affected decisions, rerun them under the correct interpretation and provide redress.
Updates should not flow silently into operational systems. Consumers need signed or otherwise verifiable releases, change notices, test results and a declared commencement date. Emergency corrections need a record of what changed and why. Vendors should not be allowed to freeze an obsolete interpretation behind contractual claims or proprietary tooling; the authority must retain the knowledge and capability to maintain the model.
Recent use remains varied in maturity. In 2025, New Zealand’s Government Chief Digital Office said it used a rules-as-code product to convert draft API guidelines into structured material for precise annotation and cross-referencing during a review. That is a bounded document-review use, not automated administration of an entitlement. OpenFisca supports operational calculators and policy simulation in multiple settings, but each country model is still an interpretation maintained through its own governance. “Rules as code” names a family of practices, not a single certified technology.
The strongest case for official code
The serious counterargument is that companion status is too weak. If only prose is authoritative, private organisations and public agencies must still translate it, recreating inconsistency. Official executable rules could provide certainty, lower compliance costs and let people obtain the same answer wherever they ask.
That argument is strongest for tightly specified calculations and parameters. A legislature could choose to confer legal status on a formally defined schedule, formula or data table, with an accessible human rendering and proper enactment. But making an executable artefact authoritative changes constitutional and practical questions: who can amend it, how it is promulgated, what counts as an error, how courts interpret it, and how a person without specialised tools can know the law.
Those questions cannot be solved by hosting source code in a public repository. Openness is necessary but not sufficient. The public needs durable documentation, accessible explanations, stable identifiers, review procedures and an institution capable of answering challenges. Official status should be granted deliberately by law, clause by clause where appropriate—not acquired accidentally because every service happens to call the same API.
A governed companion, not an invisible sovereign
A credible rules-as-code programme needs an accountable legal owner and a multidisciplinary maintenance team. Legislative counsel, policy officials, operational staff, developers, service designers and representatives of affected people should work from the same models. Independent reviewers need access to the sources, releases and tests. Appeals staff must be able to reconstruct a result and correct it.
The measure of success is not the percentage of legislation converted into code. It is whether fewer implementation errors reach people, discrepancies are found sooner, changes propagate safely, reasons become clearer and unusual cases receive genuine judgement. A system that calculates perfectly but makes its assumptions impossible to challenge has automated administration, not strengthened the rule of law.
Rules as code can give people a practical capability that prose alone often does not: the ability to test how a rule operates before a consequential decision arrives. It can also give lawmakers evidence about the effects of a proposal. To preserve that value, government must publish the boundary along with the code—what the model determines, what it merely supports, and where a human remains responsible.
If you want to follow this examination of human-centred public technology, subscribe to Alkemata for the next article in the series.
Continue exploring
The companion article “Law That Machines Can Read—and People Can Still Understand” explains the document standards and version provenance that make legislation addressable before any rule is executed.