Representing Contradictory Rules with Single-Hit and Multi-Hit Decision Tables

Modern rules and decisions management systems provide effective mechanisms for development of good decision models. However, building real-world decision models people always face complex issues related to diagnostic and resolution of rule conflicts. Some systems can effectively verify decision model consistency and diagnose rule conflicts. But there are no practically used Business Rules products that claim that they may automatically resolve rule conflicts (at least I am not aware of them).  As a result, it becomes a responsibility of users to represent rules in such a way that allows them to avoid conflicts.

Unfortunately, rule conflicts occur in real-life all the time especially when some rules are exceptions to others. Let’s consider a simple example of rule conflicts:

• Rule 1: Birds can fly
• Rule 2: Chicken cannot fly
• Rule 3: Scared chicken can fly.

Even little children can apply these rules in many practical situations. When business analysts try to represent these rules, they may quickly come up with a decision table that avoids rule conflicts by considering all “if-then” combinations in a mutually exclusive way:

Table 1. A simple decision table

However, in real life, new concepts and related rules are frequently introduced later on when an initial set of rules is already in production. Then representation of all possible if-then-else combinations may become a real challenge. Even in this simple case, let add two more rules:

• Rule 4: Penguins cannot fly
• Rule 5: Everybody can fly in the airplane.

Apparently, if you try to cover all possible combinations for these 5 rules, the number of rules grows exponentially. The proper decision table may look like below:

Table 2. A more complex single-hit decision table

It is already quite difficult to read and understand such a decision table not mentioning a necessity to maintain it with future changes. Think about adding a rule “Birds with broken wings cannot fly” or taken into consideration Ostriches who would not fly even when they are scared.  What if we try to add more rules that cover other 40 kinds of flightless birds that are in existence today?

All previous decision tables were so called “single-hit” tables that corresponded to the requirements of The Decision Model (TDM) and expect a user to cover all possible combinations of rules conditions as only one rule will be executed. However, OpenRules and some other BR products also support so called “multi-hit” decision tables that allow rule overrides.  It means that instead of describing all possible combinations of rules conditions, you may take an advantage of the fact that rules with more specific conditions may override previously defined rules with more generic conditions. For example, the single-hit decision table 2 could be replaced with the following multi-hit decision table:

Table 3. A multi-hit decision table with rule overrides

Please note the keyword “DecisionTableMultiHit” at the left top corner of this multi-hit decision table. Here the Rule 2 “Chicken cannot fly” clearly overrides the Rule1 “Bird can fly”. While the Table 3 looks more readable and easy to maintain to compare with a single-hit Table 2, it relies on a strict sequencing of the rules inside the decision table that makes an introduction of new concepts and rules much more problematic.

The Part 2 will describe the latest attempts to solve rules conflicts using the defensible logic and its implementations.