Example

Let's say that a person's income from an employment is modeled as Cúram Evidence. The income starts when a person starts an employment, and ends if the employment is subsequently terminated. The name of the employer is constant throughout the period of income, because the designer of the evidence structure made a design decision that if a person moves from one job to another, then the first employment comes to an end and a separate employment starts.

Over the lifetime of an employment, the income amount (i.e. the per annum pay) can vary, as the employee receives pay rises. Similarly, but independently, the person can be employed on a permanent or temporary basis, and this "employment status" can change over the lifetime of the employment. It is possible for the income's amount to change on the same date as the employment status, but a change in income amount can occur without a change in employment status, and vice versa.

The evidence designer designs an Income evidence entity as follows:

A rules designer then models a new "Income" rule class, extending the "ActiveInEditSuccessionSet" rule class, and adds rule attributes, identifying which have values that change over time (i.e. those which should be allowed to vary across different records in the same succession set):

Should be constant across records in the succession set:

Should be allowed to vary across records in the succession set:

The rules designer also identifies which rule attributes identify the "lifetime" of the Income:

and annotates the rule class to identify these rule attributes.

An administrator publishes the rule set changes, and then publishes a data configuration for Active/In-Edit Succession Set Rule Objects to map the Income evidence type to the new rule class. A case worker records some new Income evidence (for an employment which started on 1st January 2000).

Initially the evidence is "in edit" and its data is available to the Active/In-Edit Succession Set Rule Object Converter to populate a rule object. When evidence capture is complete, the case worker activates the evidence. No action is taken by the Active/In-Edit Succession Set Rule Object Propagator.

Over time, real-world circumstances change:

On each of these occasions, the case worker records a new version of the Income evidence, leading to the system storing a new 'EvidenceDescriptor'/'Income' pair of rows for the evidence data effective from each change date.

The Active/In-Edit Succession Set Rule Object Converter recognises that the three versions of evidence relate to a single succession set, and use the effective-dated data to change the timeline values for the attributes on the single rule object. The rule object data will be updated as soon as the changes are made, there will be no wait until the succession set is activated.

On 30th June 2002, the employment comes to an end and a case worker records the end date on the latest record in the succession set. The case worker inserts the changes, which cause the existing latest "EvidenceDescriptor"/"Income" pair to become "superseded" and a new pair to become "active". The Active/In-Edit Succession Set Rule Object Converter immediately updates the rule object to change its timeline values from 1st July 2002 (the day after the end of the employment).

Some time later, a review of the case finds that the entire history of the income has been recorded against the wrong person. All the evidence records for the Income are canceled by the caseworker, pending removal, which causes existing rule object to be removed. The case worker than realizes that he has canceled the Income record for the wrong person. He reverts the changes and the appropriate rule object gets re-created. The case worker now cancels the Income records for the correct person.

The evidence is re-recorded against the correct person (in a new succession set) and a new rule object created for the new succession set of income records. Note that the old rule object is removed and a new created before any of the evidence changes has been activated. The caseworker eventually activates the changes, causing no updates for the existing rule objects.