AZ-037 — Long-Term Archive Verification and Preservation Schedule v1

Status

Acest document definește programul de verificare și conservare pe termen lung pentru arhivele critice ATLAS ZERO.

După AZ-001 până la AZ-036, există deja:

• specificația protocolului și a subsistemelor;
• vault-ul de artefacte, manifesturile și atestările;
• pachetele release/genesis;
• launch archive și audit package;
• protocolul de upgrade și hard fork;
• matricea de compatibilitate și rollout-ul dintre versiuni.

AZ-037 răspunde la întrebarea: cum ne asigurăm că arhivele critice rămân verificabile, complete și reutilizabile peste ani, chiar dacă mediile de stocare se degradează, formatele de transport se schimbă și echipele sau infrastructura inițiale dispar?

Scopul documentului este să fixeze:

• clasele de arhive cu retenție lungă;
• verificările periodice obligatorii;
• politica de migrare a mediilor de stocare;
• reverificarea manifesturilor, hash-urilor și atestărilor;
• detectarea degradării și coruperii tăcute;
• procedurile de re-ambalare, re-indexare și re-atestare fără a altera adevărul arhivat.

Acest document se bazează pe:

• AZ-002 până la AZ-036, cu accent direct pe AZ-018, AZ-019, AZ-020, AZ-021, AZ-033, AZ-034 și AZ-036.

Termeni:

• MUST = obligatoriu
• MUST NOT = interzis
• SHOULD = recomandat puternic
• MAY = opțional

1. Obiectiv

AZ-037 răspunde la 10 întrebări critice:

1. Ce arhive trebuie păstrate pe termen lung?
2. Cât de des trebuie reverificate?
3. Ce înseamnă verificare de arhivă completă versus verificare superficială?
4. Cum detectăm degradarea tăcută a mediilor și a fișierelor?
5. Cum migrăm arhivele între medii de stocare fără a altera identitatea lor normativă?
6. Cum păstrăm atestările și manifesturile utile peste ani?
7. Ce facem când un format auxiliar devine depășit sau greu de citit?
8. Cum reconstituim o arhivă din copii redundante?
9. Cum păstrăm o politică auditabilă de retenție și verificare?
10. Cum evităm situația în care „arhiva există”, dar nu mai poate fi verificată sau folosită?

2. Principii

2.1 Preservation means verifiable preservation

A păstra o arhivă înseamnă mai mult decât a o copia. Înseamnă să poți demonstra în timp că:

• este aceeași;
• este completă;
• și poate fi reconstruită semantic.

2.2 Manifest truth outlives storage medium

Adevărul arhivat MUST rămâne definit de manifesturi, identități de artefact și rădăcini canonice, nu de filesystem-ul sau mediul particular în care se află copia curentă.

2.3 Reverification must be scheduled, not ad hoc

Arhivele critice MUST avea un program explicit de reverificare. Verificarea ocazională, făcută doar când apare o problemă, este insuficientă.

2.4 Migration is normal, silent mutation is forbidden

Mediile de stocare și containerele se pot schimba. Conținutul normativ arhivat MUST NOT fi alterat tăcut.

2.5 Auxiliary convenience formats are replaceable; normative payload is not

Putem migra ambalaje, indexuri și reprezentări auxiliare. Nu putem schimba identitatea normativă a artefactelor și manifesturilor fără supersession explicită.

2.6 Long-term preservation is a protocol governance concern

Arhivele launch, upgrade, incident și audit sunt parte din memoria instituțională și operațională a rețelei. Pierderea verificabilității lor este un risc real.

3. Archive classes under preservation

3.1 Recommended long-term classes

ATLAS ZERO SHOULD păstra explicit cel puțin:

• LT_ARCHIVE_MAINNET_LAUNCH
• LT_ARCHIVE_EARLY_MAINNET
• LT_ARCHIVE_STABILIZATION_REVIEW
• LT_ARCHIVE_UPGRADE_AND_FORK
• LT_ARCHIVE_SECURITY_INCIDENT
• LT_ARCHIVE_KEY_COMPROMISE_AND_ROTATION
• LT_ARCHIVE_GOVERNANCE_CRITICAL
• LT_ARCHIVE_CONFORMANCE_RELEASE

