AZ-051 — Public Historical Snapshot Canon and Time-Bound Verification Rules v1

Status

Acest document definește canonul snapshot-urilor istorice publice și regulile de verificare legate de timp pentru ATLAS ZERO.

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

• specificația protocolului și a subsistemelor;
• canoanele constituționale, parametrice, validatoriale și financiare;
• interfața publică de export al adevărului rețelei;
• bundle-ul constituțional machine-readable;
• matricea formală a capabilităților actorilor.

AZ-051 răspunde la întrebarea: cum definim snapshot-urile istorice publice ale adevărului rețelei, ce boundary-uri sunt suficient de importante încât să fie canonizate, cum înghețăm semantica lor de verificare și cum păstrăm posibilitatea de validare peste timp, chiar după upgrade-uri, hard fork-uri, recovery-uri și evoluții de schemă?

Scopul documentului este să fixeze:

• modelul canonic al snapshot-ului istoric public;
• clasele de boundary și de snapshot;
• regulile de publicare, supersession și revocare;
• regulile de verificare time-bound;
• relația dintre snapshot-uri, canoane normative, export public, constituție machine-readable și preservare pe termen lung;
• și prevenirea ambiguității istorice după schimbări majore de protocol.

Acest document se bazează pe:

• AZ-002 până la AZ-050, cu accent direct pe AZ-021, AZ-033, AZ-037, AZ-038, AZ-043, AZ-048, AZ-049 și AZ-050.

Termeni:

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

1. Obiectiv

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

1. Ce este un public historical snapshot?
2. Ce boundary-uri istorice merită snapshot canonic?
3. Ce adevăruri trebuie incluse într-un snapshot?
4. Cum înghețăm semantica de verificare pentru acel snapshot?
5. Cât timp rămâne verificabil sub aceeași schemă și aceleași reguli?
6. Cum tratăm snapshot-urile după hard fork, recovery sau schimbări de versiune?
7. Cum distingem snapshot complet, minimal sau branch-specific?
8. Cum se leagă snapshot-ul de bundle-ul constituțional și de public truth interface?
9. Cum se păstrează și se exportă pe termen lung?
10. Cum evităm reinterpretarea retroactivă a trecutului public al rețelei?

2. Principii

2.1 A historical snapshot is frozen truth for a declared boundary

Un snapshot istoric public MUST reprezenta adevărul înghețat pentru un boundary declarat, nu o reconstrucție vagă „aproximativă”.

2.2 Verification semantics must be pinned

Nu este suficient să păstrăm datele. Trebuie să păstrăm și semantica prin care acele date se verifică:

• schemă;
• reguli de canonicalizare;
• rădăcini sursă;
• versiuni relevante.

2.3 Historical truth must survive present-day evolution

Upgrade-urile, fork-urile, recovery-urile și schimbările de schemă MUST NOT face snapshot-urile istorice imposibil de interpretat sau verificat.

2.4 Public historical truth is branch-aware

Dacă există ramuri constituționale distincte, snapshot-urile MUST fie clar branch-specific unde este cazul.

2.5 Snapshot publication and verification are distinct

A publica un snapshot nu înseamnă automat că toți actorii îl pot verifica la același nivel. Regulile de verificare time-bound SHOULD fi explicite.

2.6 Historical supersession must not erase original public memory

Un snapshot mai bogat sau corectat poate superseda unul vechi, dar MUST NOT șterge originalul din istoria publică.

3. Snapshot canon purpose

3.1 Canonul SHOULD răspunde:

• ce boundary a fost înghețat?
• ce adevăruri normative au fost incluse?
• ce branch și ce identity se aplică?
• prin ce bundle sau manifest se verifică?
• până la ce condiții de schemă/tooling rămâne verificarea directă?
• ce snapshot îl supersedează sau îl revocă?

3.2 Rule

Dacă aceste întrebări nu pot fi răspunse din snapshot și metadata lui, canonul este insuficient.

4. Snapshot classes

4.1 Recommended snapshot classes

ATLAS ZERO SHOULD include cel puțin:

• HS_CURRENT_TO_HISTORICAL_ROLLOVER
• HS_LAUNCH_BOUNDARY
• HS_FINALIZED_EPOCH_BOUNDARY
• HS_UPGRADE_ACTIVATION_BOUNDARY
• HS_HARD_FORK_BOUNDARY
• HS_RECOVERY_BOUNDARY
• HS_CONSTITUTIONAL_BRANCH_SNAPSHOT
• HS_AUDIT_REFERENCE_SNAPSHOT
• HS_FINANCIAL_AUDIT_SNAPSHOT
• HS_VALIDATOR_SET_REFERENCE_SNAPSHOT

4.2 Rule

