Satoshium Anchor · Lifecycle

Lifecycle Boundary

Anchor describes the lifecycle of its own Integrity Reference, not the lifecycle state of the external Source Artifact.

Lifecycle Model

These states are now sufficiently supported by the architecture to serve as the initial Anchor Lifecycle State set.

Initial Frozen Lifecycle Values

These five values form the initial Anchor Lifecycle State vocabulary.

Additional values should be added only when production demonstrates a condition that cannot be represented accurately by this set.

Lifecycle vs. Publication State

Lifecycle and Publication remain separate.

An Integrity Reference may be active but not yet publicly published. A superseded record may remain publicly accessible. An archived record may remain resolvable indefinitely.

Lifecycle vs. Integrity State

Lifecycle describes institutional use. Integrity State describes the current integrity condition.

For example, an archived Integrity Reference may still have a fully satisfactory integrity condition.

Lifecycle vs. Verification Result

A Verification event may produce a mismatch or become unable to verify without automatically determining the lifecycle of the Integrity Reference.

Maintenance, investigation, Correction, or Governance may determine what lifecycle action follows.

Source Lifecycle Independence

The Source Artifact may have its own lifecycle states such as:

These Source states do not automatically become Anchor lifecycle states.

Source Withdrawal

If a Source Artifact is withdrawn, Anchor may preserve the Integrity Reference as evidence of the representation that existed at the time it was anchored.

Source Supersession

If the Source Institution issues a new Source Version, the existing Anchor record continues to govern the earlier representation.

A new Source Version may require:

Versioning architecture will define the boundary.

Draft State

`draft` applies before the Integrity Reference enters active institutional use.

Draft records may change freely under production procedures because they are not yet part of the preserved public lineage.

The exact point at which `draft` becomes `active` should be aligned with Validation and Publication architecture.

Active State

`active` means Anchor recognizes the Integrity Reference as the current institutional record for the integrity subject it governs.

Active does not mean:

Superseded State

`superseded` applies when a later Integrity Reference replaces the earlier record for current institutional use.

The earlier identifier, provenance, Verification history, and relationships remain preserved.

Withdrawn State

`withdrawn` applies when Anchor intentionally removes an Integrity Reference from normal active use without replacing it through ordinary supersession.

Potential reasons may include:

Exact withdrawal procedure remains to be defined.

Archived State

`archived` applies when an Integrity Reference is preserved primarily for historical, evidentiary, or institutional continuity.

Archive does not mean deletion.

Lifecycle Transitions

Initial allowed transitions should conceptually include:

Reverse transitions should not be assumed. If production later requires restoration or reactivation, that behavior should be explicitly governed rather than improvised.

No Silent Lifecycle Reversal

Once a record becomes superseded, withdrawn, or archived, Anchor should not silently return it to active use.

A reversal, if ever allowed, should require an explicit governed event and preserved history.

Lifecycle History

Lifecycle changes should preserve:

Exact event structure remains to be finalized in Schema and Procedures.

Lifecycle and Identifiers

Lifecycle change does not change Anchor identity.

This preserves durable citation and relationship resolution.

Lifecycle and Versioning

Versioning changes the governed representation of an Integrity Reference. Lifecycle describes its institutional position.

A Version change does not necessarily change lifecycle. A lifecycle change does not necessarily require a new Version.

Lifecycle and Corrections

A Correction does not automatically change lifecycle.

Depending on severity, a Correction process may:

Corrections architecture will define the governing behavior.

Lifecycle and Maintenance

Maintenance may detect conditions that require lifecycle review.

Maintenance should recommend or trigger governed lifecycle action rather than silently changing state.

Lifecycle Controlled Values

This page now freezes the initial production Lifecycle State set:

These tokens should remain machine-stable unless later governance formally deprecates or replaces one.

Lifecycle Principle

Anchor should preserve the full institutional history of an Integrity Reference even after it is no longer the active record.