AZ-033 — Mainnet Artifact Archive and Audit Package v1

Status

Acest document definește arhiva de artefacte și pachetul de audit pentru mainnet în ATLAS ZERO.

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

specificația protocolului și a subsistemelor;
pachetele release și genesis;
manualele și checklist-urile operatorilor;
ceremoniile de genesis și launch;
launch window procedure;
launch decision ledger;
profilele de monitorizare early mainnet;
review-ul de stabilizare post-launch.

AZ-033 răspunde la întrebarea: cum păstrăm complet, verificabil și pe termen lung toate artefactele relevante ale lansării și stabilizării timpurii, astfel încât un auditor sau o echipă tehnică viitoare să poată reconstrui exact ce s-a lansat, cum s-a lansat, ce s-a observat și ce s-a decis?

Scopul documentului este să fixeze:

ce artefacte intră în arhivă;
cum sunt împachetate;
ce manifesturi și atestări le leagă;
cum se separă artefactele normative de cele auxiliare;
cum se verifică integritatea, completitudinea și retenția;
cum se păstrează istoria launch-ului fără degradare sau ambiguitate.

Acest document se bazează pe:

AZ-002 până la AZ-032, cu accent direct pe AZ-018 până la AZ-032.

Termeni:

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

1. Obiectiv

AZ-033 răspunde la 10 întrebări practice:

Ce este Mainnet Artifact Archive?
Ce artefacte trebuie arhivate obligatoriu?
Cum sunt împachetate pentru audit?
Cum se diferențiază artefactele normative de cele auxiliare?
Cum se leagă arhiva de vault, manifesturi, atestări și ledger?
Cum se verifică integritatea și completitudinea arhivei?
Ce politici de retenție și supersession există?
Cum se face recovery sau re-import al unei arhive?
Cum poate un auditor să reconstruiască istoria lansării și stabilizării?
Cum evităm arhive incomplete, corupte sau imposibil de folosit peste timp?

2. Principii

2.1 Archive is part of operational truth preservation

Arhiva nu este doar backup. Este stratul de conservare a adevărului operațional și auditabil.

2.2 Preserve exact launch scope

Arhiva MUST ancora exact:

release scope;
genesis scope;
launch window scope;
early mainnet stabilization scope.

2.3 Normative first, auxiliary second

Arhiva MUST separa clar:

artefacte normative și verificabile;
logs și observabilitate;
documente auxiliare și note.

2.4 Append, never rewrite

Arhiva SHOULD funcționa prin adăugare, supersession explicit și revocation explicit. Nu prin rescriere tăcută.

2.5 Auditability over convenience

Formatul și structura SHOULD privilegia reconstrucția auditabilă în fața comodității locale.

2.6 Long-term integrity

Arhiva SHOULD fi verificabilă mult după momentul lansării, inclusiv dacă mediul inițial nu mai există.

3. Archive purpose

3.1 Mainnet Artifact Archive

Este colecția canonicală de artefacte și manifesturi care conservă:

ce s-a lansat;
cine a aprobat;
cum s-a verificat;
cum s-a pornit;
ce s-a monitorizat;
ce s-a decis;
și cum s-a stabilizat rețeaua în faza inițială.

3.2 Rule

Pentru scope-uri serioase, arhiva SHOULD fi tratată ca artefact TIER_4.

4. Archive classes

4.1 Recommended archive classes

ARCHIVE_LAUNCH_CORE
ARCHIVE_EARLY_MAINNET
ARCHIVE_STABILIZATION_REVIEW
ARCHIVE_FULL_AUDIT_PACKAGE

4.2 Meaning

ARCHIVE_LAUNCH_CORE

Conține strict minimul normativ al lansării.

ARCHIVE_EARLY_MAINNET

Adaugă monitoring, incident linkage și early epoch outputs.

ARCHIVE_STABILIZATION_REVIEW

Adaugă review-ul formal și rezultatele lui.

