Checking sets and evaluators

Checking sets represents points in the job at which issues can be raised. For each checking set, evaluator classes determine whether or not to create underwriting issues. Each underwriting rule and its corresponding UWIssueType type has a checking set property.

The IPolicyEvaluationPlugin triggers policy evaluation. For each underwriting rule, this plugin uses the checking set to determine whether to add underwriting issues on a policy period. In the base configuration, this plugin calls evaluator classes to raise issues. The plugin then removes orphaned issues. Orphaned issues are underwriting issues that were generated at a checking set but are no longer an issue when that checking set runs at a later time.

If you need to change this plugin, see Policy evaluation plugin.

Evaluator Classes

The evaluator classes contain methods that raise underwriting issues based upon the checking set. In the base configuration, the default evaluator class, DefaultUnderwriterEvaluator.gs, raises underwriting issues for all lines of business. Each line of business implements its own evaluator class. For example, the evaluator for the personal auto line of business is PA_UnderwriterEvaluator.gs. These evaluator classes contain methods that raise underwriting issues for a checking set. For example, the onRenewal method in the default evaluator raises underwriting issues for the Renewal checking set.

Note: The evaluator classes ignore the Enabled setting of the underwriting rule defined in the Underwriting Rule user interface. Therefore, these classes raise underwriting issues regardless of the Enabled setting.

If you make code changes to the methods that raise underwriting issues, the code must adhere to the following:

The method must raise issues only for that checking set.
Only one checking set can raise a given underwriting issue type.

In the default configuration, the evaluators always raise auto-approvable issues regardless of whether the current (or other) user has sufficient authority to approve them. The evaluators always raise these issues because the issue needs to exist for the least-privileged user of the system. This approach separates the underwriting guidelines for things require approval from the approval levels assigned to users. For users with sufficient authority to approve the resulting issue, PolicyCenter usually does not display the issue in the user interface. (The user can easily view the issue by selecting different view options.)

You can configure the application to raise auto-approvable issues only when one or more users would be unable to approve them. One reason to do this would be to improve performance by reducing the number of auto-approvable issues being raised and silently approved.