Rules and calculation engines

Why rules deserve their own service

A rule that lives in a policy document, a spreadsheet formula and three developers' heads is not a rule. It is a risk. It cannot be tested, it cannot be explained to the person it affects, and it changes silently when someone edits the wrong cell.

Booolean has spent years building systems where the rules are the product: who is eligible, who gets placed where, what a member is entitled to, what a bill should contain, what a planner is allowed to schedule. The pattern is always the same. Get the rules out of the code and into a place where they can be configured, versioned, tested and explained.

What a Booolean rules engine looks like

Configurable thresholds and parameters. Values that change each year or each intake are held in configuration with an approval path, not buried in application code.
Explicit rule sets. Eligibility, preference, capacity and priority rules are modelled as named, ordered, testable units.
Explainable outcomes. Every decision records which rules fired and why, so an officer can answer "why was this the result?" without a developer.
Audit trail. Who changed which rule, when, and what outcomes changed as a result.
Human judgement path. Rules do not fit every legitimate circumstance. The design always includes an alternative or review pathway so automation guides a process rather than replacing accountable judgement.
Resilience. When a rule depends on an external service, the system degrades gracefully rather than blocking the person in front of it.

Where we have applied it

EducationStatewide school placementConfigurable preference, eligibility and capacity rules with auditable placement outcomes for a state education department. EducationPhoto validation rulesFace-analysis quality signals translated into client-configurable acceptance rules and plain-language feedback. Health insuranceEntitlement and payment calculationComplex financial and membership calculations moved out of legacy procedures into testable services. TelecommunicationsBilling compositionEvery bill assembled by rule, at volume, every cycle.

Our design principles

Define the decision precisely. Assessing eligibility, ranking preferences and allocating capacity are different problems with different fairness and audit requirements.
Use the minimum data needed. Do not collect or infer more than the rule requires. This matters doubly in government.
Keep core checks independent. The parts of the rule that do not need an external service should keep working when that service is down.
Make thresholds configurable and governed. Technical values should support an approved policy, never silently become the policy.
Write the outcome for the person affected. Plain language, with what to do next.
Test the rules, not just the code. Scenario tests written with the policy owner are the acceptance criteria.

Start here

If you have a policy document and a system that does not quite implement it, we would like to see both. Get in touch.