ARCHIVE_FULL_AUDIT_PACKAGE

Conține pachetul complet pentru audit istoric.

4.3 Rule

Un launch mainnet serios SHOULD produce cel puțin ARCHIVE_FULL_AUDIT_PACKAGE.

5. Archive scope

5.1 Canonical structure

ArchiveScope {
  scope_class
  target_network_class
  target_chain_id
  target_genesis_hash
  release_package_id
  genesis_package_id
  launch_window_id?
  stabilization_review_id?
}

5.2 scope_class examples

launch_core_scope
early_mainnet_scope
stabilization_scope
full_audit_scope

5.3 Rule

Arhiva MUST fi scope-bound. O arhivă fără exact chain/genesis/release binding este slabă.

6. Archive top-level layout

6.1 Recommended layout

mainnet_audit_archive/
  archive_manifest/
  artifacts/
  decisions/
  checklists/
  ceremonies/
  monitoring/
  incidents/
  stabilization/
  attestations/
  manifests/
  logs/
  docs/
  checksums/

6.2 Meaning

archive_manifest/

Manifestul principal al arhivei și manifesturile auxiliare.

artifacts/

Release package, genesis package, artifact refs, linkage bundles.

decisions/

Launch decision ledger extracts și decision records.

checklists/

Operator checklist records relevante.

ceremonies/

Genesis ceremony, launch ceremony, confirmations.

monitoring/

Monitoring snapshots, anomaly records, health assessments.

incidents/

Incident records și linkage către incidente relevante.

stabilization/

Stabilization review, findings, recommendations, exit decisions.

attestations/

Aprobări și atestări relevante pentru artefacte și package-uri.

manifests/

Manifesturi suplimentare, root manifests, scope manifests.

logs/

Log bundles și evidence adjunct dacă policy le include.

docs/

Ghiduri, rezumate și note non-normative.

checksums/

Liste rapide de verificare și sumare auxiliare.

7. Mandatory archive contents

7.1 Every full mainnet audit archive SHOULD include at minimum:

release package manifest ref or exact artifact
genesis package manifest ref or exact artifact
exact release_package_id
exact genesis_package_id
exact chain_id
exact genesis_hash
LaunchWindowRecord
launch checkpoint records
launch ceremony records and confirmations
Go/No-Go / authorization decisions
operator checklist records used for readiness
early monitoring snapshots and anomaly records
incident records relevant to launch/stabilization scope
StabilizationReviewRecord and findings
restricted posture enter/exit related decisions
archive manifest and integrity roots

7.2 Rule

Dacă unul dintre aceste elemente lipsește pentru full audit scope, arhiva SHOULD be considered incomplete.

8. Optional archive contents

8.1 MAY include

selected raw log bundles
operator advisory documents
public status summaries
bug intake summaries
conformance linkage bundles
release notes and launch notes
public communications snapshots
dashboard export bundles

8.2 Rule

Artefactele opționale MUST NOT be confused with normative truth layer.

9. Normative artifact families

9.1 Normative archive families SHOULD include:

release and genesis artifacts
package manifests
artifact attestations
ceremony records
checklist records
decision ledger records
monitoring records referenced by decisions/review
stabilization review records
scope manifests
archive manifest

9.2 Rule

Acestea SHOULD be machine-verifiable and canonical.

10. Auxiliary artifact families

10.1 Auxiliary families MAY include:

human-readable summaries
analyst notes
screenshots
charts
dashboard exports
operator memos
communication transcripts
long-form postmortem narrative

10.2 Rule

Auxiliary artifacts MUST be clearly labeled non-normative unless they themselves have a canonical object form.

11. Archive manifest

11.1 Canonical structure

MainnetAuditArchiveManifest {
  version_major
  version_minor

  archive_id
  archive_class
  archive_scope
  normative_entry_root
  auxiliary_entry_root?
  attestation_root?
  retention_policy_hash
  creation_time_unix_ms
  metadata_hash?
}