3.2 Rule

Fiecare clasă SHOULD avea:

• retention horizon;
• verification cadence;
• replication policy;
• restoration priority.

4. Preservation scope

4.1 Canonical structure

PreservationScope {
  preservation_scope_id
  archive_class
  target_network_class
  target_chain_id
  target_genesis_hash?
  archive_id
  retention_class
  criticality_tier
}

4.2 retention_class examples

• short_operational
• medium_audit
• long_governance
• permanent_constitutional

4.3 Rule

Preservation policy MUST be scope-bound and explicit.

5. Verification levels

5.1 Standard verification levels

• AVL_PRESENCE_ONLY
• AVL_CHECKSUM_LEVEL
• AVL_MANIFEST_LEVEL
• AVL_FULL_NORMATIVE_REBUILD
• AVL_CROSS_COPY_RECOVERY_TEST

5.2 Meaning

AVL_PRESENCE_ONLY

Verifică doar că fișierele există. Insuficient pentru arhive critice.

AVL_CHECKSUM_LEVEL

Verifică checksums auxiliare sau top-level bundle hashes.

AVL_MANIFEST_LEVEL

Verifică manifestul, intrările și identitatea artefactelor.

AVL_FULL_NORMATIVE_REBUILD

Reconstruiește și revalidează rădăcinile normative și relațiile.

AVL_CROSS_COPY_RECOVERY_TEST

Reconstituie arhiva din copii redundante și verifică identitatea finală.

5.3 Rule

Arhivele TIER_4 sau constituționale SHOULD receive at least periodic AVL_FULL_NORMATIVE_REBUILD.

6. Verification cadence classes

6.1 Recommended cadence classes

• CAD_MONTHLY
• CAD_QUARTERLY
• CAD_SEMIANNUAL
• CAD_ANNUAL
• CAD_EVENT_TRIGGERED

6.2 Rule

Critical archives SHOULD have both:

• periodic cadence;
• event-triggered verification after migration, incident or storage anomaly.

7. Verification schedule object

7.1 Canonical structure

ArchiveVerificationSchedule {
  schedule_id
  preservation_scope_id
  verification_level
  cadence_class
  next_due_policy_hash
  escalation_policy_hash
  active
}

7.2 Rule

Each critical archive SHOULD be linked to a concrete active verification schedule.

8. Verification run object

8.1 Canonical structure

ArchiveVerificationRun {
  run_id
  preservation_scope_id
  verification_level
  archive_id
  started_at_unix_ms
  completed_at_unix_ms?
  verifier_policy_ref
  result_class
  evidence_root?
  notes_hash?
}

8.2 result_class

• RUN_PASS
• RUN_PASS_WITH_NOTES
• RUN_FAIL
• RUN_PARTIAL
• RUN_RECOVERY_REQUIRED
• RUN_QUARANTINE_REQUIRED

8.3 Rule

Long-term preservation MUST rely on recorded runs, not oral memory.

9. Verification evidence model

9.1 Evidence MAY include:

• manifest verification results
• normative root recomputation outputs
• copy comparison results
• media health reports
• missing entry reports
• corruption detection reports
• restore trial reports
• attestation verification results

9.2 Canonical structure

ArchiveVerificationEvidenceEntry {
  evidence_class
  evidence_ref
}

9.3 Rule

Important verification runs SHOULD be evidence-backed enough for later audit.

10. Media health monitoring

10.1 Preservation SHOULD monitor storage-media health signals such as:

• unreadable sectors or blocks
• checksum drift
• replication mismatch
• unexpected deletion or truncation
• slow read anomalies suggestive of decay
• metadata corruption
• container extraction failures

10.2 Rule

Media-health degradation SHOULD trigger earlier archive reverification.

11. Silent corruption detection

11.1 Need

One of the main risks is bit rot or silent mutation.

11.2 Detection SHOULD rely on:

• content_hash recomputation
• canonical_hash recomputation where applicable
• chunk_root verification
• manifest root verification
• cross-copy comparison
• periodic full rebuild tests for top-tier archives

11.3 Rule

Silent corruption MUST NOT be treated as hypothetical; preservation policy should assume it can happen.

12. Chunk-level preservation

12.1 Large archives or bundles SHOULD preserve:

• chunk hashes
• chunk roots
• chunk manifests if relevant

12.2 Benefit

Allows:

• partial corruption detection
• targeted repair
• cross-copy healing
• more efficient revalidation

12.3 Rule

Chunk-level metadata MUST remain linked to original artifact identity, not replace it.

13. Replication policy

13.1 Critical archives SHOULD have:

• multiple independent copies
• multiple physical or cloud backends
• at least one cold/offline copy for highest criticality scopes
• at least one copy outside the primary operational failure domain

13.2 Rule

All copies SHOULD be treated as candidates until verified. Replication without verification is weak preservation.

14. Preservation tiers

14.1 Suggested tiers

• PT_NORMAL
• PT_IMPORTANT
• PT_CRITICAL
• PT_CONSTITUTIONAL

14.2 Example mapping

PT_NORMAL

Internal release-support archives.

PT_IMPORTANT

Conformance release packages, non-launch major upgrades.

PT_CRITICAL

Mainnet launch, early-mainnet, major incident bundles.

PT_CONSTITUTIONAL

Genesis, chain-identity-defining records, hard fork roots, constitutional governance records.

14.3 Rule

Higher preservation tier => stronger cadence, stronger rebuild testing, stricter media redundancy.

15. Preservation policy matrix

15.1 The system SHOULD maintain, per archive class or tier:

• retention duration
• verification level minimum
• cadence minimum
• replication count minimum
• cold-storage requirement
• migration review requirement
• mandatory restore-test frequency

15.2 Rule

This matrix SHOULD be canonical and auditable.

16. Retention horizons

16.1 Recommended horizons

• operational support archives: years as policy requires
• mainnet launch and upgrade archives: long multi-year retention minimum
• constitutional/identity-defining archives: effectively permanent or equivalent governance-grade retention

16.2 Rule

Exact durations MAY vary by policy, but critical launch and identity archives SHOULD not have short-lived retention.

17. Migration of storage media

17.1 Need

Media and storage platforms age out.

17.2 Migration MUST preserve:

• archive manifest truth
• normative entry root
• artifact identities
• scope binding
• attestation lineage
• prior verification history

17.3 Rule

Migration MUST create migration records, not silent copy-and-delete behavior.

18. Archive migration record

18.1 Canonical structure

ArchiveMigrationRecord {
  migration_id
  preservation_scope_id
  source_storage_profile_hash
  target_storage_profile_hash
  migrated_archive_id
  pre_migration_verification_ref
  post_migration_verification_ref
  migration_time_unix_ms
  result_class
}

18.2 result_class

• MIGRATION_PASS
• MIGRATION_PASS_WITH_NOTES
• MIGRATION_FAIL
• MIGRATION_ROLLBACK_REQUIRED

18.3 Rule

Critical archives SHOULD be verified both before and after migration.

19. Repackaging rules

19.1 Sometimes transport or storage container formats change.

19.2 Rule

Repackaging MAY change:

• outer archive container
• compression
• filesystem layout convenience
• side indexes

But MUST NOT change:

• normative artifact bytes
• manifest identity
• canonical roots unless done through explicit supersession model.

19.3 Rule

Repackaged copies SHOULD themselves be tracked as storage/container artifacts, not mistaken for new normative archives.

20. Re-indexing rules

20.1 Indexes may be regenerated.

20.2 Rule

Indexes are derived. They MAY be replaced or rebuilt, but MUST remain clearly non-authoritative compared with manifest truth.

20.3 Rule

Index regeneration SHOULD be logged and SHOULD be verifiable against archive manifest.

21. Long-term attestation verification

21.1 Need

Attestations may remain useful for provenance and audit years later.

