With the two rules expanded into four subrules, most of the Cross Product is displayed. Click the Check for Conflicts button in the toolbar.

Figure 1. Conflict revealed by the Conflict Checker
Note: The mechanics of confict checks are described in the Tutorial: Basic Rule Modeling topic Analyze rules .
Note: Refresher about conflict discovery and resolution: On a Rulesheet, click Check for Conflicts , and then expand the rules by clicking Expand Rules . Expansion shows all of the logical possibilities for each rule. To resolve conflict, either change the rules, or decide that one rule should override another. To do that, in the Overrides row, at each column intersection where an override is intended, select the one or more column numbers that will be overridden when that rule fires. Click Check for Conflicts again to confirm that the conflicts are resolved.

In this topic, the intent is to correlate the results of the automatic conflict check with the problems we identified first with the flowchart method, and then later with test cases. Subrules 1.1 and 2.1, the subrules highlighted in pink and yellow in Figure 1, correspond to the intersection of column 1 and row 1 of Rule 2 Expected Outcome or test case #1 in Test Cases Extracted from Cross Product. But note that Corticon Studio does not instruct the rule writer how to resolve the conflict; it alerts the rule writer to its presence. The rule writer, ideally someone who knows the business, must decide how to resolve the problem. The rule writer has two basic choices:

  1. Change the Actions for one or both rules. You could change the Action in subrule 1.1 to match 2.1 or vice versa. Or, you could introduce a new Action, say riskRating = medium, as the Action for both 1.1 and 2.1. If either method is used, then the result will be that the Conditions and Actions of subrule 1.1 and 2.1 are identical. This removes the conflict, but introduces redundancy, which, while not a logical problem, can reduce processing performance in deployment. Removing redundancies in Rulesheets is discussed in the How to optimize Rulesheets topics.
  2. Use an Override. Think of an override as an exception. To override one rule with another means to instruct the rules engine to fire only one rule even when the Conditions of both rules are satisfied. Another way to think about overrides is to refer back to the discussion surrounding the flowchart in Flowchart with two dependent Rules. At the time, it was unclear which decision should execute first. No priority was declared in the rules. But, it made a big difference how our flowchart was constructed and what results it generated. To use an override here, select the number of the subrule to be overridden from the drop-down box at the bottom of the column of the overriding subrule, as shown circled in the following figure. This is expressed as “subrule 2.1 overrides 1.1”. It is incorrect to think of overrides as defining execution sequence. An override does not mean “fire rule 2.1 and then fire rule 1.1.”  It means “fire rule 2.1 and do not fire rule 1.1”.
Figure 2. Override entered to resolve conflict

An override is essentially another business rule, which should to be expressed somewhere in the Rule Statements section of the Rulesheet. To express this override in plain English, the rule writer might choose to modify the rule statement for the overridden rule:

This modification successfully expresses the effect of the override.

If you are ever in doubt as to whether you have successfully resolved a conflict, click the Check for Conflicts button again. The affected subrules should not highlight as you step through any remaining ambiguities. If all ambiguities were resolved, then you see the following window:

Figure 3. Conflict Resolution Complete
Note: How does one rule override another rule? To understand overrides, the first concept to learn is condition context. The condition context of a rule is the set of all entities, aliases, and associations that are needed to evaluate all the conditional expressions of a rule. The second concept is the override context. The override context is defined using set algebra. The override context of two rules is the intersection of the two rule’s condition contexts. To evaluate the override, the set of entities that fulfill the overriding rule’s conditions are trimmed to the override context and recorded. Before the conditions of the overridden rule are evaluated, the entities that are part of the override context are tested to determine if they recorded; if so, then the rule is overridden, and processing of the rule with those entities stopped. If the override context is empty, then any execution of the overriding rule will stop all executions of the overridden rule.

Use overrides to handle conflicts that are logical dependencies

Overrides can be used for more than just conflicting rules. While the basic use of overrides is in cases where rules are in conflict to allow the modeler to control execution, it is not the only use. The more advanced usage applies cases where there is a logical dependency—cases where a rule might modify the data so that another rule can also execute. This type of conflict is not detected by the conflict checker.

Consider a simple Cargo Rulesheet:


When tested, the first rule is triggered, and its action sets a value that triggers rule 2:

The Ruletest result shows that the value set in the first rule's action modified the data so that the change in the condition's value triggered the second rule. If this effect is not what is intended, an override can be used. The use of an override here ensures that the modification of data will not trigger execution of the second rule; they are mutually exclusive (mutex). When an override is set on rule 1 that specifies that, if it fired, it should skip rule 2...


... the rules produce the preferred output:


If these rules were re-ordered, then the override would be unnecessary.