Snapshot class MUST reflect why snapshot-ul există și ce întrebări istorice susține.

5. Boundary classes for snapshots

5.1 Boundary classes SHOULD include:

• launch_boundary
• finalized_epoch_boundary
• finalized_block_boundary
• upgrade_boundary
• fork_boundary
• recovery_boundary
• explicit_audit_window_boundary
• explicit_governance_boundary

5.2 Rule

Boundary semantics MUST be machine-readable and deterministic.

6. Historical snapshot scope model

6.1 Canonical structure

HistoricalSnapshotScope {
  snapshot_scope_id
  target_network_class
  target_chain_id
  target_genesis_hash
  constitutional_branch_ref?
  historical_boundary_hash
  included_truth_class_root
}

6.2 Rule

Scope MUST bind chain identity, branch and exact historical boundary.

7. Included truth classes

7.1 A serious public historical snapshot SHOULD be able to include:

• identity truth
• constitutional lineage truth
• active parameter truth
• active validator set truth
• public financial truth
• public obligations truth
• version/upgrade status truth
• verification metadata truth

7.2 Rule

Snapshot MUST say explicitly which truth classes are included and which are not.

8. Snapshot completeness classes

8.1 Recommended completeness classes

• SNAP_MINIMAL_IDENTITY_ONLY
• SNAP_MINIMAL_VERIFIER
• SNAP_SCOPE_COMPLETE
• SNAP_BRANCH_SPECIFIC_COMPLETE
• SNAP_AUDIT_REFERENCE_COMPLETE
• SNAP_PARTIAL_WITH_OMISSIONS

8.2 Rule

Completeness class MUST be declared and MUST match actual included bundles.

9. Historical snapshot object

9.1 Canonical structure

PublicHistoricalSnapshotRecord {
  version_major
  version_minor

  snapshot_id
  snapshot_class
  completeness_class
  snapshot_scope
  source_constitution_bundle_ref
  source_public_truth_export_ref?
  truth_bundle_root
  verification_profile_ref
  consistency_root
  supersession_root?
  revocation_root?
  generation_time_unix_ms
  metadata_hash?
}

9.2 Rule

This object SHOULD be the top-level canonical representation of a public historical snapshot.

10. Source constitution linkage

10.1 Need

Historical public truth SHOULD trace back to the constitution bundle or canon roots valid for that boundary.

10.2 Rule

A historical snapshot MUST link to at least one source constitutional truth anchor:

• constitution bundle ref;
• canonical root set;
• or equivalent preserved source manifest.

10.3 Rule

Historical public truth without source constitutional linkage is weak.

11. Snapshot truth bundle model

11.1 Canonical structure

HistoricalTruthBundle {
  bundle_id
  truth_class
  bundle_scope_hash
  normative_entry_root
  required
  historical_boundary_hash
}

11.2 Rule

Bundles MUST be branch-aware and boundary-aware.

12. Identity and lineage snapshot

12.1 A serious historical snapshot SHOULD include:

• chain identity as of boundary
• branch identity or branch status
• relevant continuity or fork records up to that boundary
• network identity summary valid for that boundary

12.2 Rule

Historical identity MUST be interpreted at the time of the snapshot, not through later reinterpretation only.

13. Parameter snapshot

13.1 Parameter truth in a snapshot SHOULD include:

• active parameter set ref at boundary
• parameter set root
• relevant parameter registry snapshot ref
• activation lineage needed to explain why that set was active then

13.2 Rule

Historical parameter verification MUST be possible without assuming today’s active parameters.

14. Validator set snapshot

14.1 Validator truth in a snapshot SHOULD include:

• active validator set at boundary
• validator membership root
• role assignment root
• branch-specific membership context if needed

14.2 Rule

Historical validator truth MUST remain separate from current live gossip or present-day status.

15. Public financial snapshot

15.1 Financial truth in a snapshot SHOULD include:

• active financial state at boundary
• balance root
• obligation root if relevant
• reconciliation ref up to or at the boundary
• branch-specific financial context if needed

15.2 Rule

Historical financial truth MUST remain reconstructible independently of later rebalancing or branch changes.

16. Verification metadata model

16.1 Every serious snapshot SHOULD preserve:

• schema version
• canonicalization rules version
• verifier metadata version
• public export schema version
• constitution bundle schema version if relevant

16.2 Rule

Historical verification SHOULD not depend on implicit knowledge of old schemas.

17. Verification profile model

17.1 Canonical structure

HistoricalVerificationProfile {
  verification_profile_id
  schema_root
  rule_root
  supported_truth_class_root
  expected_tooling_ref_root?
  deprecation_policy_hash?
}

17.2 Rule

A verification profile SHOULD pin how the snapshot is to be verified.

