When a Rules Engine Is Better Than AI

Finding a tire that fits isn't enough

Years ago, I developed tire fitment software that helped customers find replacement tires for their vehicles. On the surface, it seemed like a straightforward database problem. Find the tires that match the vehicle's required dimensions and display the results.

But matching dimensions doesn't necessarily mean a tire is suitable for the vehicle.

A replacement tire might have the correct dimensions but an insufficient load rating. It might have a lower speed rating than the original equipment tire. Or it might be a off-road tire that wasn't suitable for the particular type of vehicle.

A customer wouldn't necessarily know any of this. They would reasonably assume that if the software recommended a tire, it was appropriate for their vehicle.

How I approached the problem

I divided the problem into two parts. First, SQL retrieved the available tires that matched the required dimensions. That produced a list of candidates, but not necessarily valid replacements.

I then passed those candidates through a rules engine that evaluated whether each tire was suitable for the vehicle.

For example, if the original tire had a V speed rating, a replacement with an H rating would be excluded under the replacement rules we were applying. Similarly, a tire that couldn't support the required vehicle load was removed, even if the dimensions matched.

The rules also accounted for vehicle characteristics. A performance tire might be an acceptable option for one vehicle but not for a van.

This separation made sense to me. SQL was good at finding matching products. The rules engine handled the additional business and fitment requirements that determined which products could actually be recommended.

Why I wanted explicit rules

The important thing was consistency. Given the same vehicle specifications, tire data, and replacement rules, the system needed to produce the same result every time.

It also needed to be possible to understand why a particular tire was excluded. If a product didn't meet the load requirement, that was the reason. There was no need to infer or guess.

Of course, the rules were only as good as the information behind them. Incorrect vehicle specifications or an incorrectly defined rule could still produce a bad result. Those problems needed to be addressed through accurate data and proper validation.

But using explicit rules meant the application could apply the intended conditions consistently. That was especially important when the consequences of a wrong recommendation went beyond a poor customer experience.

Would I use AI for this today?

Not for the final fitment decision.

AI could be useful in other parts of the experience. A customer might describe what they need in ordinary language, or ask questions about different tire types. An AI interface could help interpret those requests and make the search easier.

But once I have the vehicle specifications and a set of candidate tires, I don't see a good reason to ask a model to decide whether each one meets a defined load or speed-rating requirement.

I already know how to evaluate those conditions. Conventional software can do it consistently, without introducing model variability or inference costs.

If I were rebuilding the system today, I might explore AI for understanding customer questions or finding information in unstructured product descriptions. I would still keep the final suitability checks deterministic.

The architecture matters more than the tool

I think this example reflects how I've approached software decisions throughout my career. Different parts of a problem often need different solutions.

In this case, SQL handled the initial search and a rules engine handled suitability. Neither needed to do the other's job.

AI gives us another option, particularly for dealing with ambiguous requests and information that conventional software has difficulty interpreting.

But having another option doesn't mean I should use it everywhere. Sometimes the best approach is still a database query followed by a set of well-defined rules.