Dealing with Ambiguity in Rule Modeling

Suppose we have this decision table:

 

Notice that it contains this ambiguity

 

Specifically in this particular case

This can be resolved in a number of ways:

  1. Perhaps there is another attribute Thing.a5 whose value serves to distinguish the two cases. Adding that as an extra condition would remove the ambiguity
  2. We could set an override for one of the two rules (if it’s always the case that one rule overrides the other)

 

But what if there is no other data that serves to distinguish the two cases and that the real world situation is that in some cases the result is X and in some cases it is Y.

How should we model this.

One possible way is to create two results – one for X and one for Z and assign a probability for each:

Now whenever the conditions for rule 2 arise we preserve the duality of the result by showing that it can be both X and Z (although with different probabilities for each).

 

 

This type of rule might arise in a medical diagnosis application where the results of lab tests a1..a4 in case 2 are not sufficient to distinguish completely the two possible diagnoses X and Z. Maybe at a future date we might discover a test that does accurately distinguish the two cases and at that point in time we can update the rule.

 

This idea of introducing probabilities (or uncertainties) into the results is explored more fully in a separate section and we discuss how certainties can be mathematically aggregated as different rules contribute their probabilities.

 

 

 

Ambiguity

This sheet has an ambiguity since risk rating can only hold one value

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

Should this be flagged – No, because rule 1 and rule 2 are independent

  

 Semantically this cannot happen of course – should Corticon flag this as an ambiguity?

 

What about this example?

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 – so it is correct in flagging this as an ambiguity for the business user to resolve

In this case there is a missing business rule – the one that says that you cannot be under 21 and over 65.

 

Should this be handled by suppressing the ambiguity checker? Or is there something more fundamentally wrong with our rule model.

We could capture the missing business rule this way:

 

The ambiguity goes away completely if its modeled like this – now we can explicitly state the previously hidden rule about not being under 21 and over 65 at the same time

 

Here’s a real world example
This comes from an actual customer POC a few years ago.

They had rules like this:

BTW we took this verbatim from their own rules expressed as an Excel spreadsheet (basically copy/pasted it and then hand edited - though now there is a tool available for importing rules from Excel into Corticon)

  

There are actually 42  attributes each of which can be Y or N and the rulesheet has 47 defined rules

Running the completeness checker on this is somewhat amusing:

Took Studio many minutes to come up with this – but it did it!

And the ambiguity checker turns up 96 ambiguities among the 47 rules!!!

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 rulesheet is overwhelming, The real problem is the model is fundamentally wrong!When we showed this to the customer they said “Oh well those aren’t really ambiguities – they can’t occur in the real world”

The reality is that many of the attributes represent the state of work on one queue or another. Work cannot be in more than one queue at any one time. So basically the vocabulary is wrong! Restructuring the vocab makes a huge difference.

So what’s the solution?

Well, we have to capture somewhere in the rules the idea that queues are mutually exclusive as a real business rule not some hidden plumbing.

This can be done easily be creating a helper rule sheet (which by the way can also be checked for ambiguity) that expresses this knowledge and simply (if somewhat tediously) maps from several dozen Y/N attributes into a single (transient?) attribute that can take dozens of values.

Now the ambiguities arising from this simply vanish – we shouldn’t need a complicated way 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 vocab we’d end up with much simpler rules like this

We can further  improve the rules by repartitioning into smaller orthogonal ones – the very visual appearance of the original with all its gaps sort of indicates  how it should be divided up

For example rules 31 to 46 appear to form a discrete set dealing with the “move to HCO”:

Any ambiguities that might arise here are now false ambiguities arising from action 2 since the important action “move to HCO” is the same in all cases

If we could simply “hide” action 2 from the ambiguity checker then we’d be fine. I’m not sure in this case if the warnXXX are mutually exclusive or not – if they are then some more remodeling is needed and the rulesheet would be even simpler.

Unfortunately disabling action 2 does not prevent the ambiguity checker from including it.

Download

Download PDF version