18. Time-bound verification rules

18.1 Need

Verification semantics may evolve. We need explicit rules for what remains directly verifiable and how.

18.2 Time-bound verification SHOULD define:

• direct verification window
• compatibility verification window
• archival verification fallback
• verifier metadata supersession policy
• schema migration policy for historical snapshots

18.3 Rule

No snapshot SHOULD rely on “whatever the current verifier does” without a pinned verification profile.

19. Verification window classes

19.1 Recommended classes

• VW_DIRECT_NATIVE
• VW_DIRECT_COMPAT
• VW_ARCHIVAL_FALLBACK
• VW_TOOLING_MIGRATION_REQUIRED
• VW_LEGACY_SCHEMA_ONLY

19.2 Meaning

VW_DIRECT_NATIVE

Current verifier stack can verify snapshot directly under original rules.

VW_DIRECT_COMPAT

Current verifier stack can verify via compatible adapter or schema support.

VW_ARCHIVAL_FALLBACK

Verification requires preserved archival tooling or preserved schema adapters.

VW_TOOLING_MIGRATION_REQUIRED

Verification possible, but only after migrating toolchain.

VW_LEGACY_SCHEMA_ONLY

Snapshot is still preserved but only verifiable through legacy preserved semantics.

19.3 Rule

Verification window class SHOULD be attached to snapshot or profile metadata.

20. Snapshot verification state record

20.1 Canonical structure

HistoricalSnapshotVerificationState {
  verification_state_id
  snapshot_ref
  verification_window_class
  verified_at_unix_ms?
  verifier_profile_ref
  result_class
}

20.2 result_class

• verified
• verified_with_adapter
• archival_only
• temporarily_unverifiable
• revoked_due_to_inconsistency

20.3 Rule

Historical verification state SHOULD be tracked explicitly over time.

21. Historical verification run

21.1 Canonical structure

HistoricalSnapshotVerificationRun {
  run_id
  snapshot_ref
  verification_profile_ref
  started_at_unix_ms
  completed_at_unix_ms?
  result_root
  result_class
  notes_hash?
}

21.2 result_class

• pass
• pass_with_notes
• fail
• partial
• schema_gap_detected
• preservation_gap_detected

21.3 Rule

Important historical snapshots SHOULD undergo periodic re-verification.

22. Snapshot consistency model

22.1 Snapshot consistency SHOULD verify:

• all included truth bundles share same boundary
• all included truth bundles share same chain identity and branch
• validator set scope matches parameter and constitutional scope
• financial state scope matches same historical branch and boundary
• source constitution linkage is valid

22.2 Rule

Historical snapshot consistency MUST be machine-checkable.

23. Snapshot consistency assertion

23.1 Canonical structure

HistoricalSnapshotConsistencyAssertion {
  assertion_id
  assertion_class
  participating_root
  assertion_scope_hash
  evidence_root?
}

23.2 assertion_class examples

• shared_boundary_consistent
• shared_identity_consistent
• branch_specific_consistent
• parameter_validator_consistent
• financial_constitution_consistent
• verification_profile_consistent

23.3 Rule

Assertions SHOULD be rooted into snapshot consistency_root.

24. Publication policy

24.1 Public historical snapshots SHOULD be published when:

• launch boundary is reached
• major upgrade activates
• hard fork occurs
• recovery redefines legitimate state materially
• major governance milestone is constitutionally relevant
• periodic historical anchor cadence is reached
• audit reference snapshot is required

24.2 Rule

Publication policy SHOULD be explicit, not opportunistic.

25. Publication cadence classes

25.1 Recommended classes

• at_major_boundary_only
• periodic_epoch_anchor
• periodic_time_anchor
• governance_triggered
• audit_triggered
• preservation_triggered

25.2 Rule

Different networks or branches MAY choose different cadences, but policy MUST be declared.

26. Historical supersession model

26.1 A newer historical snapshot MAY supersede an older one because:

• it has richer completeness for same boundary
• it corrects structural omission
• it refines branch classification
• it attaches improved verification metadata
• it replaces a partial snapshot with a complete one

26.2 Rule

Supersession MUST NOT erase original historical publication.

27. Historical supersession record

27.1 Canonical structure

HistoricalSnapshotSupersession {
  supersession_id
  prior_snapshot_ref
  new_snapshot_ref
  supersession_reason_class
  scope_relation_hash
}

27.2 supersession_reason_class examples

• richer_completeness
• corrected_branch_scope
• corrected_consistency
• better_verification_profile
• archive_grade_reissue

27.3 Rule

Supersession SHOULD preserve historical discoverability.

28. Historical revocation model

28.1 Need

A historical snapshot may be found inconsistent or misleading.

28.2 Rule

