Rules are the product
A school placement engine, an application form with photo requirements, a member entitlement calculation: the value in each is the rules, not the interface. Yet the rules are usually the least visible part of the system, scattered across code, stored procedures, spreadsheet formulas and the memories of the people who run the process.
The first principle is to treat the rules as a first-class part of the design. Model them explicitly. Name them. Order them. Test them.
Define the decision precisely
Assessing whether someone is eligible, ranking their preferences, and allocating limited capacity are three different problems. Checking that a photo is usable is different again from confirming that it shows a particular person. Each has different fairness, privacy and audit requirements, and different approvals.
Be precise about which decision the system is making. It shapes everything downstream, and it is the question a review board will ask first.
Thresholds are configuration, governed
The numbers change. Capacity changes each intake. A quality threshold moves as the organisation learns. If those values are in code, every change is a release, and every release is a chance to get it wrong.
Hold thresholds and parameters in configuration with an approval path, so authorised business owners can review and change them. Technical values should support an approved policy; they should never silently become the policy.
Every outcome must be explainable
A family asks why their child was not placed. An applicant asks why their photo was rejected. An officer has to answer without a developer in the room.
Record which rules fired and why, for every decision. Then write the outcome for the person affected, in plain language, with what to do next. "Please use a photo where your face is looking towards the camera" beats "yaw threshold exceeded" every time.
Leave a path for human judgement
Rules do not fit every legitimate circumstance. Photo requirements meet religious headwear, medical needs and disability. Placement rules meet situations the policy did not anticipate.
Design the alternative pathway in from the start. Let individual rules be switched off. Route exceptions to accountable people. Automation should guide a process, not replace judgement, and in the public sector that is a matter of procedural fairness as much as good design.
Keep core checks independent of external services
When part of a rule depends on an outside service, an AI API, a lookup, a payment gateway, that dependency will be unavailable at the worst moment.
Separate what can be checked without the service from what cannot. Give the organisation an operational switch and a defined fallback policy: what is accepted, what is marked for later review, how people are informed. A form should not stop working because a vendor is having a bad afternoon.
Use the minimum data needed
Do not collect or infer more than the rule requires. If basic quality signals meet the need, do not ask a service for attributes you will not use. This is good engineering everywhere and a legal obligation in government.
Test the rules with the policy owner
Scenario tests written with the people who own the policy are the acceptance criteria. Each rule becomes a set of worked examples both sides agree on. When the policy changes, the examples change first and the code follows. It is the most reliable way we know to keep a system and its policy in step.
Where we have applied this
- A statewide school placement engine with configurable preference, eligibility and capacity rules.
- Real-time photo validation inside a government application, with an operational switch for the AI service.
- Entitlement and payment calculations for a health insurer.
If you have a policy document and a system that does not quite implement it, read about our rules and calculation engines or get in touch.