11.2 archive_id

archive_id = H("AZ:MAINNET_AUDIT_ARCHIVE:" || canonical_archive_manifest)

11.3 Rule

The archive manifest MUST be the primary canonical entry point into the archive.

12. Archive entries

12.1 Canonical structure

ArchiveEntry {
  entry_id
  entry_class
  artifact_ref
  required
  normative
  path_hash?
  notes_hash?
}

12.2 entry_class examples

release_package
genesis_package
ceremony_record
confirmation_record
checklist_record
decision_record
monitoring_snapshot
anomaly_record
incident_record
stabilization_record
recommendation_bundle
advisory_doc
log_bundle

12.3 Rule

Required normative entries MUST be explicitly marked.

13. Normative entry root derivation

13.1 Rule

All normative entries MUST be ordered canonically and hashed into:

entry_hash_i = H("AZ:ARCHIVE_ENTRY:" || canonical_entry_i)
normative_entry_root = MerkleRoot(entry_hash_i...)

13.2 auxiliary_entry_root

Derived similarly for non-normative entries.

13.3 Rule

Archive integrity verification SHOULD begin from normative_entry_root.

14. Archive integrity model

14.1 Integrity checks MUST cover:

archive manifest hash
normative entry root
all referenced artifact identities
no missing required entries
no conflicting duplicate required roles
attestation sufficiency where required
scope consistency across all critical records

14.2 Rule

An archive with intact files but broken scope coherence is still invalid.

15. Archive completeness model

15.1 Completeness means at least:

all required records present
all required package and decision lineage reconstructible
no unresolved reference gaps in normative layer
enough evidence to explain active decisions and stabilization verdict

15.2 Rule

Completeness is not about “lots of files”. It is about reconstructibility.

16. Scope consistency rules

16.1 Critical records inside archive MUST agree on:

target_network_class
chain_id
genesis_hash
release_package_id
genesis_package_id
relevant launch_window_id where applicable

16.2 Rule

Any scope mismatch in normative launch records SHOULD trigger archive invalidity or quarantine.

17. Decision ledger bundle

17.1 The archive SHOULD include a decision ledger subset containing:

active launch decisions
superseded decisions relevant to launch path
hold/proceed/go/defer/abort history
restricted posture enter/exit decisions
restart/rejoin decisions relevant to early mainnet if material

17.2 Rule

The bundle SHOULD preserve append order or ledger hash chain.

18. Ceremony bundle

18.1 SHOULD include

GenesisCeremonyRecord
GenesisCeremonyConfirmations
LaunchCeremonyRecord
LaunchCeremonyConfirmations
GoNoGoDecisionRecord linkage
LaunchAuthorizationRecord
BootstrapExecutionRecord
LaunchObservationRecords

18.2 Rule

Ceremony bundle MUST be sufficient to reconstruct the formal path from package verification to network start.

19. Checklist bundle

19.1 SHOULD include

prelaunch artifact checklist results
environment checklist results
keys and roles checklist results
preflight checklist results
launch window final checks
role-specific checklists
first blocks / first epochs checklists
incident/restart/rejoin checklists if relevant
normalization or restricted posture checklists if used

19.2 Rule

Not every local checklist from every auxiliary observer node must be included, but all material launch-critical checklist evidence SHOULD be preserved.

20. Monitoring bundle

20.1 SHOULD include

monitoring profile ids and versions used
monitoring snapshots over review windows
anomaly records
health assessments
escalation records if any
restricted posture exit monitoring evidence

20.2 Rule

Monitoring bundle SHOULD be sufficient to justify why stabilization verdict was reached.

21. Incident bundle

21.1 If incidents occurred, archive SHOULD include:

incident records
severity and state transitions
evidence refs
related decision records
related recommendations or remediation notes
closure or still-open status

21.2 Rule

An open critical incident MUST be visible in the archive summary.

22. Stabilization bundle

22.1 SHOULD include

