Basic revisioning structure of a policy

Think of a policy as a container of contractual periods, each with a specific range of effective time. A contractual period is a single policy term from the date the policy goes into effect (the effective date) to the date it expires (the expiration date). For example, if a homeowners policy has a year long period, calendar year 2008 is one contractual period. If that 2008 policy is modified, then PolicyCenter saves each version. Each version represents the same policy in the same period.

The period can be any length and start on any day of the year. A period can be six months, three months, or any arbitrary length. The main rule is that one policy cannot have contractual periods that overlap in effective time, not including sections of contractual periods where a policy was canceled or rewritten.

Note: The contractual periods might overlap if there was a cancellation and a new contractual period was created after the cancellation date. However, their effective time (the non-canceled time range) for the periods must never overlap.

When a policy renews, the renewal job (policy transaction) creates another contractual period with a different range of effective time. For example, a renewal job for a 2008 policy period would clone the data for that policy for a new contractual period with different effective dates for 2009.

Each one of these snapshots of the policy for one period is a branch. PolicyCenter represents each branch in the contractual period as a PolicyPeriod entity instance. This entity instance is a container for the rest of the objects on the policy, for example vehicles, coverages, and policy contacts. PolicyCenter assigns each period a unique period ID, which is stored in a PolicyPeriod in its PeriodID property. That value identifies and links all branches for that contractual period.

As part of making a branch legally enforced, PolicyCenter performs a process called binding. This process is also called binding a branch or promoting a branch. The result is a promoted branch or a bound branch. When binding a branch, PolicyCenter sets the ModelDate property in the PolicyPeriod to the real-world date it was bound. Additionally, if there are earlier versions of this PolicyPeriod entity instance in the contractual period, PolicyCenter increments the PolicyPeriod model number (the ModelNumber property). It sets it to one greater number than the most recently bound earlier revision in this contractual period. These model time properties let PolicyCenter track what is the legally-enforced version of the policy for that period.

Each PolicyPeriod also includes a MostRecentModel property that is true if this PolicyPeriod is the most recently bound branch for this contractual period. When a branch is bound, if there was another branch in that contractual period, PolicyCenter sets two things. First PolicyCenter sets this property to false on the previous branch and sets it to true on the newest branch in the same database transaction. Technically, this is redundant with checking for the highest model number (ModelNumber) for all PolicyPeriod entities in this contractual period (those that share the same PeriodID). However, this property is provided to simplify queries that work only with the latest bound branch in any given period. The MostRecentModel property is very useful for writing reporting queries.

If a PolicyPeriod cannot be modified because the branch is bound, withdrawn, or discarded, PolicyCenter sets its Locked property to true. This locking prevents accidental changing of that PolicyPeriod or any of its subobjects. PolicyCenter enforces this locking at the application level.

Note: You can customize application logic before promoting a branch. For more on this topic, see Policy period plugin.

Subobjects

Every policy revision branch is represented by a PolicyPeriod entity instance at the root of a complex graph of subobjects such as policy lines, vehicles, coverages, and many others. The entire hierarchy of Guidewire entities are cloned in the database into new rows during policy changes, renewals, or other jobs that result in cloning everything in a branch. In contrast, a submission job’s branch is not cloned from another branch.

PolicyCenter must identify that some rows in the database represent the same real-world thing. This is true for the following cases:

  • Across model time – PolicyCenter typically represents one object (such as a driver or a vehicle) more than once across model time. PolicyCenter creates one instance each time it copies the branch due to a policy change job or other job. To understand differences between two historical periods, PolicyCenter needs to know they represent the same object not multiple different objects.
  • Multiple periods – One object (such as a driver or a vehicle) might exist in multiple contractual periods. To understand differences between two periods, PolicyCenter needs to know they represent the same object not multiple different objects.
  • Across effective time – Some objects change across effective time within one branch. To understand that these are the same object across effective time, PolicyCenter must know these represent the same object, not different objects. For example, suppose you have a car on a policy and then need to change the license plate number. The database contains two rows for the car: one with the original license plate number, one with the new license plate number. This topic discussed further in Structure of revisioning across effective time.

For these reasons, PolicyCenter knows which rows represent the same object because they share an ID called a fixed ID, stored in its FixedID property. If the fixed IDs for two vehicles match, they are versions of the same vehicle, not two different vehicles. If the fixed IDs do not match, they represent different vehicles.

Note: In previous releases of PolicyCenter, the fixed ID was called a revision-independent ID (RIID).

Each subobject also contains a foreign key to the PolicyPeriod entity instance that contains it. This foreign key is called a branch ID and is stored in the subobject’s BranchValue property. This foreign key always matches the PolicyPeriod entity instance’s Id property. Remember that this foreign key references the PolicyPeriod unique Id property, not the PeriodID property that identifies related PolicyPeriod entities in one contractual period.

The following diagram shows the structural relationship of simple policy with two contractual periods. Note in the diagram:

  • Within one contractual period, each PolicyPeriod entity instance shares the same period ID.
  • Each PolicyPeriod entity instance has a model number that increments for each revision in the contractual period each time a change is made in model time (real-world time).
  • Each subobject contains a branch ID that identifies its root PolicyPeriod entity instance, and it matches the PolicyPeriod.Id property
  • Each subobject has the same fixed ID when the subobject exists in multiple branches and even across contractual periods. For example, a car’s data that was modified has the same fixed ID in each branch that references it. The fixed ID is also the same in renewal periods if that car is still covered in the renewal period.