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 Image Removed  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: Even if there is no default value is mainstream, the decision tables and/or other logic elements contain all the exceptions.

Now what if the exception is UNKNOWN?

in that case the attribute remains unknown.

But what if you would want your decision table to be complete and hold all possible alternatives?
Or even in an incomplete decision table with a default, what if there are situations where the derived attribute really is unknown?

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 * or ? to achieve this.
(one might argue that the symbol ? would have been a better candidate for that)

See the example below:

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 aged 18 or younger the discount cannot be inferred, a case handler should determine the discount on a case-by-case basis.