We want to distinguish looping, which involves revisiting, re-evaluating, and possible re-firing rules, and which requires you to enable one of the looping modes discussed above, from another behavior that may appear similar on the surface.
You have almost certainly noticed Corticon's inherent ability to process multiple test scenarios at once. For example, a rule written using the Vocabulary term Cargo.weight will be evaluated (and potentially fired) for every instance of Cargo encountered during execution. If a Ruletest contains 4 Cargo entities, then the rule engine will test the rule's conditions with each of them. If any of the Cargo entities satisfy the rule's conditions, then the rule will fire. This could mean that the rule fires once, twice, or up to four times, depending on the actual data values of each Cargo. We know from our prior discussion of Scope that a rule will evaluate all data that shares the same scope as the rule itself.
This iterative behavior is a natural part of the Corticon rule engine design – there's nothing special we need to do to enable it or turn it on. Note, that this behavior is different from the modes of looping discussed above because the Cargo.weight rule is not re-evaluated for a given piece of data. Rule execution is still single-pass. It is just that it makes a single pass through each of the 4 Cargo entities.
The advantage of this natural iteration is that we don't need to force it – the rule engine will automatically process all data that shares the same scope as the rule. If the Ruletest contains 4 Cargos, the rule will be evaluated 4 times. If the Ruletest contains 4000 Cargos, the rule will be evaluated 4000 times. We don't write the rule any differently in Corticon Studio.
But this advantage can also be a disadvantage. What if we want rule execution to stop part-way through its evaluation of a given set of entity data (which we call a binding). What if, after finding a Cargo that satisfies the rule among the set (binding) of Cargo entities, we want to stop evaluation mid-stream? In normal operation, this is not possible.
Here's a simple example.
Figure 162. Rulesheet and Ruletest, no threshold condition, CaPT disabled
In the example above, no threshold condition, CaPT disabled, we see a simple rule that sets thing.selected = true for all thing.aSize = 'small'. Notice in the adjacent Ruletest, that each small Thing is selected. Thing[2] and Thing[3] are both small, so they are both selected by the rule. The rule has evaluated all three Things, but finding only two that satisfy the rule's condition, only fires twice. This iteration happened automatically.
What if we wanted rule execution to stop after finding the first Thing that satisfies the rule? In other words, allow the rule engine to fire for Thing[2] but stop processing beforefiring for Thing[3]. Is that possible? You might think the following Rulesheet would accomplish this goal.
Figure 163. Rulesheet and Ruletest, threshold condition added, CaPT disabled
The example in this figure includes two changes: 1) Thing.selected is defaulted to false in the Nonconditional rule (Action row A0). And 2) a second Condition row checks for Thing.selected = false as part of rule 1. This is called a threshold condition.
You might be temped to think that when Thing[2] fires the rule, its value of selected (re-set to true) would be sufficient to stop further evaluation and execution of Thing[3]. But as we see in the adjacent Ruletest, that this isn't the case. The reason is that Thing[3] is an entirely separate entity within the binding, and is entitled to its own evaluation of rule 1 regardless of what happended with Thing[2]. The addition of the threshold condition accomplished nothing.
A special feature in Corticon Studio, called Use Condition as Processing Threshold (abbreviated as CaPT), allows us to interrupt processing of the binding. You activate this option by selecting the rule column involved, then from the Corticon Studio menu bar, choose Rulesheet > Rule Columns(s) > Use Condition as Processing Threshold.
Once selected, CaPT causes the rule column header to display in bold type, as shown below, circled in orange:
Figure 164. Rulesheet and Ruletest, threshold condition added, CaPT enabled
When CaPT is activated, it breaks out of the automatic binding iteration whenever an instance in the binding fails to satisfy the threshold condition. In this case, Thing[2], having just fired rule 1, no longer satisfies the threshold condition, and causes rule execution to stop before evaluating Thing[3]. If we re-ran this Ruletest, we might see Thing[3] evaluated first, in which case rule execution would stop before evaluating Thing[2].
Within a binding, sequence of evaluation of elements is random and may change from execution to execution. There is nothing about the binding that enforces an order or sequence among the bound elements.
