Machine Learning or Just Rules? An Honest Decision Guide
Last updated:
The unfashionable option is often the right one
There is a strong pull towards machine learning for problems that a few dozen if-statements would solve better. Rules are cheap, instant, perfectly explainable, and they work on day one without training data.
Before commissioning a model, try to write the rules. The attempt is informative either way: if you can, you are done cheaply; if you cannot, you have learned something important about the problem.
Where rules genuinely win
- The logic is written down somewhere — a policy, a rate card, a regulation
- Every decision must be explainable to a customer or a regulator
- You have little or no historical labelled data
- The cost of an error is high and unpredictability is unacceptable
- The logic changes by decision rather than by drift, and needs to change instantly
Fraud thresholds, pricing bands, eligibility checks and routing by postcode are all rules problems. Dressing them up as ML adds cost and removes explainability.
Where rules fall over
Two symptoms. First, the rule count passes a few hundred and nobody can predict the effect of a change. Second, the exceptions start needing exceptions, and each new customer or product breaks something.
The tell we listen for: “we're not sure what that rule is for, but things break when we remove it.” That is a system that has outgrown its representation.
Where models genuinely win
When a pattern demonstrably exists — experienced staff can spot it — but nobody can articulate the criteria. Which leads convert. Which invoices are likely to be disputed. Which support tickets will escalate. Which machines are about to fail.
The requirement is history: enough labelled examples, consistently recorded, covering the range of cases you care about. Without that, a model is guessing with extra steps.
The hybrid that beats both
In production the strongest designs use both. Rules handle the certainties and the hard constraints; a model handles the grey area; the rules then constrain what the model is allowed to do.
- Rules first for anything mandatory — legal limits, hard eligibility, safety.
- Model for the ranking, scoring or classification in the middle.
- Rules again as a guardrail, so a model output can never breach a business constraint.
- Log every decision with its inputs, so both halves can be audited and improved.
Cost and time, side by side
| Rules engine | Model | |
|---|---|---|
| Typical build | £4,000–£15,000 | £20,000–£60,000+ |
| Needs historical data | No | Yes, and clean |
| Time to first version | 2–5 weeks | 8–16 weeks |
| Explainability | Complete | Partial at best |
| Changing behaviour | Edit a rule | Retrain and revalidate |
| Handles the unforeseen | Poorly | Better, sometimes surprisingly |
Frequently asked questions
How much data does a model need?
Can we start with rules and move to a model later?
Are large language models an alternative to both?
How do we explain a model's decision to a customer?
Not sure which one your problem needs?
Describe the decision you want automated and how it is made today. We will tell you whether it is rules, a model, or both — and we will say so if rules are enough.