People frequently assume that a good, consistent decision model should produce one and only one decision (solution) for any valid input. However, in real-world applications we frequently deal with situations when a decision model may produce multiple feasible solutions for the same input. And it does not mean that the decision model is incomplete – simply a user may choose the most appropriate solution among all produced decisions. It can be done interactively or by adding more rules. I’ve already provided an example “Monkey Business Analyzed” that describes how to deal with multiple decisions using OpenRules What-If Analyzer. In this post I will describe another decision model that also shows how to choose an optimal decision among multiple feasible decisions.
Let’s consider a loan origination use case, such as the one described at the DMCommunity.org website. It covers loan pre-qualification decision model that uses Income Validation and Debt Research Rules to decide if a customer qualified for a loan. If we add this decision model to our What-If Analyzer, it will look as follows:
Our What-If Analyzer immediately produces one and only one decision (solution) showing that this particular customer is QUALIFIED for the requested loan with a fixed loan amount. Of course, we may deactivate some rules or try different customers and loan requests, but the result is always QUALIFIED or UNQUALIFIED. What if the result is UNQUALIFIED and we want to know if there is a loan amount to which this customer is qualified? We may try different amounts but it could be too many tried-and-failed situations to find an answer manually.
It is much more practical to consider another decision model when we specify only lower and upper bounds for loan amount and different acceptable loan terms. Then we may ask the decision model itself to find an optimal combination of loan amount and loan term for a qualified borrower. Our new decision model is called “Loan Calculation” and its glossary defines only the following decision variables:
Here we have only two input (known) variables, Monthly Income and Monthly Debt. All other variables are unknown and should be defined by our decision model.
We will specify the variable “Loan Amount” as our optimization objective using this method:
Our new Income Validation Rules will look as follows:
Here is how we define our intermediate variables “Total Debt”, “Total Income”, and “Accumulated Debt” needed by these rules:
We will let our user to activate the rules that enforces value SUFFICIENT for the decision variable “Income Validation Result”:
To allow our user to play with different values of Loan Amount and Loan Term, we will specify the following rules that the user may activate/deactivate doing what-if analysis:
When we load this decision model into our What-If Analyzer, it will look as follows:
Please note that our rules define Loan Term = 24 and 35000 <= Loan Amount <= 75000. However, constraint propagation by itself already limited the upper bound of Loan Amount to 35999 = 98399 – 62400 to keep Income Validation Result SUFFICIENT.
Let’s change Loan Term from 24 to 36. Here is the result:
As you can see, the domain of Loan Amount has been changed to 35000..53999 as Total Income for 36 months grows to 147600.
If we click on the button “Solution”, we will get the first feasible solution, and then by clicking on the “Next” we may navigate through various solutions. Here is one of the possible solutions:
We limited the maximal number of solutions to 500 (using “Settings”), but there are obviously many more of them. If we click on the button “Maximize”, we will find the maximal Loan Amount=53999 for the Loan Term=36:
If we deactivate all constraints on the Loan Term, the maximal Loan Amount will be automatically defined as 75000 while Loan Term will be defined as 72 months. If we additionally deactivate the rule “Loan Amount <= 75000” then the maximal Loan Amount will be 100000, the specified maximum in the Glossary.
When we have more complex rules and combinations of other risk factors, What-If Analyzer still would be able to quickly produce alternative and optimal decisions.
Conclusion. In many practical cases, it is not realistic to force a user to specify rules for ALL possible combinations of decision variables. Instead, a decision modeler may specify a business objective that depend on other decision variables and then ask the decision model itself to come up with a decision that minimizes or maximizes this objective. Thus, we should make the decision model smarter by empowering it with decision optimization capabilities similar to those described in the above example.