Looping, which involves revisiting, re-evaluating, and possible re-firing rules, and requires you to enable one of the looping modes, must be distinguished from another behavior that may appear to be similar.

You probably noticed Corticon's inherent ability to process multiple test scenarios at once. For example, a rule written using the Vocabulary term Cargo.weight is evaluated (and potentially fired) for every instance of Cargo encountered during execution. If a Ruletest contains four Cargo entities, then the rule engine tests the rule's conditions with each of them. If any of the Cargo entities satisfy the rule's conditions, then the rule fires. This could mean that the rule fires once, twice, or up to four times, depending on the actual data values of each Cargo. From the prior discussion of scope, a rule will evaluates 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 is nothing that you need to do to enable it. Note that this behavior is different from the modes of looping 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 four Cargo entities.

The advantage of this natural iteration is that you do not need to force it. The rule engine automatically processes all data that shares the same scope as the rule. If the Ruletest contains four Cargos, the rule will be evaluated four times. If the Ruletest contains 4000 Cargos, the rule is evaluated 4000 times. You do not write the rule differently in Corticon Studio.

But, this advantage can also be a disadvantage. What if you want rule execution to stop partway through its evaluation of a given set of entity data (a binding). What if, after finding a Cargo that satisfies the rule among the set (binding) of Cargo entities, you want to stop evaluation mid-stream? In normal operations, this is not possible.

Here is a simple example.

Figure 1. Rulesheet and Ruletest, no threshold condition, CaPT disabled

In the preceding example, no threshold condition, CaPT disabled, you 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 evaluated all three Things, but finding only two that satisfy the rule's condition, only fires twice. This iteration happened automatically.

What if you 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 before firing for Thing[3]. Is that possible? You might think the following Rulesheet accomplishes this goal.

Figure 2. Rulesheet and Ruletest, threshold condition added, CaPT disabled

The example in this figure includes two changes: Thing.selected is defaulted to false in the Nonconditional rule (Action row A0), and a second Condition row checks for Thing.selected = false as part of rule 1. This is called a threshold condition.

You might 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 you see in the adjacent Ruletest, this is not the case. The reason is that Thing[3] is an 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 you to interrupt processing of the binding. You activate this option by selecting the rule column involved, and then from the Corticon Studio menu bar, choose Rulesheet > Rule Columns(s) > Use Condition as Processing Threshold.

When selected, CaPT causes the rule column header to display in bold type, as shown, circled in orange:

Figure 3. 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 you re-ran this Ruletest, you might see Thing[3] evaluated first, in which case rule execution stops 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.