An Application Validation (AV) mode ruleset can reference all rules in a ruleset that is defined in the same application or a ruleset that belongs to any built-on application.
In this example, it is assumed that AV mode rulesets are used. Each shaded or unshaded cell represents an application and each name represents a ruleset. With AV mode, you have the ability to call rules both above and below the designated ruleset.
Ruleset |
Mode |
|---|---|
| LoanPricing | Can call all other rulesets listed. |
| LoanUnderwriting | Can call all other rulesets listed. |
| LoanPricingFW | Can call LoanUnderwritingFW but not shaded rulesets. |
| LoanUnderwritingFW | Can call LoanPricingFW but not shaded rulesets. |
This example uses a mixture of AV mode and Rule Validation (RV) mode. A ruleset name with brackets indicates a RV mode ruleset with its respective prerequisite. With RV mode, you are unable to call an AV mode ruleset not listed in the prerequisites.
Name |
Mode |
|---|---|
| LoanPricing | Can call all other rulesets listed. |
| LoanUnderwriting | Can call rules in all other rulesets including LoanPricing. |
| MyCoPL [MyCo] | Can call rules in MyCo but not in LoanUnderwriting, LoanPricing, LoanPricingFW, or LoanUnderwritingFW. |
| LoanPricingFW | Cannot call rules in MyCoPL, LoanUnderwriting, or LoanPricing. |
| LoanUnderwritingFW | Cannot call rules in MyCoPL, LoanUnderwriting, or LoanPricing. |
| MyCo[PRPC] | Cannot call rules in MyCoPL, LoanUnderwriting, or LoanPricing. |
As a best practice for design, your unlocked AV mode rulesets should belong to one Rule-Application, but can still belong to more than one version. This prevents AV mode rulesets from referring to rules that may not exist in all applications that the ruleset is contained in.
Alternately, rulesets should be refactored into applications that are included as built-on applications.
It is recommended that new rulesets use AV mode. However, if refactoring does not work, then the rulesetcan be set to RV mode.
Versioning in AV mode works similarly to how it does when using RV mode. Within a given ruleset name, you cannot call rules in a higher ruleset version. For example, rules in App:01-01-01 cannot reference rules in App:01-01-03 at design time. For versions across different ruleset names, the standard AV mode logic is applied.
A branched ruleset using AV mode can access all rulesets in an application, including other rulesets in the same branch and any other branches included in the same application definition. This means that all branches within a given application definition can refer to each other. Rules in non-branched rulesets cannot reference rules in any branch.
The validation mode for a branch ruleset, set as AV mode by default, can be changed. It is recommended that validation mode be kept the same as the mode used by the base ruleset, but this is optional.
A branched ruleset is initially set to the same validation mode as the non-branched ruleset. If the validation mode of the branched and non-branched rulesets do not match, a warning displays, because there is the potential for a conflict upon merging. Best practice recommends using the same validation mode for both the branched and non-branched ruleset instances for the same ruleset name.
Mobile and local rulesets have their own ruleset validation mode. If set to AV mode, a mobile or local ruleset can refer to all rules in the application (or built-ons). An application ruleset cannot explicitly refer to local or mobile rulesets unless they are added to the application.
Adding local or mobile rulesets to the base application ruleset is not recommended because non-local or non-mobile rulesets could call into the local/mobile rulesets.
Production rulesets get placed on top of the stack and can reference application rulesets, although application rules cannot directly reference a production ruleset. A non-production version of the rule must exist for validation.
These ruleset types cannot be set to AV mode.