Home Services Partners Company
More Examples of Accounting for Uncertainty in Rule Modeling

More Examples of Accounting for Uncertainty in Rule Modeling

June 24, 2015 0 Comments

More examples of ambiguity in rule modeling illustrate how to account for uncertainty in Progress Corticon.

In my last post, “Clearing Up Ambiguity in Rule Modeling,” I discussed how to resolve ambiguity in business rules modeling using example from real Progress® Corticon® projects. Resolving ambiguities can be critical in decision-making instances where yes or no answers are a matter of health, welfare or financial risk.

While risk is an inevitable part of life, businesses need to be certain of what they do know, and have a grasp of the probability of certain outcomes to avoid it. Just as in life, businesses face decisions that have to account for an amount of uncertainty. But you can account for uncertainties in business rule models by mathematically aggregating certainties as different rule validations contribute to probabilities.

Using the Corticon Ambiguity Checker

The sheet below has an ambiguity, since a risk rating can only hold one value.

Risk rating rule containing ambiguity.

Figure 8: Risk rating rule containing ambiguity.

Should this be flagged? Yes, because one rule will overwrite the results of the other depending on the order of execution.

Is there an ambiguity in this rule model?

Figure 2: Is there an ambiguity in this rule model?

Is there a real ambiguity here? No. Applicant.age and Applicant.hobby rules are independent—they affect different attributes. In addition, hobbies are generally independent of age. So what should we do about the next example?

A rules model defining an ambiguous business attribute.

Figure 3: A rules model defining an ambiguous business attribute.

Semantically this model defines a business attribute that cannot exist, because any particular age must fall into one of the three ranges defined by the conditions. So, should Corticon flag this as an ambiguity?

In the next example, we have two different attributes that are saying something about age.

Rule determining fitness for “young” category.

Figure 4: Rule determining fitness for “young” category.

Clearly, someone cannot be under 21 and over 65 at the same time, so this cannot be an ambiguity. But Corticon does not know that, and is correct in flagging this rule as an ambiguity for the business user to resolve. The problem arises because the first and second conditions are mutually exclusive (in the real world). There is a missing business rule—the one that says that an applicant cannot be less than 21 and over 65.

We could capture the missing business rule this way:

Rule model with missing business rule added.

Figure 5: Rule model with missing business rule added.

The ambiguity goes away completely if it’s modeled like this. Now we can explicitly state the previously hidden rule about not being under 21 and over 65 at the same time.

Resolving Ambiguities in Business Rule sheets

Here’s a real world example that illustrates this same problem. It comes from an actual proof of concept (POC) done several years ago. The client had rules similar to the model below.

Sample business role model copied from Excel into Corticon.

Figure 13: Sample business role model copied from Excel into Corticon.


The customer’s rules, expressed as an Excel spreadsheet, were simply copied and pasted into Corticon. It’s not important to read the actual rules.

In this rule model, there are 42 attributes, each of which can be Y or N, and the rule sheet has 47 defined rules. How many missing rules do you think there are? Running the completeness checker on this model is somewhat amusing:

Corticon Studio completeness check of rule sheet.

Figure 14: Corticon Studio completeness check of rule sheet.

It took Progress® Corticon® Business Rules Studio many minutes to come up with this result, but it did it. And the ambiguity checker turned up 96 ambiguities among the 47 rules!

Corticon ambiguity checker results.

Figure 15: Corticon ambiguity checker results.

Defining overrides would be a very painful task. Defining the sets of actions or rules to suppress false ambiguity would be completely unmanageable in this model. The lists would be so long as to be unreadable.

Apart from the fact that the rule sheet is overwhelming, the real problem is that the model was fundamentally wrong. Many of the possible scenarios wouldn’t occur in the real world. But if that’s the case, then they shouldn’t occur in the rule sheet either. The reality is that many of the attributes in this model represent the state of work on one queue or another. Work cannot be in more than one queue at any one time. In this model, the vocabulary was wrong! Restructuring the vocabulary made a huge difference.

If we were stuck with an existing (bad) data model that we might not be able to change, at least not outside of Studio, how could we solve the issues?

We have to capture somewhere in the rules the idea that queues are mutually exclusive as a real business rule, not as hidden plumbing. This can be done easily be creating a helper rule sheet—which can also be checked for ambiguity—that expresses this knowledge and simply maps from several dozen Y/N attributes into a single attribute that can take dozens of values, indicating which of the many mutually exclusive queues the work can be in.

Now the ambiguities arising from this simply vanish—we shouldn’t need a complicated solution to deal with a problem that shouldn’t be there in the first place. Otherwise, we are just making a bad situation worse. With a better vocabulary, we’d end up with much simpler rules like this:

A simpler business rule sheet.

Figure 16: A simpler business rule sheet.

We can further improve the rules by re-partitioning into smaller orthogonal ones. The visual appearance of the original with all its gaps gives us a clue how it should be divided up. For example, rules 31 to 46 appear to form a discrete set dealing with the “move to HCO.”

Discrete set of rules on the rule sheet that should be re-partitioned.

Figure 10: Discrete set of rules on the rule sheet that should be re-partitioned.

Any ambiguities that might arise here as a result of the different values in the second action, which is tracking which rule executed, are not true ambiguities. The important action “move to HCO” is the same in all cases.

If we could simply “hide” action 2 from the ambiguity checker we’d be fine. Unfortunately, disabling action 2 does not prevent the ambiguity checker from including it.

Stay tuned for my next post, in which I will discuss modeling rules to account for uncertainty and probability.

Learn More in the Progress Corticon Community

To stay updated on the latest tips, tricks and help from Progress Corticon developers and users, follow the Corticon Community. There you can access RulesWorld, the Corticon wiki; find the latest documentation; and speak with Corticon experts from around the world.

Michael Parish

View all posts from Michael Parish on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.

Read next Master the Market by Unlocking Business Agility
Comments are disabled in preview mode.