Out-of-sync policy data

Availability and requiredness logic

In PolicyCenter, a policy is represented as a hierarchy of objects. The hierarchy includes coverables, coverages, questions, modifiers, exposures, exclusions, and conditions. Typically, these objects do not exist independently from one another. Rather, the product definition defines logic that identifies how the state of one object can determine whether another object must or must not exist.

This type of logic typically falls into two categories: availability logic and requiredness logic.

Availability logic identifies when a given object is available or unavailable, depending on the state of another object. For example, a Personal Auto product for the US could have logic that states a "PIP - Oregon" coverage is available for a vehicle only if the vehicle is garaged in Oregon. Thus:

  • The coverage is available if the vehicle is in Oregon.
  • The coverage is not available if the vehicle is not in Oregon.

Requiredness logic identifies when a given object is required, depending on the state of another object. For example, a Personal Auto product could have logic that states if the value of a vehicle is over $50,000, then a "no drivers under the age of 25" exclusion is required. Thus:

  • The exclusion is required if the vehicle's value is over $50,000.
  • The exclusion is not required if the vehicle's value is $50,000 or less.

Out-of-sync policies

When you create a policy through Cloud API, there is no requirement as to the order in which objects are created or modified. As a result, the structure of a policy may become out-of-sync. An out-of-sync policy is a policy which has objects or logic that are inconsistent with each other.

There are two primary ways in which a policy can become out-of-sync: inconsistency with availability logic, and inconsistency with requiredness logic.

Inconsistency with availability logic

Availability calculations are cached. This means that the set of available fields, coverages, coverage terms, and so on reflect what was available when the object was created or when the data was last synced. If you change an object without synchronizing the data, the availability calculations could identify that something is available when it should not be, or that something is not available when it should be. This can prevent you from adding allowed objects to the policy. It can also fail to prevent you from adding prohibited objects to the policy.

For example, suppose there is a Personal Auto product for the US with logic that states:

  • "PIP - Oregon" coverage is available for a vehicle only if the vehicle is garaged in Oregon.
  • "PIP - Washington" coverage is available for a vehicle only if the vehicle is garaged in Washington.

You create a vehicle in Oregon. The availability calculations for the vehicle are cached, indicating that you can add "PIP - Oregon" coverage. Later, you change the vehicle's location to Washington. At this point, "PIP - Oregon" coverage should not be allowed, and "PIP - Washington" coverage should be allowed. But because the availability calculation was cached when the vehicle was created, "PIP - Washington" coverage is not allowed, and "PIP - Oregon" coverage is.

Inconsistency with requiredness logic

When one object is created, other objects may be required and may be created automatically. However, if the state of the first object is changed, the related objects are not updated automatically.

For example, suppose that a Personal Auto product has logic that states if the value of a vehicle is over $50,000, then a "no drivers under the age of 25" exclusion is required. You create a vehicle whose value is under $50,000. The exclusion is not required and not created automatically. Later, you change the value of the vehicle to more than $50,000. At this point, the exclusion is required, but it is not created automatically.

This type of out-of-sync data may not prevent you from building the policy. But when you attempt to quote the policy, quoting validation fails because required objects are missing.

Resolving out-of-sync data

When a policy's data becomes out-of-sync, you can fix the situation by synchronizing the data. The Job API includes a set of /sync endpoints that synchronize job data. For more information, see The /sync endpoints.

You can also use a set of query parameters to defer validation. This gives you the ability to suppress validation checks while the policy is known to be in an inconsistent state. For more information, see Deferring validation.