Collection operators are powerful parts of the Corticon Rule Language. In some cases, they may be the only way to implement a particular business rule. For this reason, another example is provided.

Business problem: An auto insurance company has a business process for handling auto claims. Part of this process involves determining a claim’s validity based on the information submitted on the claim form. For a claim to be classified as valid, both the driver and vehicle listed on the claim must be covered by the policy referenced by the claim. Claims that are classified as invalid will be rejected, and will not be processed for payment.

From this short description, extract the primary business rule statement:

  1. A claim is valid if the driver and vehicle involved in a claim are both listed on the policy against which the claim is submitted.

In order to implement the business rule, the following UML Class Diagram is proposed. Note the following aspects of the diagram:

  • A policy can cover one or more drivers
  • A policy can cover one or more vehicles
  • A policy can have zero or more claims submitted against it.
  • The claim entity was denormalized to include driverName and vehicleVin .
    Note: Alternatively, the Claim entity could have referenced Driver.name and Vehicle.vin (by adding associations between Claim and both Driver and Vehicle), respectively, but the denormalized structure is probably more representative of a real-world scenario.
Figure 1. UML Class Diagram
This model is realized in Corticon Studio as:
Figure 2. Vocabulary for insurance claims

Model the following rules in Corticon Studio, as shown:

  1. For a claim to be valid, the driver’s name and vehicle ID listed on the claim must also be listed on the claim’s policy.
  2. If either the driver’s name or vehicle ID on the claim is not listed on the policy, then the claim is not valid.
Figure 3. Rulesheet for insurance claims
This appears very straightforward. But a problem arises when there are multiple drivers or vehicles listed on the policy. In other words, when the policy contains a collection of drivers or vehicles. The Vocabulary permits this scenario because of the cardinalities that were assigned to the various associations. This problem is demonstrated in the following Ruletest:
Figure 4. Ruletest input for insurance claims
Notice in the Rulestest that there are three drivers and three vehicles listed on (associated with) a single policy. When you run this Ruletest, you see the results:
Figure 5. Ruletest output for insurance claims

As you can see from the Ruletest results, the way Corticon Studio evaluates rules involving comparisons of multiple collections means that the validClaim attribute may have inconsistent assignments – sometimes true, sometimes false (as in this Ruletest). It can be seen from the following table below that, given the Ruletest data, 4 of 5 possible combinations evaluate to false, while only 1 evaluates to true. This conflict arises because of the nature of the data evaluated, not the rule logic, so Studio’s Conflict Check feature does not detect it.

Claim. driverName Claim.policy. driver.name Claim. vehicleVin Claim.policy. vehicle.vin Rule 1 fires Rule 2 fires Rule 3 fires validClaim
Joe Joe 123-ABC 123-ABC X True
Joe Sue X False
Joe Mary X False
123-ABC 987-XYZ X False
123-ABC 456-JKL X False
The existential quantifier will be used to rewrite these rules:
Figure 6. Rulesheet with rules rewritten using the existential quantifier

This logic tests for the existence of matching drivers and vehicles within the two collections. If matches exist within both, then the validClaim attribute evaluates to true, otherwise validClaim is false.

Now the same Ruletest data as before is used to test these new rules. The following figure shows the results:

Notice that only one rule fired, and that validClaimwas assigned the value of true. This implementation achieves the intended result.