Anchor · Maintenance

Satoshium Anchor · Maintenance

Maintenance governs post-publication operations required to preserve the continued integrity, resolvability, verifiability, and historical usefulness of published Integrity References.

Maintenance observes, tests, records, and escalates. It must not silently rewrite canonical Anchor records.

Maintenance Principle

Observe continuously. Preserve history. Escalate governed change.

Resolution Health

Monitors Source locations, canonical Anchor URLs, JSON availability, historical Versions, and relationship targets.

Core

Reverification

Re-tests integrity evidence after publication according to schedule, trigger, or risk condition.

Core

Method Health

Reviews integrity methods, algorithms, signing keys, timestamp systems, and external commitment mechanisms for continued suitability.

Core

Source Change Review

Detects Source Artifact changes and determines whether Anchor action is needed.

Core

Correction Routing

Routes confirmed Anchor-owned errors into Corrections rather than silently patching production records.

Core

Preservation

Preserves durable access to current and historical Versions, provenance, proof material, and institutional lineage.

Core

Maintenance Boundary

Maintenance may detect change.
Maintenance does not silently create authority.

A Maintenance observation may trigger Verification, Correction, Versioning, Lifecycle review, or Publication action. Those governed systems determine the institutional consequence.

Post-Publication Monitoring

Source reachability
Canonical HTML availability
Canonical JSON availability
current-Version resolution
historical-Version resolution
relationship resolution
Verification Material availability
external commitment availability
algorithm / key status
Correction notices
lifecycle notices

Broken Source Links

A broken Source location does not necessarily invalidate the Integrity Reference.

Source identifier → identity
Source URL → location

Maintenance should distinguish temporary outage, permanent move, Source withdrawal, Source deletion, archive relocation, and identifier resolution failure.

Source Relocation

If the Source Artifact moves but identity remains the same, Anchor may update location metadata through governed Versioning or Maintenance metadata, depending on whether the canonical Anchor record changes.

The old location should remain recoverable in historical provenance where useful.

Source Artifact Changes

Source changed
↓
compare Source identity + Canonical Representation + Representation Boundary
↓
same integrity subject?
↓
no action / Reverification / new Anchor Version
or
new Integrity Reference

Source change is not automatically an Anchor Correction.

Reverification Triggers

scheduled review
Source change
Source relocation
suspected corruption
algorithm review
key rotation
external commitment concern
Correction
Version change
governance request
manual investigation

Failed Reverification

Reverification result
↓
investigate cause
↓
no change / Maintenance note / Correction / Lifecycle review / new Integrity Reference

Maintenance must not silently convert a failed Reverification into a new canonical state.

Algorithm Deprecation

historical algorithm evidence
→ preserve

new production use
→ may be prohibited or deprecated

Maintenance should trigger review of whether stronger replacement evidence should be added for the same integrity subject.

Algorithm Migration

same integrity subject
+ new algorithm evidence
→ additional method evidence or new Anchor Version

Historical evidence using the older algorithm should remain preserved.

Key Rotation

old key reference
→ preserved for historical Verification

new key reference
→ used for future signing activity

Key rotation must not make earlier signatures uninterpretable.

Key Compromise

If a key is compromised, Maintenance should preserve the compromise context and determine which historical signatures or Integrity References require review.

Reverification
Integrity State review
Correction
additional replacement evidence
lifecycle review

External Commitment Health

service availability
proof availability
ledger / log accessibility
identifier resolution
protocol deprecation
inclusion-proof validity
historical verification capability

Bitcoin Commitment Health

transaction resolution
confirmation history
commitment location
inclusion proof
committed value correspondence
archival proof availability

No Bitcoin-specific Maintenance procedure is frozen yet.

Human / Machine Consistency

Maintenance should periodically confirm that canonical HTML and canonical JSON still represent the same current Anchor Version.

Canonical HTML
↔
Canonical JSON

Version Health

current Version pointer resolves correctly
historical Versions remain accessible
Version lineage is intact
Correction lineage is intact
supersession relationships remain resolvable

Correction Routing

Maintenance finding
↓
Correction review
↓
Correction + new Anchor Version
or
new Integrity Reference if subject-invalidating

Maintenance itself should not silently edit production history.

Lifecycle Escalation

superseding Integrity Reference exists
unresolved integrity defect
Source permanently withdrawn
method no longer verifiable
policy or governance change
long-term archival transition

Maintenance should trigger the decision. It should not silently change Lifecycle State.

Publication Health

canonical record remains published where intended
current Version is correctly identified
Correction notices are visible
supersession notices are visible
withdrawal / archive notices are accurate
canonical URLs remain stable or properly redirected

Long-Term Preservation

Anchor Identifier
all production Versions
Source references
Canonical Representation context
integrity material
Verification Material
Provenance
Corrections
Relationships
Lifecycle history
Publication history

Storage Migration

storage system changes
≠
Anchor Identifier changes

Migration should preserve integrity, Version history, canonical resolution, and historical relationships.

Maintenance Event

reviewed_at
trigger
scope
observations
Reverification result where applicable
action required
related Correction
related Anchor Version
lifecycle review
next review due

Whether Maintenance events receive permanent identifiers remains unfrozen.

Maintenance Cadence

Integrity Method
algorithm risk
key status
Source volatility
external commitment dependency
lifecycle state
institutional importance

No universal cadence is frozen yet.

Maintenance vs. Correction

Maintenance → observes and detects
Correction → repairs Anchor-owned error

Not every Maintenance finding is a Correction.

Maintenance vs. Versioning

Maintenance event
≠
automatically new Anchor Version

A new Version is required only when the canonical Anchor record changes under Versioning rules.

Maintenance vs. Verification

Maintenance → decides when / why review is needed
Verification → performs the integrity comparison

Maintenance Procedure

1. Identify Maintenance trigger.
2. Load current Integrity Reference and Version history.
3. Check publication and relationship resolution.
4. Check Source availability and Source changes.
5. Review method, algorithm, key, and commitment health.
6. Perform Reverification where required.
7. Record observations.
8. Determine whether governed action is required.
9. Route to Correction, Versioning, Lifecycle, Publication, or new Integrity Reference as appropriate.
10. Preserve Maintenance history.
11. Set next review where applicable.
Durable integrity requires care after publication, not only at creation.