Task 4: Selecting or aggregating values from multiple rules

You learn about using interaction policies to select and aggregate values.

In Task 1, decision logic consistency was achieved through nonoverlapping rule sets, where at most one rule applies to each case. Two rules are nonoverlapping when their applicable case sets do not intersect. They are called overlap-free rule sets.

Consider the following decision table, similar to the conflicting rows example from Task 1:

Figure 1. Decision table with overlapping rows
Decision table with overlapping rows

Rows 1 and 5 both target beginners in landscape photography with high budgets. Unlike the table from Task 1, both rows propose the same APS-C sensor format. While the rows overlap, their decisions don't conflict: either or both can be applied.

Achieving overlap-free rule sets is challenging. Overlaps between two rules can be resolved by replacing them with three rules:

  • A rule for cases where both overlapping rules apply. The rule action needs to be specified.
  • A rule for cases where only the first rule applies. This rule has the same action as the first rule.
  • A rule for cases where only the second rule applies. This rule has the same action as the second rule.

This approach is tedious, creating complex conditions and increasing the rule count. A simpler solution is to tolerate overlaps.

Conflict-resolution policies

When overlaps are tolerated, multiple rules may apply to a case. Since each rule determines a decision node value, you need a method to select one candidate value or aggregate them into a unique result. It is achieved through an interaction policy.

For nonconflicting overlapping rules like the preceding example, resolving overlaps is unnecessary. Selecting the first candidate value suffices by using the First rule applies interaction policy.

Consider the conflicting rows table from Task 1. Here rows 1 and 5 propose different sensor formats for beginners in landscape photography with high budget: APS-C or Micro Four Third. The First rule applies policy selects APS-C as the decision node value.

Figure 2. Decision table with conflicting rows
Decision table with conflicting rows

Rule order determines precedence: each rule takes priority over subsequent rules. While common, this policy does not address all use cases. When rule order does not express precedence, all candidate values need to be retained by using the Collect all values policy. This policy can be used in multi-valued nodes only. Multi-valued nodes can take a list of values and the same value can appear multiple times in the list.

If applied to the decision table with conflicting rows (fig. 2), the Collect all values would return { APS-C, Micro Four Third }. If applied to the decision table with overlapping rows (fig. 1), it would return { APS-C, APS-C }. The number of retained values equals the number of applicable rules, including duplicates.

Note: Changing node cardinality impacts all direct successor decision logic: they must either select from the list or process all values. In the camera example, this could result in a multi-body camera system, common among photographers.

There are specific conflict-resolution policies for decision nodes with a numerical output type. They work with single-valued decision nodes:

  • The Choose smallest value policy selects the minimum candidate value.
  • The Choose greatest value policy selects the maximum candidate value.
  • The Sum all values policy computes the sum of all candidate values.

Other selection and aggregation methods, such as averaging, arg min, or arg max, can be implemented by combining the Collect all values policy with subsequent decision logic. This approach leverages the full expressiveness of the rule language to construct custom aggregation methods.

The Collect all values and Sum all values policies require specific action syntax. Instead of setting the decision variable value, rules add values to it, improving readability for the rule author.

Table 1. Action syntax requirements
  set decision to... add ... to decision
Single-valued
  • First rule applies
  • Choose smallest value
  • Choose greatest value
 Sum all values
Multi-valued N/A Collect all values

Exercise 1: First rule applies policy

  1. Import the Step4 solution for Decision Modeling practice tutorial sample from the New decision service wizard. For more information about importing samples, see Building decision services.
  2. Open the Step 4 - Exercise 2 decision model.
  3. Create a new decision table named DT with overlapping rows in the sensor format node.
  4. Populate the table with values from the Decision table with overlapping rows (Fig. 1) available above.
  5. Go back to the Logic tab and make sure the First rule applies policy is selected.
  6. Go to the Run tab.
  7. Create a test data set with the following values:
    • level: beginner
    • subject: landscape
    • budget: 2000
  8. Click Run and note the proposed sensor format.
  9. Go back to the Logic tab and select the Rules are applied in sequence policy.
  10. Go back to the Run tab and run the test data set again. Does is return the same sensor format?

Exercise 2: Collect all values policy

  1. Import the Step4 solution for Decision Modeling practice tutorial again and open the Step 4 - Exercise 2 decision model.
  2. Click the sensor format decision node.
  3. In the Details tab, click Output is a list.
  4. In the Logic tab, create a new decision table named DT with conflicting rows.
  5. Populate the table with values from the Decision table with conflicting rows (Fig. 2) available above.
  6. Right-click the action column header and select Define column...
  7. Verify that the action definition uses the add <sensor format> to decision construct and not the set decision to <sensor format> construct.
  8. Go back to the Logic tab and select the Collect all values policy.
  9. Go to the Run tab.
  10. Create a test data set with the following values:
    • level: beginner
    • subject: landscape
    • budget: 2000
  11. Click Run. How many sensor formats are returned? How many rows were applied to sensor format in the run history?

Lessons learned

The previous tasks introduced three decision logic types, each with an overlapping-rules variant.
Complete and overlapping rule set
  • Each rule makes independent decisions based on available information for all applicable cases.
  • At least one rule applies in every case.
  • An interaction policy selects or aggregates decisions from applicable rules.
Overlapping and incomplete rule set
  • Each rule makes independent decisions based on available information for all applicable cases.
  • The decision is undefined when no rules apply.
  • An interaction policy selects or aggregates decisions when at least one rule applies.
Overlapping rule set with a default value
  • Each rule makes independent decisions based on available information for all applicable cases.
  • The default value is used when no rules apply.
  • An interaction policy selects or aggregates decisions when at least one rule applies.

Unlike the DMN standard, these decision logic types are descriptive rather than normative. In Decision Intelligence, there is no completeness indicator enforcing completeness and no unique policy requiring overlap-free rules. Whereas hit policies are defined at the decision table in DMN, interaction policies in Decision Intelligence are defined at the decision logic level and are applicable to multiple rules and decision tables.

Limitations

All decision logics discussed assume that each rule can make independent decisions based on available information for all applicable cases. Well-structured decision-making problems with intermediate decisions and submodels should meet this assumption.

However, when a single decision logic makes multiple decisions, this assumption is no longer valid.