21.2 Preservation SHOULD include:

• attestation objects
• revocation and supersession records
• policy matrix versions
• verification outputs at time of archive verification

21.3 Rule

If older signature schemes become operationally harder to verify, the archive SHOULD still preserve original attestation truth and MAY add modern preservation attestations without altering original claim.

22. Preservation attestation object

22.1 Canonical structure

ArchivePreservationAttestation {
  attestation_id
  preservation_scope_id
  verification_run_ref
  attestation_class
  attestor_policy_ref
  timestamp_unix_ms
  signature_envelopes
}

22.2 attestation_class examples

• integrity_reconfirmed
• migration_verified
• rebuild_verified
• retention_review_completed

22.3 Rule

Preservation attestations MAY add confidence, but MUST NOT overwrite original archive truth.

23. Restoration / recovery testing

23.1 Critical archives SHOULD periodically undergo restore tests:

• from primary copy
• from secondary copy
• from mixed-copy reconstruction if chunk model supports it

23.2 Rule

At least some high-tier archives SHOULD receive AVL_CROSS_COPY_RECOVERY_TEST on scheduled basis.

23.3 Goal

Ensure that “restorable” is demonstrated, not assumed.

24. Recovery test record

24.1 Canonical structure

ArchiveRecoveryTestRecord {
  recovery_test_id
  preservation_scope_id
  source_copy_root
  reconstructed_archive_id
  verification_run_ref
  timestamp_unix_ms
  result_class
}

24.2 result_class

• RECOVERY_PASS
• RECOVERY_PASS_WITH_NOTES
• RECOVERY_FAIL
• RECOVERY_PARTIAL

24.3 Rule

A failed recovery test SHOULD escalate preservation priority immediately for that scope.

25. Degradation escalation model

25.1 Degradation classes

• DEG_MEDIA_WARNING
• DEG_COPY_MISMATCH
• DEG_MANIFEST_FAILURE
• DEG_MISSING_REQUIRED_ENTRY
• DEG_REBUILD_FAILURE
• DEG_ATTESTATION_VERIFICATION_GAP
• DEG_SCOPE_INCONSISTENCY

25.2 Rule

Critical degradation SHOULD map to:

• quarantine of suspect copy
• immediate reverification of other copies
• migration planning
• archive preservation incident if necessary

26. Quarantine of suspect copies

26.1 Need

Not every failing copy means the archive truth is lost. But suspect copies MUST be isolated.

26.2 Rule

A suspect copy SHOULD be:

• marked non-authoritative
• removed from automated restore preference
• preserved for forensic comparison if useful
• replaced only after verification of healthy copies

26.3 Rule

Copy quarantine MUST NOT imply archive revocation unless normative truth itself is compromised.

27. Archive supersession and preserved history

27.1 Need

A fuller archive package may supersede an earlier incomplete one.

27.2 Rule

Long-term preservation MUST keep:

• original archive id
• superseding archive id
• supersession reason
• continuity proof between them

27.3 Rule

Do not silently discard older archive generations if they are part of historical audit chain.

28. Archive revocation under long-term preservation

28.1 Need

An archive may later be found incomplete or corrupted.

28.2 Rule

Revocation MUST remain explicit and preserved in long-term schedule, including:

• revocation reason
• evidence
• replacement archive if any
• date and responsible authority

28.3 Rule

Revoked archives remain historically important and SHOULD not vanish.

29. Preservation review cadence

29.1 In addition to per-run verification, the preservation program SHOULD conduct periodic policy reviews asking:

• are retention tiers still appropriate?
• are storage backends still viable?
• are verification tools still reproducible/available?
• do signature verification dependencies need modernization?
• have any archives drifted into incomplete status?

29.2 Rule

Long-term preservation is not static; its policy layer also needs review.

30. Preservation review record

30.1 Canonical structure

PreservationReviewRecord {
  review_id
  review_window_hash
  reviewed_scope_root
  findings_root
  policy_change_root?
  timestamp_unix_ms
  result_class
}

30.2 result_class

