Is Inference Dead?

on September 14, 2010
SMARTS™ Data-Powered Decision Management Platform

I was reading a blog from a BRMS “sequential” proponent that attacked “inference”… of course!  That part is not at all surprising.  That being said, it is not black or white…  Inference Vs. Sequential is not a Good Vs. Evil discussion.

Per my older blog on Algorithm, you know that I certainly don’t care to surface the algorithm and how it works to the actual users — those in charge of the maintenance of the business rules.

That being said, does it matter that the thing runs in sequential or inference mode?  Well, most of the time it doesn’t but sometimes it does. Do you care to know why?

Why it does not matter most of the time

The real value in business rules is the maintenance, not the execution.  With that in mind, it may sound surprising that I post yet one more blog on the topic.  One could argue “pick one, sequential or inference, and be merry”.


As long as the tooling you select allows for business rules to be maintained independently, meaning that you do not have to understand the whole set to make an update, as long as each business rule represents an atomic piece of logic, the mode of execution should not have any importance whatsoever.

In many projects your business rules are so independent that they can really live a life of their own: the execution of one has zero impact on the others.  Take some examples:

  • Retail / e-Commerce:
    • If you purchase more than $25 of stuff, you get free shipping
    • If you apply a gift certificate that exceeds the purchase amount, the extra $$ is forfeited
    • If you buy a cookbook, you get recommendations for other popular cookbook and cooking accessories
  • Insurance
    • If you have had more than 3 accidents or violations in the past 3 years, you are not eligible for an Auto policy
    • If you live in CA, we do not offer Earthquake coverage
    • If you are older, you must submit a medical statement
  • Financial Service
    • If your credit score is between 650 and 700, your credit limit increase is limited to 20%
    • If your account has been delinquent for 6 months or more, your case will be turned over to a Collection agency
    • If your account balance gets below $1,500, you will be charged service fees

Although those business rules should be coordinated they would not trigger each other to execute again and again.  It is pretty likely that you only need to check each one only once and then you can move on to the next one.

How you evaluate and execute all of those business rules would certainly have some importance in performance.  Evaluating each one independently and sequentially would be faster for a large batch of objects that you evaluate against a few rules.  Now if you have millions of rules to go through, combining elegantly the conditions might save you some time if your batch is much smaller.  This is a general guideline of course.  A good architect would likely look at the nature of the problem in more details to assess which technique is the most effective.

But, in the end, it does not really matter which technique you are using because they will lead to the same result.  If your shopping cart should be charge $53.99, it will be charged $53.99.  Period.

Why it does matter sometimes

Sometimes performance can play a big role in your architecture decision.  I remember a project a long time ago when I was responsible our Telecom business.  A Telecom operator wanted to use Business Rules to correlate alarms raised by their networks.  They had used sequential coding before that leads to huge bottlenecks.  We introduced a Rules Engine in their architecture with a few dozen rules that removed duplicates and made some basic decisions on the fly.  That processing took no time at all.  They were impressed.

The main reason for the performance improvement was the fact that RETE could remember the past alarms and only processed the incoming delta.  That was huge.  This was a RETE application way back then of the “Always On” concept we hear about nowadays when talking about Complex Event Processing (CEP).

The other reason for RETE or inference to be relevant in a decisioning service is…  INFERENCE…  “Duh” you might say.  One of the key attributes of the algorithm is not only to be elegant about combining condition evaluations like we discussed before, but more importantly to be very good at propagating changes in your data.  It means that when you make a little decision, you might create a chain reaction of correlated decisions.  You allow decisions to be chained together in ways that you do not want to describe and/or maintain.  The algorithm figures out what is related to what and applies it.

Let me take a simple Healthcare example.  Let’s have business rules responsible to reasoning over health risks:

  1. If the patient is positive at the glucose test, he/she might be at risk for Diabetes
  2. If the patient was prescribed an amniocentesis, she is likely pregnant
  3. If a pregnant patient is at risk of diabetes, she should be tested again with glucose test within a couple of months of delivery

Given some patient data, you might come up with different results depending on the order in which you process your rules.  In the 1-2-3 order you find out first that the patient is pregnant and at risk, which allows you to prescribe the recommended test.  If your system looks at the rules sequentially in a different order, let’s say 3-2-1, we end up knowing about the risk and the pregnancy but we checked too early for the post-delivery glucose test — when those premises were not yet available.

This example is simplified here to look at only a limited number of factors.  The complexity of your business rules and their “linkage” increases exponentially with the number of rules.

Of course someone can fix the system by reordering the rules in the 1-2-3 order… But it does require an extra effort and introduces a risk. What if a couple of rules are not sequenced properly? The other solution might be to loop through your business rules until there is no more decision to be made — which would kill performance of course.

Inference is NOT DEAD! So should we dig Inference back up?

Well, I hope that in reality nobody buried Inference six-feet under.  Inference does serve a purpose.  That may not be the most common case but it is invaluable when it is needed.

The fact that you can ride your bike or drive your car on your daily commute does not mean that planes are irrelevant, especially when you need to travel out-of-state or out of the country.

<Disclaimer: Maybe I should have waited for Halloween to post!>

Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager

Search Posts by Category


Sparkling Logic Inc. is a Silicon Valley-based company dedicated to helping organizations automate and optimize key decisions in daily business operations and customer interactions in a low-code, no-code environment. Our core product, SMARTS™ Data-Powered Decision Manager, is an all-in-one decision management platform designed for business analysts to quickly automate and continuously optimize complex operational decisions. Learn more by requesting a live demo or free trial today.