StabilizationReviewRecord
findings
evidence root mapping
recommendations
action plan
resulting operational decisions
restricted posture exit or continuation decision

22.2 Rule

This bundle is mandatory for a full post-launch audit package.

23. Attestation bundle

23.1 SHOULD include

critical artifact attestations
release approval attestations
mainnet approval attestations
archive approval attestations if policy uses them
any revocation or supersession of critical approvals relevant to launch scope

23.2 Rule

Attestation bundle SHOULD prove provenance and approval closure, not just archive file presence.

24. Log bundle policy

24.1 Logs MAY be large and noisy.

The archive SHOULD distinguish:

required log evidence
optional raw logs
summarized log extracts

24.2 Required log evidence SHOULD include only what is necessary for:

critical anomalies
bootstrap window reconstruction
first epoch issues
incident correlation
restart/rejoin evidence if material

24.3 Rule

Raw logs SHOULD be referenced or chunked carefully. They MUST NOT obscure the normative layer.

25. Checksum bundle

25.1 Purpose

Operational quick verification.

25.2 SHOULD include

archive manifest hash
entry counts
required artifact hashes
size summaries
optional top-level file list hashes

25.3 Rule

Checksums are auxiliary; they do not replace canonical archive manifest validation.

26. Archive attestation policy

26.1 Serious archives SHOULD require:

hash confirmation
archive completeness review
archive approval for audit scope
possibly multi-role approval for mainnet full audit package

26.2 Suggested roles

audit scribe
ops lead
release manager
security lead
launch coordinator

26.3 Rule

A full audit package SHOULD have stronger approval than an internal convenience export.

27. Archive status classes

27.1 Recommended statuses

ARCHIVE_DRAFT
ARCHIVE_REVIEWED
ARCHIVE_COMPLETE
ARCHIVE_COMPLETE_WITH_NOTES
ARCHIVE_INCOMPLETE
ARCHIVE_SUPERSEDED
ARCHIVE_REVOKED

27.2 Rule

Mainnet-class archive SHOULD reach ARCHIVE_COMPLETE or ARCHIVE_COMPLETE_WITH_NOTES explicitly.

28. Archive supersession

28.1 Need

A later, more complete audit package may supersede an earlier one.

28.2 Rule

Supersession MUST be explicit:

old archive_id
new archive_id
reason
scope relation
whether old package was incomplete or merely preliminary

28.3 Rule

Old archive remains visible and auditable.

29. Archive revocation

29.1 Need

An archive may be found corrupted or misleading.

29.2 Rule

Revocation MUST be explicit and SHOULD include:

target archive_id
reason hash
evidence refs
whether replacement archive exists

29.3 Rule

Revocation MUST NOT silently delete historical launch evidence.

30. Retention policy

30.1 A retention policy SHOULD define:

minimum retention duration
replication count
storage classes
integrity recheck frequency
offline or cold archive strategy
who can access or export

30.2 Rule

Launch-critical audit archives SHOULD have long retention horizons appropriate to network seriousness.

31. Replication and preservation strategy

31.1 Recommended strategy

multiple copies
multiple storage backends
at least one offline/cold copy for critical scope
periodic integrity verification
manifest-first restoration process

31.2 Rule

Copies are not trustworthy merely because they exist. They must be reverified.

32. Recovery / re-import procedure

32.1 A valid recovery SHOULD:

load archive manifest
verify manifest integrity
verify required entry presence
verify normative entry root
verify referenced artifacts and records
rebuild indices
reconstruct launch/stabilization lineage
compare expected scope and roots

32.2 Rule

Re-imported archive MUST produce same archive identity and same normative roots.

33. Auditor usage model

33.1 A competent auditor SHOULD be able to answer from archive:

what exact artifacts were launched?
what exact genesis/release scope was used?
who approved what?
what blockers existed and how were they resolved?
what happened during launch window?
what anomalies occurred?
what was the stabilization verdict and why?
what restrictions remained or were lifted?

