The part of Corticon Studio that checks for data type mismatches (along with all other syntactical problems) is the Parser. The Parser ensures that whatever is expressed in a Rulesheet can be correctly translated and compiled into code executable by Corticon Studio's Ruletest as well as by the Decision Service. Because this is a critical function, much effort was put into the Parser's accuracy and efficiency. But rule modelers should understand that the Parser is not perfect, and cannot anticipate all possible combinations of the rule language. It is still possible to “slip one past” the Parser. Here is an example:

Figure 1. LHS and RHS resolve to integers

In the preceding figure, there is an assignment expression where both LHS and RHS return Integers under all circumstances. But making a minor change to the RHS throws this result into confusion:

Figure 2. Will the RHS still resolve to an integer?

The minor change of adding a division step to the RHS expression has a major effect on the data type of the RHS. Prior to modification, the RHS returns an Integer, but an odd Integer! When an odd Integer is divided by 2, a Decimal always results. The Parser is smart, but not smart enough to catch this problem.

When the rule is executed, what happens? How does the Decision Service react when the rule instructs it to force a Decimal value into an attribute of type Integer? The server responds by truncating the Decimal value. For example, if integer2 has the value of 2, then the RHS returns the Decimal value of 2.5. This value is truncated to 2 and then assigned to integer1 in the LHS.

Looking at this rule in isolation, it is not difficult to see the problem. But, in a complex Rulesheet, it may be difficult to uncover this sort of problem. Your only clue to its existence may be numerical test results that do not match the expected values. To be safe, iut is a best practice to ensure the LHS of numeric calculations has a Decimal data type so no data is inadvertently lost through truncation.