Rule Ambiguity When Variables are Involved

When you have two rules like this

if age <= 65 then eligible=F
if age >= 65 then eligible=T

Its fairly easy to detect that there's a conflict when age is exactly 65. But what about these rules where threshold is a variable

if age <= threshold then eligible=F
if age >= threshold then eligible=T

The value of threshold won't be known until the rules execute. But we can still flag it as a possible conflict - whatever the value of threshold is when the rules execute, the rules are ambiguous when age is exactly equal to the threshold. However, that assumes that the value of threshold hasn't changed between executing the first and second rules. If it changes then all bets are off. If you put all the rules for eligible in one DT you can avoid this issue.

What about these rules

if age <= 65 then eligible=F
if age >= threshold then eligible=T

You cannot immediately tell if there is a conflict or not. It depends in the value of threshold at the time the rule is executed. If threshold is over 65 (at execution time) then there is no conflict. If its <=65 then there is a conflict.

But we are trying to detect problems BEFORE execution (at design time) Is there anything we can do here to detect a problem? There are two situations The value of threshold will be passed in as part of the data at execution time (in the future) The value of threshold is determined by rules in the decision (which we know now)

In case 1 there's not much we can do at design time - we have no control over what values might be passed in later to the decision. UNLESS - the rule designer can give some hints (or constraints) on the permissible values of threshold (we have a constraint type DT that can be used for this purpose) For example, if at design time the author tells us (in the rule model) that threshold >65 is a constraint that must not be broken then we can say the rules are not ambiguous. Now that doesn't stop someone passing a value of 18 for the threshold at execution time. BUT the design time constraint (that threshold >65) will have been broken at execution time and the decision will be able to stop before erroneous results are produces

In case 2 if the value of threshold is set somewhere in the rules then we can look at all the values its gets set to and see if there are any that would cause a conflict. This can get tricky since the rules that set threshold could themselves be the subject of ambiguity.

Anyway, I'm curious to know what you guys think about this situation and whether you have any clever ideas. I'm pretty sure no other tool attempts this kind of analysis

NOTE instead of a variable like threshold we might equally have a function call like getThreshold(x,y,z). This would of course just be a decision table so maybe we can look at its internal rules to see what values are returned