33.2 Rule

If archive cannot answer these, it is not sufficient as audit package.

34. Archive query model

34.1 Useful query classes

by artifact id
by decision id
by checklist class
by ceremony id
by launch window id
by anomaly class
by incident id
by stabilization review id
by chain_id / genesis_hash

34.2 Rule

Indexes MAY accelerate queries, but truth remains in manifests and records.

35. Archive summary object

35.1 Recommended structure

ArchiveSummaryRecord {
  summary_id
  archive_id
  target_network_class
  target_chain_id
  target_genesis_hash
  launch_window_id
  stabilization_review_id?
  active_decision_root
  open_incident_root?
  key_findings_root?
}

35.2 Rule

Summary records are navigational aids, not replacements for full archive verification.

36. Interaction with vault

36.1 The archive SHOULD itself be admitted into the secure artifact vault as:

an archive manifest artifact
optional archive container artifact
checksum bundle artifact
attestation bundle artifact

36.2 Rule

Archive package SHOULD benefit from same integrity and admission protections as other critical artifacts.

37. Interaction with conformance and bug intake

37.1 Archive MAY include refs to:

post-launch bug reports that influenced stabilization
corpus updates triggered by launch findings
regression cases added after anomalies

37.2 Rule

Where these materially affected decisions, they SHOULD be preserved or linked.

38. Interaction with governance and public communication

38.1 If launch or stabilization involved governance/emergency decisions, archive SHOULD include their refs.

38.2 If public advisories materially shaped operator behavior, archive MAY include authoritative copies or refs.

38.3 Rule

The archive should preserve truth-relevant governance and communications context, not every incidental message.

39. Anti-patterns

Systems SHOULD avoid:

archive as one flat zip with no manifest discipline
preserving only binaries and not decisions/checklists
preserving only summaries and not canonical records
mixing normative and auxiliary files with no labels
no scope binding to chain_id/genesis_hash
deleting superseded or revoked audit packages
logs with no linkage to decisions or incidents
archives that cannot be re-verified independently
no retention strategy
silent post-hoc edits to archive contents

40. Formal goals

AZ-033 urmărește aceste obiective:

40.1 Historical reconstructibility

A future reviewer can reconstruct launch and early stabilization truth exactly enough.

40.2 Integrity preservation

Archived launch truth remains verifiable over time.

40.3 Scope coherence

All critical archived records agree on exact launch scope.

40.4 Durable audit utility

The archive remains useful for audits, postmortems, governance review and future launch discipline.

41. Formula documentului

Mainnet Artifact Archive = scope-bound archive manifest + normative record bundles + attestation and integrity roots + retention and recovery policy + audit-grade reconstructibility

42. Relația cu restul suitei

AZ-030 definește ledger-ul deciziilor.
AZ-031 definește monitoring profiles.
AZ-032 definește stabilization review.
AZ-033 definește pachetul durabil care conservă toate aceste adevăruri într-o arhivă verificabilă.

Pe scurt: AZ-032 spune ce verdict dai după stabilizare; AZ-033 păstrează dovada completă a drumului până la acel verdict.

43. Ce urmează

După AZ-033, direcțiile cu valoare maximă sunt:

AZ-034 — Governance Upgrade and Hard Fork Protocol
AZ-035 — Key Rotation, Key Compromise and Recovery Protocol
AZ-036 — Network Upgrade Rollout and Version Compatibility Matrix
AZ-037 — Long-Term Archive Verification and Preservation Schedule
AZ-038 — External Audit Interface and Evidence Export Format

Închidere

Un launch bine făcut poate fi uitat repede de oameni. Dar dacă nu îi păstrezi artefactele, deciziile și dovezile într-o arhivă serioasă, peste timp nu mai rămâne decât memorie fragmentară și interpretare.

Acolo începe arhiva cu valoare reală: nu doar păstrează fișiere, ci conservă adevărul verificabil al lansării și al primei stabilizări.