• PRES_REVIEW_OK
• PRES_REVIEW_NEEDS_ACTION
• PRES_REVIEW_INCIDENT_OPENED

30.3 Rule

Critical preservation reviews SHOULD feed into governance or operational backlog if action needed.

31. Tooling preservation

31.1 Need

Even if bytes survive, verification may fail if tooling disappears.

31.2 Preservation SHOULD consider archiving:

• manifest schema versions
• verification tool versions or source refs
• container extraction rules
• migration notes for deprecated auxiliary formats
• canonicalization rules

31.3 Rule

Preserving only the archive bytes without enough interpretation context can be insufficient.

32. Human-readable preservation notes

32.1 MAY include:

• storage migration rationale
• operational incidents affecting archive copies
• schema evolution notes
• known caveats in auxiliary formats
• verifier toolchain notes

32.2 Rule

These notes are auxiliary. Normative truth still rests in manifests and verification records.

33. Governance interaction

33.1 For constitutional or permanent archives, preservation failures SHOULD be visible to governance or equivalent authority.

33.2 Rule

Loss of long-term verifiability for constitutional archives is not just storage hygiene issue; it is governance-grade risk.

34. Incident interaction

34.1 Severe preservation failures MAY warrant incident handling, especially if:

• no verified good copy remains
• constitutional archive manifest cannot be rebuilt
• multiple copies disagree on normative entries
• recovery tests fail across replicas

34.2 Rule

Preservation incidents SHOULD be classified and archived like other critical operational incidents.

35. Audit queries the preservation program SHOULD answer

35.1 Examples

• When was archive X last fully rebuilt and verified?
• How many verified copies exist?
• Which migration events occurred?
• Which copy is currently preferred authoritative restore source?
• Has any required entry ever failed verification?
• Which archives are overdue for revalidation?

35.2 Rule

If the preservation schedule cannot answer these, it is under-specified.

36. Anti-patterns

Systems SHOULD avoid:

1. assuming archive copies are fine because storage says “healthy”
2. no scheduled full rebuilds for critical archives
3. replacing media with no migration records
4. treating checksum-only checks as enough forever
5. losing verification tooling context
6. re-compressing or re-packaging normative artifacts with silent mutation
7. no cold copy for top-tier archives
8. deleting superseded archive generations
9. not testing restore from secondary copies
10. keeping retention policy only in informal docs

37. Formal goals

AZ-037 urmărește aceste obiective:

37.1 Long-term verifiability

Critical archives remain provably intact and reconstructible over time.

37.2 Controlled storage evolution

Media migrations and format evolution do not silently damage normative truth.

37.3 Recovery confidence

The system periodically demonstrates that archived truth can actually be restored.

37.4 Governance-grade memory durability

Launch, fork, incident and constitutional archives remain usable across long horizons.

38. Formula documentului

Long-Term Archive Preservation = scheduled reverification + scope-bound retention policy + replication + migration records + rebuild testing + explicit degradation handling

39. Relația cu restul suitei

• AZ-033 definește ce intră în arhiva de launch și audit.
• AZ-037 definește cum rămâne acea arhivă verificabilă peste ani.

Pe scurt: AZ-033 construiește arhiva; AZ-037 o păstrează vie și verificabilă în timp.

40. Ce urmează

După AZ-037, documentul corect este:

AZ-038 — External Audit Interface and Evidence Export Format

Acolo trebuie fixate:

• cum exportăm dovezile pentru auditori externi;
• ce bundle-uri și manifesturi livrăm;
• cum reducem datele sensibile fără a pierde auditabilitatea;
• și cum standardizăm interfața de audit pentru launch, upgrade, incident și archive review.

Închidere

O arhivă critică nu moare doar când o ștergi. Moare și când nimeni nu mai poate demonstra că este aceeași, când copiile au derivat în tăcere, când mediul s-a schimbat, sau când restaurarea nu mai funcționează decât în teorie.

Acolo începe conservarea reală: nu când ai multe copii, ci când ai un program disciplinat prin care adevărul arhivat este reverificat și salvat înainte să se piardă.