Because the rule evaluates both Cargo and Aircraft in the context of FlightPlan, the rule has scope, which means that the rule evaluates only that data which matches the rule's scope. This has an interesting effect on the way the rule is evaluated. When the rule is executed, its scope ensures that the Corticon Server evaluates only those pairings that match the same FlightPlan. This means that cargo.weight is compared to aircraft.maxCargoWeight only if both cargo and aircraft share the same FlightPlan. This simplifies rule expression greatly, because it eliminates the need to specify which FlightPlan is referred to for each Aircraft-Cargo combination. When a rule has context, the system takes care of this matching automatically by sending only those aircraft - cargo pairs that share the same flight plan to be evaluated by the rule. And, because Corticon Studio automatically handles multiple instances as collections, it sends all pairs to the rule for evaluation.

Note: See the Collections topic for a detailed discussion of this subject.

To test this new rule, structure your Ruletest to correspond to the new structure of your rule and reflect the rule's scope. For more information about the mechanics of creating associations in Ruletests, see Add and edit association nodes and their properties and Create associations in the test tree

Finally, one FlightPlan is created for each Aircraft-Cargo pair. This means that a total of three FlightPlans are generated each night. Using the terms in your Vocabulary and the relationships between them, Figure 5 shows the possibilities. The rule evaluates these combinations and identifies any violations.

Figure 1. New Ruletest using flight plan as the rule scope

What is the expected result from this Ruletest?  If the results follow the same pattern as in the first Ruletest, you might expect the rule to fire nine times (three Aircraft evaluated for each of three Cargo shipments).

In the following figure you see that the rule fired only three times, and only for those Aircraft-Cargo pairs that are related by common flight plans. This is the result that you want. The Ruletest shows that there are no FlightPlans in violation of the rule.

Figure 2. Ruletest results using scope – note no violations

One final point about scope: it is critical that the context you choose for your rule supports the intent of the business decision you are modeling. At the beginning of the example, the purpose of the application was to check flightplans that have already been created. Therefore, the context of the rule was chosen so that the rule's design was consistent with this goal: no aircraft-cargo combinations should be evaluated unless they are already matched up using a common flight plan.

But what if the business purpose was different?  What if the problem trying to be solved is modified to: Of all possible combinations of aircraft and cargo, determine which pairings must not be included in the same flight plan.  The difference here is subtle but important. Before, you were identifying invalid combinations of pre-existing flight plans. Now, you are trying to identify invalid combinations from all possible cargo-aircraft pairings. This other rule might be the first step in a screening or filtering process designed to discard all the invalid combinations. In this case, the original rule you built, root-level context, is the appropriate way to implement the rule, because now you are looking at all possible combinations prior to creating new flight plans.