A parent reports a routine change in earnings. The new digital rule accepts the dates, runs the calculation and records a result. Yet weekly pay puts two wages in one calendar month, so the software treats a timing accident as a lasting rise in income. Its code works. The policy does not.
The safest time to find that failure is before the rule changes anyone’s entitlement. Digital policy should therefore be tested against transparent synthetic cases, carefully governed historical edge cases and scenarios designed with affected communities. The aim is not to predict every life. It is to reveal where an apparently precise implementation has smuggled in assumptions, and to give someone with public authority the power to stop, revise or reverse it.
A unit test is also a policy claim
A unit test supplies an input and checks for an expected output. Applied to a digital rule, that simple act carries institutional weight. The expected benefit for a household is not generated by mathematics alone; it embodies an interpretation of legislation, definitions, dates and discretion.
This is why a green test dashboard cannot by itself demonstrate that a policy is correct. It can show that the code agrees with the expectations written into the test suite. If those expectations omit irregular work, informal care, disputed residency, missing evidence or a deadline that falls on a closed office, the software may be perfectly consistent and systematically wrong at the same time.
The first useful layer is a set of synthetic cases: invented records containing no real person’s data. Ordinary cases confirm the basic calculation. Boundary cases sit just below and above thresholds, on commencement dates, and at the intersections between rules. Exception cases exercise missing information, conflicting evidence and situations that require human judgement. Each case should state the applicable rule, the expected result and why that expectation was chosen. That makes disagreement inspectable: lawyers can challenge the interpretation, service staff can identify an impossible workflow, and affected people can point out an implausible life story.
New Zealand’s 2018 Better Rules for Government discovery report described early machine-consumable drafts as a way to conduct scenario and user testing with ministers and impacted people. It also stressed that not all legislation is suitable for machine consumption. That work was a three-week discovery sprint, not evidence of a nationwide operational system. Its lasting value is the method: bring policy, drafting, service design and software together early enough that testing can still alter the rule.
The people at the edge help design the cases
A policy team can invent examples, but it will tend to invent people who resemble its forms. A person’s circumstances arrive as a clean row: one address, one employer, one answer per question. Real public services encounter unstable housing, shared care, changing names, inaccessible documents, coercive partners, fluctuating income and several agencies using different definitions of the same fact.
Scenarios designed with affected communities are not a decorative consultation exercise. They are a way to discover variables, sequences and harms that the formal model has excluded. Frontline caseworkers know where evidence usually goes missing. Advisers and advocacy organisations see recurring combinations of rules. Appeals staff know which apparently rare conditions become expensive, prolonged failures. People who use the service can show when a technically available route is practically unusable.
The UK Government Service Manual says alpha research should test prototypes with likely users and include people with limited digital access, disabled people, frontline staff and organisations that support users. Its guidance is about service design rather than a complete policy-assurance regime, but the principle transfers: a rule is not adequately tested by the people who encoded it alone. During beta, the manual expects continued testing with a broad range of users and production-like technology. GOV.UK also explains that a beta may operate alongside an older service while it is tested and improved, rather than immediately replacing it.
Participation needs resources and limits. A workshop cannot transfer the state’s responsibility to people who may lose money or rights. Participants need appropriate support, privacy and an account of what their evidence changed.
Historical cases reveal different truths
Past cases contain awkward combinations that synthetic examples miss and can reveal how errors accumulate across months or agencies. But history is not a neutral answer key. Earlier decisions may have been unlawful or inconsistent; appeals over-represent people able to persist; records reflect what the institution chose to collect.
Historical testing should therefore ask two separate questions. Does the new implementation reproduce the recorded decision? And should it? A disagreement may expose a software defect, but it may also expose a defect in the previous policy, data or practice. Records should be minimised, protected and, where possible, transformed into abstract test cases. Simply copying a large archive into a test environment creates privacy and security risks without guaranteeing useful coverage.
Synthetic data has the opposite weakness. It can protect privacy and deliberately represent rare combinations, yet it is often too tidy. Generators reproduce the assumptions of their designers; statistical synthetic data can preserve patterns from biased source records. The best assurance uses both forms, documents their limits and invites challenges to what is absent.
Shadow operation separates comparison from consequence
After controlled tests, a new rule can run in shadow mode. The system receives the same inputs as the existing process and produces a result, but that result does not control the person’s entitlement or obligation. Teams compare outcomes, reasons, missing-data rates and processing burdens. Disagreements are reviewed by people with legal, policy, operational and technical competence.
Shadow operation exposes failures in the complete workflow. A correct calculation may receive an out-of-date attribute; an exception may reach a team with no time to examine it; a correction may fail to propagate. Code-only tests miss these mechanisms of harm.
Shadowing is not automatically harmless. If staff can see a system’s provisional recommendation, it may anchor their judgement. A clean comparison sometimes requires the new output to remain hidden until the existing decision and reasons have been recorded. Even then, the comparison must look beyond overall agreement. A high average can conceal repeated errors for a small group, or agreement may merely show that both systems share the same flawed rule.
Canada’s current Algorithmic Impact Assessment guidance illustrates a risk-proportionate approach for federal automated decision systems. It calls for assessment at the beginning of design and again before production, alongside testing, outcome monitoring, legal consultation and recourse. For systems at higher impact levels, Canada’s peer-review guidance requires review before production and recommends including stakeholders from impacted groups where possible. These controls do not certify a system as fair. They show that release can be treated as a governed decision supported by evidence rather than as the natural end of development.
Stage the change without staging unequal rights
The strongest argument against elaborate pre-deployment testing is practical. Policy changes can be urgent, edge cases are inexhaustible, and a test environment cannot reproduce the institutions, incentives and behaviour of the real world. An assurance process can become a slow theatre in which teams produce documents instead of learning.
That objection should shape the testing regime, not abolish it. Tests should be proportionate to the consequence and reversibility of the change. A wording improvement needs a different gate from an eligibility calculation. The higher the potential impact on income, housing, liberty or legal status, the stronger the evidence and independent scrutiny should be.
A staged deployment can then expose the implementation to limited real conditions while preserving rollback, human checking and the previous route. But government cannot casually experiment with equal legal entitlements. A geographical or randomised trial that gives similarly situated people different substantive rights may be impermissible even if it is technically informative. The safer unit of experimentation is often the delivery method, staff support or interface, while the authoritative rule and full remedy remain available to everyone.
Before release, the institution should define what will trigger a pause: a material legal disagreement, a threshold error, a rising correction rate, a disproportionate burden on a group, or an inability to explain outcomes. Monitoring after release must continue, because changing behaviour and upstream data will invalidate some tests. Staged deployment is meaningful only when the organisation can return to the previous process and reconcile every affected case.
The decisive control is the power to refuse release
Testing produces evidence; governance decides whether it matters. A named service owner should be accountable, but cannot alone mark the work safe. Legal, operational and technical reviewers and affected communities need routes to record objections, while an internal authority must be able to pause release and remedy harm.
The most revealing measure is not the number of tests passed. It is what happened when a test failed. Was the rule clarified, the code changed, the service redesigned or the deployment stopped? Were affected people able to force reconsideration, or were their scenarios classified as unusual and removed from the denominator?
If you value analysis of public technology that starts with human consequences and works back through the machinery, you can subscribe to Alkemata for future essays.
Continue exploring
This article follows Rules as Code Without Government by Code, which examines why executable rules should remain testable companions to law rather than hidden substitutes for it.
A policy test suite will always be incomplete. The democratic question is therefore sharper than whether the software passed: when evidence shows that a digital rule will fail some of the people it governs, who has the standing and the power to make government redesign it before the public becomes the test environment?