Summary of revisioning terminology

revisioning

How PolicyCenter tracks changes to a graph of objects in a policy through time, through both model time and effective time

branch (a policy revision)

The graph of objects with a PolicyPeriod entity instance at the root. Collectively a branch represents the truth of all effective dates in a contractual period as of the time it was made legally binding.

contractual period

A single policy term from the date the policy goes into effect (the effective date) to the date it expires (the expiration date). Generally speaking, a policy cannot have contractual periods that overlap in effective time, although if a policy is canceled or rewritten, contractual periods in a policy could overlap.

bound (promoted)

A branch that was made legally enforced, also known as legally binding.

model time

The real-world date and time that a version of the policy (or other object) was bound.

effective time

When something is relevant and enforced within a contractual period, independent of the model time. For example, if a year-long auto policy is canceled as of August 1, the effective date for the auto policy is January 1 through July 31. This is true independent of the date this change happens in model time.

branch ID and branch value

Foreign key to the PolicyPeriod entity instance that contains this entity instance. Within the same branch, all entities must share the same branch value. This value must be non-null. Gosu exposes this value as the BranchValue property, although the database column name is BranchID. If you use the query builder APIs, specify this property as BranchValue, not BranchID. For more information, see the BranchValue row in the table in Revisioning properties on PolicyPeriod subobjects

fixed ID

This ID describes one revisioned entity instance in multiple branches, or more than once in a branch with different effective/expiration dates. For example, suppose you need to change a car license plate number. The database contains two rows for the car: one for before the change, one for after. Both rows have the same fixed ID so that the system knows that it is two versions of the same car, not two different cars.

slice mode

Viewing a PolicyPeriod entity instance’s subobjects at a specific effective date, hiding entities that are not effective at that date. See Slice mode and window mode overview.

window mode

Viewing a PolicyPeriod entity instance’s subobjects, accessing data for all effective dates in that policy period’s start date and end date. See Slice mode and window mode overview.

out-of-sequence

A job issued after another policy change or other job but with an earlier effective date in the same contractual period. If there are conflicts with future-effective-dated branches, users can choose whether to merge changes into future time ranges in that contractual period, or to skip them. Users use the Out-of-Sequence Conflicts tab to merge no changes, some changes, or all changes. See Out-of-sequence jobs.

preemption

The situation when two concurrent changes are based on the same branch. When the second one finishes, the user must choose whether to apply changes as appropriate from recently-bound jobs into the active job that is about to be bound. Alternatively, the user can withdraw the current job. See Preempted jobs.

A preempted job can also contain out-of-sequence changes. You must handle both issues before binding the job.

merge changes

For an out-of-sequence job, PolicyCenter calculates all out-of-sequence changes that are conflicts. Given these out-of-sequence conflicts, the user can choose to merge those changes in the same branch but at later effective dates in the same policy period. Contrast with the term apply changes. See Details of merging and applying changes.

apply changes

PolicyCenter can calculate all differences between two branches A and B, including entity instance adds, removals, and property changes. PolicyCenter can reapply those differences (the “deltas”) to another branch C to recreate what changed between A and B. This occurs as part of handling preemption and processing changes to policies if there is a future renewal. Contrast with the term merge changes. See Details of merging and applying changes.