Revocation MUST be explicit and SHOULD include:

• snapshot ref
• revocation reason
• affected truth classes
• replacement snapshot if any
• effect on verification state

28.3 Rule

Revoked snapshots MUST remain auditable as revoked.

29. Branch-specific snapshots

29.1 After hard fork or constitutional divergence, historical snapshots SHOULD support:

• parent-branch boundary snapshots
• child-branch initial snapshots
• branch-specific validator and financial truth
• branch-specific continuity statements

29.2 Rule

Branch-specific history MUST remain explicit. No flattened single-history model after constitutional split.

30. Recovery-specific snapshots

30.1 After severe recovery, snapshots SHOULD support:

• pre-recovery last legitimate boundary
• recovery boundary candidate state
• post-ratification recovered state
• branch-specific or continuity-specific classification

30.2 Rule

Recovery snapshots SHOULD preserve ambiguity or dispute if it existed historically.

31. Relationship to public truth interface

31.1 PNTI SHOULD expose:

• latest historical snapshot index
• snapshots by boundary class
• snapshots by branch
• current verification state metadata
• supersession and revocation lineage

31.2 Rule

Historical snapshot discovery SHOULD be part of public truth, not hidden in archives only.

32. Relationship to constitution bundle

32.1 Historical snapshots SHOULD be:

• derivable from constitution bundles;
• or directly linked to boundary-specific constitution bundle refs.

32.2 Rule

A historical snapshot SHOULD never float free of constitutional roots.

33. Relationship to preservation

33.1 Historical snapshots SHOULD be preserved with:

• original snapshot record
• verification profile
• schema versions
• verification runs
• supersession/revocation lineage
• public export projection refs

33.2 Rule

Historical public truth is preservation-critical and SHOULD be included in long-term archive schedules.

34. Relationship to audit exports

34.1 Audit exports MAY reference historical snapshots as:

• boundary anchors
• independent public corroboration
• public-facing claim support
• branch lineage evidence
• financial truth boundary evidence

34.2 Rule

Historical snapshots SHOULD remain audit-compatible, even if more minimal than full audit bundles.

35. Relationship to conformance claims

35.1 Claims MAY reference historical snapshots for statements like:

• active parameter truth at boundary X
• validator set legitimacy at boundary Y
• public financial state at boundary Z
• branch identity as of fork boundary F

35.2 Rule

Historical snapshots SHOULD be claim-usable through stable IDs and verification profiles.

36. Snapshot anti-patterns

36.1 Systems SHOULD avoid:

1. calling any old export a historical snapshot with no pinned boundary
2. historical snapshots with no verification profile
3. using current schema semantics to reinterpret old data silently
4. overwriting a published historical snapshot in place
5. flattening branch-specific history after a split
6. no verification state tracking over time
7. no linkage to source constitution bundle
8. publishing “current minus some data” and calling it historical truth
9. dropping old verifier metadata because new tools exist
10. hiding revoked historical snapshots instead of marking them

37. Formal goals

AZ-051 urmărește aceste obiective:

37.1 Frozen and verifiable public history

The network can publish historical snapshots that remain clearly scoped and verifiable.

37.2 Time-aware verification discipline

Historical verification remains possible through pinned schemas, profiles and fallback paths.

37.3 Branch- and recovery-aware public memory

Historical truth remains coherent even across forks, recovery events and constitutional divergence.

37.4 Durable public accountability

Third parties can inspect what the network publicly claimed as truth at important boundaries.

38. Formula documentului

Public Historical Snapshot Canon = boundary-pinned historical snapshot records + included truth bundles + pinned verification profiles + time-bound verification states + supersession/revocation lineage

39. Relația cu restul suitei

• AZ-048 definește interfața publică a adevărului curent.
• AZ-049 definește bundle-ul constituțional machine-readable.
• AZ-051 definește memoria publică istorică, înghețată pe boundary-uri verificabile în timp.

Pe scurt: AZ-051 este stratul prin care trecutul public al rețelei rămâne verificabil, nu doar vizibil.

40. Ce urmează

După AZ-051, documentul corect este:

AZ-052 — Cross-Canon Consistency and Integrity Verification Framework

Acolo trebuie fixate:

• verificările transversale între toate canoanele;
• regulile de detectare a contradicțiilor și drift-ului între bundle-uri;
• și modul în care integritatea globală a sistemului de canoane devine verificabilă ca întreg.

Închidere

Adevărul public al unei rețele nu este complet dacă poate spune doar ce este adevărat acum. Devine matur abia când poate spune, verificabil și peste ani: ce era adevărat atunci, pe ce boundary, pe ce branch, sub ce reguli, și prin ce profil de verificare.

Acolo începe canonul snapshot-urilor istorice publice.