Correct The Register (CTR)

Correcting the Register (or CTR for short) is the process by which the current or a previous version of the live registry data is amended. Refer to Correct the register section for the full documentation.

This page relies heavily on the concepts of the business service and versioning and these should be read and understood fully to ease the absorption of this content on CTR.

Correction vs. maintenance

Unlike a standard maintain service a correction service is used when there is a mistake in the registry data that is live on the register – in these cases the version itself needs to change so it no longer exists in its current state, even historically. In other words the live version of the registry data doesn’t reflect the real world picture of the entity as it ever was, so needs to be fixed without introducing a new version and leaving the existing data as a previous version that you would get from a standard maintain service. Also, unlike maintain services, corrections can be applied to previous live versions on the register, not just the current live version. Corrections should only be available to internal users with adequate security clearance i.e. a specific security role.

Maintain services usually have one or more filings associated to them which are typically viewable by the public and/or internal users and those who have authority over the registry data. Corrections also have filings associated to them, so changes made via a correction are still tracked and can be viewed, but these are often more restricted than filings for maintain services and hidden from the public and even users with authority over the registry data (although this is configurable via the filing instruction privacy type).

A correction is used by special authorised internal users to fix mistakes on live registry data so that it accurately reflects the real-world state for the period it relates to. These changes are often invisible to insufficiently authorised users.

Correction versioning

As outlined on the versioning page, corrections are tracked via the sibling version dimension. This section provides examples to illustrate versioning specifically related to corrections.

Example: Correct non-live maintain version

In this scenario we start with an activated service instance live on the register. One maintain service was then started, saved, reloaded for more edits and then applied. A second maintain service was then started and applied. A correction service against the live version relating to the first applied maintain service is then performed.

To help, this scenario has been broken down into two as follows:

• the state prior to the correction being started
• the state after the correction has been applied

Take your time looking at the details and diagram relating to state 1 until you are comfortable with the details before moving on to the second state below.

Also note, when it says "X->Y" it means the value of property X is the id of service transaction Y.

State 1: Before the correction is performed

Prior to the correction being started there are three service instances involved with service transactions relating to them as follows prior to the maintain service being applied:

• S1 – Initial registration service instance
  • 1 – The only service transaction for this instance, containing the first version of registry data that was live on the register (nextVersionId->3)
• S2 – A maintain service based off S1
  • 2 – The first service transaction relating to S2 which has been saved & exited, but since superseded by 3 (previousVersionId->1, nextSiblingId->3)
  • 3 – The second service transaction that was loaded in, edits made then applied, containing the second version of registry data that was live on the register (previousVersionId->1, previousSiblingId->2, nextVersionId->4)
• S3 – The second maintain service based off S2, current version live on the register
  • 4 – The only service transaction for this instance, containing the registry data that is currently live on the register (previousVersionId->3)

Note: the lighter blue area at the top of the diagram below shows service transactions that are part of one of these service instances but are not a live version on the register. The dark blue-bordered arrow contain the activated service transactions that make up the live versions on the register.

State 2: After the correct service has been started and applied

The correction to S2 is then performed, which leaves the original three plus one new service instances with service transactions relating to them as follows:

• S1 – Initial registration service instance
  • 1 – The only service transaction for this instance, containing the first version of registry data that was live on the register (nextVersionId->3 5)
• S2 – A maintain service based off S1
  • 2 – The first service transaction relating to S2 which was saved & exited then superseded by 3 (previousVersionId->1, nextSiblingId->3)
  • 3 – The activated service transaction for S2 that was corrected and has now been shunted out to no longer be a live version on the register (previousVersionId->1, previousSiblingId->2, nextVersionId->4, nextSiblingId->5)
• S3 – The second maintain service based off S2, current version live on the register
  • 4 – The only service transaction for this instance, containing the registry data that is currently live on the register (previousVersionId->3 5)
• CTR – The correction service correcting S2, a live previous version on the register, now applied and itself a live previous version on the register
  • 5 – The only service transaction for this instance, now containing the second version of registry data that was live on the register (previousVersionId->1, previousSiblingId->3, nextVersionId->4)

Note: again, the lighter blue area at the top of the diagram below shows service transactions that are part of one of these service instances but are not a live version on the register. The dark blue-bordered arrow contain the activated service transactions that make up the live versions on the register.

Configuration

Corrections are configured like any other business service and form with the exception that the business service mode is one of:

• Correct – corrects the current or a previous live version of existing registry data
• CorrectAdd – inserts a new live version after the current or a previous live version of existing registry data

This is enough to ensure the registry data and versioning as outlined in the section above is applied as expected.

Other than that the correction business service can be configured via the usual means, including any special security roles, as well as the related filing instruction privacy setting if applicable.

In terms of form configuration, again corrections are configured as normal, although their layout tends to differ slightly in that they often present both the registry data as well as instance data plus any filing details for editing as well. This is typically done making use of existing wizard and filing configuration components. Most other configuration components also take corrections into account when appropriate, so when used should handle correction details seamlessly. Some custom rules may be required to ensure details are shown as expected and are editable if necessary depending on the configuration and business rules, but otherwise no special treatment should be required.