Real-world business decision models frequently contain both hard rules and soft rules that can be violated when necessary. Representing and maintaining such rules becomes even more challenging when they conflict with each other and new rules need to be added — at which point a traditional rule-based approach begins to break down.

With this in mind, I will present a different approach that allows subject matter experts to express business rules with a certain degree of probability. Traditional DMN-style decision tables can be extended by assigning a low, medium, or high probability to conflicting rules. A decision engine then determines the optimal decision by satisfying the most probable combination of all applicable business rules.

Let’s consider an example from the DMCommunity May 2025 Challenge:

Traditional Rule-based Approach

In the example above, there are only four rules, and we can easily represent them in the following multi-hit decision table:

This table lists all possible combinations of 4 decision variables, but it relies on rule ordering, meaning that rules below can override rules above. While this table will produce valid results for all proposed test cases, the real question is: Will this solution remain maintainable when we need to represent a much larger number of interconnected rules with more possible conflicts?

The real-world trading systems that produce buy/sell recommendations maintain many more rules – the above problem represents only a tiny use case. The Challenge itself warns us that more rules will be added down the road. As this decision table grows significantly, continuing to rely on rule ordering will inevitably lead to a dead end.

New Approach: Rules with Probabilities

Let’s start with the Business Glossary that defines all the decision variables:

This is the standard Glossary usually used by rule-based decision models created with the OpenRules Decision Intelligence platform. It contains 4 input variables and 2 output variables. The only unusual construct here is the last column, “Domain”. It tells OpenRules that the last two decision variables are unknown, with possible values 0 (false) or 1 (true). It also means we plan to use a special decision engine called RuleSolver included in OpenRules. It supports Rules/Constraints with Probabilities and was designed for business analysts without programming skills.

RuleSolver requires two tables — “Define” for problem definition and “Solve” for problem resolution. In our case, we will define them as follows:

The table “Define” will post constraints on our unknown variables StockIsRisky and BuyStockShares:

The first table, “PostRickyConstraints,” rather than assigning exact values to the variable StockIsRisky, posts the appropriate constraint with varying degrees of confidence in the “Probability” sub-column — such as HIGH or LOW. The order of rules within this table does not matter, and additional rules can be added in any order.

The second table, “PostBuyConstraints,” doesn’t need probabilities. The first rule just states that if StockHasGoodPrice is Yes, then BuyStockShares should be 1. The second rule states that if StockHasGood Price is No, then post a conditional constraint

(StockIsRisky = 1) -> (BuyStockShares = 0)

As you may guess, this constraint states that if (StockIsRisky = 1), then (BuyStockShares = 0).

Note that a regular “Condition” column cannot be used to check the value of StockIsRisky, since it remains unknown at the problem definition stage (“Define”). Its possible values are automatically evaluated and selected only during problem resolution (“Solve”).

The table “Solve” will use the predefined RuleSolver’s method “SolverFindSolution”. This method will try to find a solution that minimizes the total constraint violation: the higher the constraint’s probability, the more expensive its violation is. Thus, our decision model will automatically decide which constraints will be violated (if any), making sure that the total constraint violation is minimal.

Here are my test cases:

The results were exactly as expected.

Note that we can post these constraints in any order, and, contrary to the pure rules-based solution, they do not have to list all mutually exclusive relationships. The probability of rules/constraints defines their relative levels of importance.

Keep in mind that RuleSolver supports the following “Probability” values:

NEVER, VERY_LOW, LOW, BELOW_MID, MID, ABOVE_MID, HIGH, VERY_HIGH, ALWAYS

The probability ALWAYS means that this is a regular “hard” constraint that cannot be violated. The probability NEVER means that this constraint can never be satisfied. All other probabilities specify rules that can be violated.

The same approach scales to far more complex business problems – see more examples at RuleSolver.com.