Anchor · Corrections

Satoshium Anchor · Corrections

Corrections define how Anchor repairs Anchor-owned errors while preserving the historical record of what was previously published, stored, or relied upon.

A Source Artifact change is not an Anchor Correction. Anchor corrects only information, provenance, integrity material, relationships, or metadata that Anchor itself recorded incorrectly.

Correction Principle

Correct forward. Preserve backward.

A Correction creates a new governed state without silently erasing the prior one.

Correction Boundary

Source Artifact Change ≠ Anchor Correction

Source Institutions correct their own artifacts. Anchor corrects only Anchor-owned records and integrity metadata.

Source Artifact Change

A revision, Correction, withdrawal, revocation, or new Version performed by the Source Institution under its own authority.

External Authority

Anchor Correction

A governed repair to incorrect Anchor-owned information while preserving the prior production state.

Anchor Authority

Correction Lineage

Preserves what was wrong, what changed, which Version carried the error, and which later Version or Integrity Reference resolves it.

Required

Subject Error

An error showing that the Integrity Reference was about the wrong integrity subject may require a new Integrity Reference rather than ordinary Versioning.

Material Boundary

Anchor-Owned Errors

Examples of Anchor-owned errors may include:

wrong Source-System Identifier
wrong Source Institution
wrong Source location
wrong Source Version metadata
wrong Representation Boundary
wrong canonicalization metadata
wrong Integrity Method metadata
wrong Integrity Value
wrong algorithm metadata
wrong timestamp
wrong signer / key reference
wrong external commitment reference
wrong relationship
wrong publication metadata
wrong lifecycle metadata

Source Changes Are Not Anchor Errors

The following do not become Anchor Corrections merely because they affect what Anchor references:

Source publishes a new Version
Source corrects its own content
Source withdraws a record
Source revokes a statement
Source changes lifecycle
Source changes canonical location
Source supersedes an artifact

Anchor may need Maintenance, Reverification, a new Anchor Version, or a new Integrity Reference—but the Source event remains Source authority.

Correction Decision Test

1. Is the disputed information Anchor-owned?
2. Was Anchor's recorded value incorrect at the time it was recorded?
3. Does the integrity subject remain the same?
4. Can the error be repaired through a new Anchor Version?
5. Or does the error reveal that Anchor preserved the wrong integrity subject?

Same subject + Anchor-owned error → Correction + new Anchor Version.
Wrong subject → new Integrity Reference, with lifecycle action on the flawed record.

Correction and Versioning

Same integrity subject + Anchor error
→ Correction
→ new Anchor Version

The Anchor Identifier remains stable because the underlying integrity subject remains the same.

Wrong Integrity Subject

Some errors cannot be repaired as an ordinary Version because they invalidate the identity premise of the original Integrity Reference.

wrong Source Artifact
wrong Canonical Representation
materially wrong Representation Boundary
wrong artifact package
wrong Source identity

Normal response:

flawed Integrity Reference
→ withdraw or supersede

correct integrity subject
→ new Integrity Reference
→ new Anchor Identifier

Correction Lineage

Every production Correction should preserve enough lineage to reconstruct:

affected Anchor Identifier
affected Anchor Version
error discovered
erroneous field / condition
prior value
corrected value
correction reason
corrected Anchor Version
effective time
related Verification / Maintenance event where applicable

Correction Record

Anchor may benefit from a separately identified Correction record if Corrections need durable citation independent of Version history.

Integrity Reference
↓ corrected_by
Correction Record
↓ applied_in
Later Anchor Version

Whether Correction Records receive their own permanent identifiers remains intentionally unfrozen until Procedures and first production use prove the need.

Correction Type

Correction Type is now proven to be a useful Controlled Value category.

Initial candidate categories include:

source_reference_error
representation_error
integrity_material_error
provenance_error
relationship_error
attribution_error
publication_metadata_error
lifecycle_metadata_error
other_anchor_metadata_error

These remain provisional until the first real Corrections demonstrate which distinctions materially affect procedure and reporting.

Enumeration Unfrozen

Severity

Anchor should not assume every Correction has the same operational impact.

Potential severity distinctions may eventually include:

clerical
material
integrity-affecting
subject-invalidating

No severity Controlled Value set is frozen yet. Production should prove whether severity adds durable value beyond Correction Type.

Clerical vs. Integrity-Affecting Error

A typo in non-material notes is not equivalent to an incorrect digest.

clerical metadata issue
≠
integrity material issue

Procedures may later allow different review thresholds while preserving the same correction lineage standard.

Integrity Value Correction

If Anchor stored the wrong Integrity Value for the correct Canonical Representation, the error is Anchor-owned.

correct subject
+ wrong Integrity Value
→ Correction
→ new Anchor Version

The prior incorrect value must remain visible in preserved Version history.

Representation Error

Representation errors require the Versioning subject test.

metadata describes boundary incorrectly
but actual governed subject was correct
→ may be Correction + new Version

wrong representation actually anchored
→ new integrity subject required

Relationship Error

If Anchor links the Integrity Reference to the wrong Source identifier, Correction, prior Version, superseding record, or commitment, that relationship error belongs to Anchor.

Corrected relationship lineage should preserve both the prior incorrect link and the corrected link through Version history or Correction records.

Provenance Error

If Anchor records provenance incorrectly, Anchor may correct:

producing system
generation timestamp
canonicalization method
signer reference
key reference
external commitment provenance

The Correction should distinguish inaccurate provenance from a later change in the actual process.

Verification-Discovered Corrections

Verification may reveal an Anchor error.

Verification mismatch
↓
investigate cause
↓
Anchor error confirmed?
↓
Correction process

A mismatch itself is not automatically a Correction.

Maintenance-Discovered Corrections

Maintenance may identify:

broken Source reference
stale publication location
missing commitment metadata
wrong algorithm status metadata
inconsistent relationship lineage

Maintenance should route genuine Anchor errors into Correction rather than silently patching production records.

Correction and Lifecycle

Correction does not automatically determine Lifecycle State.

Correction
→ active remains active
or
→ withdrawal
or
→ supersession
or
→ archival

The appropriate lifecycle consequence depends on whether the integrity subject remains valid and whether the defect is safely repairable.

Correction and Publication

Publication should make material Corrections visible.

A canonical public Integrity Reference should identify:

current Anchor Version
prior Version history
Correction notice where applicable
corrected fields or condition
effective Correction time

Publication must not create the appearance that the corrected value was always the value originally recorded.

No Destructive Correction

Anchor should never repair a production error by deleting evidence of the erroneous state from institutional history.

Version N = preserved error state
Version N+1 = corrected state

Public presentation may emphasize the current corrected state while preserving access to historical Versions.

Correction Validation

Later Validation architecture or Production Procedures should confirm:

affected record exists
affected Version exists
error is Anchor-owned
Correction reason provided
prior value preserved
corrected value provided
Version increment valid where required
lifecycle consequence valid
relationship lineage coherent

Correction Procedure

1. Detect potential error.
2. Preserve current production state.
3. Determine Source change vs. Anchor error.
4. Determine whether integrity subject remains the same.
5. Classify Correction where useful.
6. Record prior and corrected values.
7. Create new Anchor Version or new Integrity Reference as required.
8. Preserve Correction lineage.
9. Apply lifecycle consequence if required.
10. Publish Correction notice / updated canonical state.
11. Reverify corrected state where applicable.
A trustworthy correction preserves evidence of what came before it.