Page History

  What if in certain situations, an attribute must be set to UNKNOWN in a decision table?

One could argue that to achieve this, the default should be set to unknown (a.k.a. no default is specified) and the situations in which the attribute should remain unknown should not be part of the decision table. This works fine, since a decision table The order in which logic is inferred is set in Blueriq and explained in Order and hierarchy in knowledge elements. In many cases, a business engineer will create a default value for an attribute - being the most frequent value. Decision tables and/or other logic elements will infer the value of that attribute and if no inference is applicable, the default value is chosen. In short: default value is mainstream, the decision tables and/or other logic elements contain all the exceptions.

Now what if the exception is UNKNOWN?

But what if you would want your decision table to be complete and hold all possible alternatives? In that case, it must be possible to let the decision table set an So in most cases we know the value of an attribute, for instance 37, and in some specific cases it is unknown. In these situations, an action alternative will set the attribute to unknown, using the symbol * to achieve this.
(one might argue that the symbol ? would have been a better candidate for that) .

See the example below:

Image Added

The example above should be read as follows: For males, the discount for some fictitious product is 5%, 7% or 10%, depending on the age of the applicant. For females over 18 the percentage is 5%. For females under 18 the discount cannot be inferred, a case handler should determine the discount on a case-by-case basis.