AZ-043 — Constitutional Record and Network Identity Canon v1

Status

Acest document definește canonul constituțional al identității de rețea și al recordurilor normative ultime pentru ATLAS ZERO.

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

• specificația protocolului și a subsistemelor;
• modelul genesis, launch, upgrade, hard fork, archive și audit;
• threat canon, conformance claims și incident postmortem canon.

AZ-043 răspunde la întrebarea: ce recorduri constituționale definesc identitatea ultimă a rețelei, cum se leagă între ele de-a lungul timpului și cum distingem fără ambiguitate între continuitate legitimă, upgrade compatibil, hard fork incompatibil și istorie normativă separată?

Scopul documentului este să fixeze:

• setul de recorduri constituționale;
• relația dintre chain identity, genesis, governance-critical records și fork lineage;
• canonul memoriei normative ultime a rețelei;
• regulile de supersession, continuity și constitutional divergence;
• și verificarea pe termen lung a identității rețelei.

Acest document se bazează pe:

• AZ-002 până la AZ-042, cu accent direct pe AZ-009, AZ-016, AZ-017, AZ-022, AZ-026, AZ-033, AZ-034, AZ-037, AZ-038 și AZ-042.

Termeni:

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

1. Obiectiv

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

1. Ce este un constitutional record în ATLAS ZERO?
2. Ce definește identitatea ultimă a unei rețele?
3. Cum se leagă genesis, chain_id și lineage-ul de upgrade/fork?
4. Ce recorduri sunt constituționale și nu doar operaționale?
5. Cum distingem continuitatea legitimă de o ramură normativă separată?
6. Cum tratăm hard fork-urile incompatibile și noua identitate de rețea?
7. Cum se leagă recordurile critice de guvernanță de memoria constituțională?
8. Cum se verifică acest canon după ani de upgrade-uri și incidente?
9. Cum exportăm și arhivăm canonul constituțional pentru audit și guvernanță?
10. Cum evităm identități de rețea ambigue, suprapuse sau rescrise retroactiv?

2. Principii

2.1 Network identity is a constitutional fact set, not just a string

Identitatea rețelei MUST fi tratată ca set de recorduri normative legate între ele, nu doar ca valoare textuală chain_id.

2.2 Constitutional records define the uppermost truth boundary

Există recorduri a căror pierdere sau ambiguitate afectează însuși răspunsul la întrebarea: „ce rețea este aceasta?” Acestea MUST fi tratate distinct.

2.3 Continuity must be provable

Continuitatea dintre faze, launch, upgrade și guvernanță MUST putea fi reconstruită prin recorduri și linkage explicit, nu prin interpretare istorică liberă.

2.4 Incompatible divergence creates constitutional branching

Dacă apare hard fork incompatibil sau altă divergență normativă majoră, noua ramură MUST fi tratată constituțional ca distinctă, cu identitate și lineage explicit.

2.5 Constitutional memory must resist silent mutation

Recordurile constituționale MUST NOT fi rescrise tăcut. Supersession, revocation și branching MUST fi explicite și auditate.

2.6 Governance legitimacy must anchor into constitutional memory

Recordurile critice de guvernanță care schimbă identitatea sau regulile fundamentale ale rețelei SHOULD intra în canonul constituțional.

3. Constitutional canon purpose

3.1 The canon SHOULD answer:

• care este identitatea acestei rețele?
• care a fost genesis-ul ei normativ?
• ce upgrade-uri și fork-uri au păstrat continuitatea?
• ce evenimente au creat ramuri distincte?
• ce recorduri de guvernanță sunt constituțional decisive?
• care este lanțul de memorie normativă până în prezent?

3.2 Rule

Dacă canonul nu poate răspunde acestor întrebări, este insuficient.

4. Constitutional record classes

4.1 Recommended constitutional record classes

ATLAS ZERO SHOULD include cel puțin:

• CR_CHAIN_IDENTITY
• CR_GENESIS_ROOT
• CR_GENESIS_PACKAGE_IDENTITY
• CR_LAUNCH_AUTHORIZATION
• CR_MAINNET_START_RECORD
• CR_CONSTITUTIONAL_GOVERNANCE_ACT
• CR_HARD_FORK_DECLARATION
• CR_FORK_LINEAGE_RECORD
• CR_CHAIN_CONTINUITY_RECORD
• CR_CONSTITUTIONAL_ARCHIVE_ROOT
• CR_NETWORK_IDENTITY_SUMMARY

4.2 Rule

Nu orice record important este constituțional. Doar cele care schimbă sau definesc identitatea și continuitatea ultimă a rețelei SHOULD intra aici.

5. Constitutional asset classes

5.1 Canon SHOULD protect active classes such as:

• network identity
• genesis truth
• constitutional governance legitimacy
• fork lineage truth
• archival constitutional memory
• continuity of protocol authority
• replay separation across constitutional branches

5.2 Rule

Threats against these assets SHOULD be tracked explicitly in threat canon.

6. Network identity model

6.1 A network identity SHOULD be defined by:

• target_network_class
• chain_id
• genesis_hash
• constitutional lineage root
• current constitutional policy root or equivalent governance anchor
• current canonical continuity record

6.2 Rule

No single field alone SHOULD be treated as complete identity for constitutional purposes.

7. Chain identity record

7.1 Canonical structure

ChainIdentityRecord {
  version_major
  version_minor

  chain_identity_record_id
  target_network_class
  chain_id
  genesis_hash
  genesis_package_id
  constitutional_lineage_root
  creation_boundary_hash
  metadata_hash?
}

7.2 Rule

This record SHOULD anchor the base identity from which constitutional continuity is evaluated.

8. Genesis root as constitutional anchor

8.1 Genesis root means more than bootstrapping data.

It defines the normative time-zero identity of the chain.

8.2 Constitutional canon SHOULD preserve:

• genesis_hash
• genesis package identity
• derived roots commitment
• chain identity linkage
• launch authorization linkage

8.3 Rule

A network whose genesis truth is ambiguous is constitutionally unstable.

9. Launch authorization as constitutional boundary

9.1 Launch is not just operational.

For mainnet-class scope it establishes a constitutional start boundary.

9.2 Canon SHOULD preserve:

• launch ceremony scope
• GO / authorization records
• bootstrap execution record
• linkage from genesis and release to first live network identity

9.3 Rule

Mainnet start SHOULD be constitutionally reconstructible.

10. Constitutional governance acts

10.1 Not every governance action is constitutional.

A constitutional governance act is one that changes or reaffirms identity-defining truth.

10.2 Examples

• adoption of genesis and launch scope
• approval of incompatible hard fork
• ratification of constitutional policy changes
• chain continuity ratification after exceptional recovery
• constitutional authority reassignment if protocol permits

10.3 Rule

These acts SHOULD be recorded separately from ordinary parameter changes.

11. Constitutional governance act record

11.1 Canonical structure

ConstitutionalGovernanceAct {
  act_id
  act_class
  scope_hash
  governing_authority_root
  decision_root
  evidence_root?
  timestamp_unix_ms
}

11.2 act_class examples

• launch_ratification
• hard_fork_ratification
• constitutional_policy_change
• continuity_confirmation
• constitutional_recovery_ratification

11.3 Rule

A constitutional act MUST bind exact scope and decision lineage.

12. Continuity model

12.1 Need

The system must distinguish:

• same chain continuing;
• same chain upgraded compatibly;
• same chain under ratified exceptional recovery;
• different chain created by incompatible divergence.

12.2 Canonical structure

ChainContinuityRecord {
  continuity_id
  prior_identity_ref
  new_identity_ref
  continuity_class
  justification_hash
  governance_act_ref?
  evidence_root?
  timestamp_unix_ms
}

12.3 continuity_class

• compatible_continuation
• compatible_upgrade_continuation
• exceptional_recovery_continuation
• incompatible_branch_split
• identity_reissuance_after_recovery
• continuity_disputed

12.4 Rule

Continuity MUST be explicit whenever ambiguity would otherwise exist.

13. Hard fork constitutional model

13.1 A hard fork becomes constitutional issue when:

• it changes incompatible protocol truth;
• it creates competing claims to continuity;
• it needs identity separation;
• it changes governance legitimacy path.

13.2 Rule

Incompatible hard fork SHOULD generate:

• hard fork declaration;
• fork lineage record;
• new or separated network identity record;
• continuity or divergence statement.

14. Hard fork declaration record

14.1 Canonical structure

HardForkDeclarationRecord {
  declaration_id
  prior_chain_identity_ref
  new_chain_identity_ref?
  fork_boundary_hash
  fork_class
  replay_separation_root
  governance_act_ref
  release_package_root
  timestamp_unix_ms
}

14.2 fork_class

• incompatible_protocol_split
• emergency_constitutional_split
• recovery_driven_split
• governance_disputed_split

14.3 Rule

Hard fork declarations MUST be explicit, not inferred retroactively from code divergence alone.

15. Fork lineage record

15.1 Purpose

Preserves the branch structure of constitutional history.

15.2 Canonical structure

ForkLineageRecord {
  lineage_record_id
  parent_chain_identity_ref
  child_chain_identity_ref
  fork_declaration_ref
  divergence_boundary_hash
  branch_status
}

15.3 branch_status

• canonical_child
• sibling_branch
• historical_branch
• disputed_branch
• archived_branch

15.4 Rule

Branch status SHOULD be governance-visible and historically preserved.

16. Constitutional lineage root

16.1 Need

Identity requires chainable lineage.

16.2 The canon SHOULD derive lineage root from:

• genesis constitutional anchor
• continuity records
• constitutional governance acts
• hard fork declarations
• fork lineage records

16.3 Rule

The lineage root SHOULD summarize constitutional history in canonical, ordered form.

17. Constitutional lineage entry

17.1 Canonical structure

ConstitutionalLineageEntry {
  entry_id
  entry_class
  record_ref
  effective_boundary_hash
}

17.2 entry_class examples

• genesis_anchor
• launch_boundary
• continuity_event
• constitutional_act
• fork_event
• recovery_identity_event

17.3 Rule

Entries MUST be canonically ordered and hash-linked.

18. Network identity summary record

18.1 Purpose

Provides a compact auditor/operator-facing constitutional snapshot.

18.2 Canonical structure

NetworkIdentitySummaryRecord {
  summary_id
  chain_identity_ref
  latest_constitutional_lineage_root
  latest_constitutional_act_root?
  latest_continuity_ref?
  latest_fork_status_root?
  timestamp_unix_ms
}

18.3 Rule

This summary is navigational. Underlying record chain remains authoritative.

19. Constitutional archive root

19.1 Need

Constitutional memory must point to archival preservation.

19.2 Canon SHOULD include:

• archive ids containing constitutional records
• preservation scope refs
• latest verification runs for constitutional archives
• export refs if public/audit-facing

19.3 Rule

Constitutional records without durable archive linkage are weak over long horizons.

20. Constitutional archive record

20.1 Canonical structure

ConstitutionalArchiveRecord {
  constitutional_archive_id
  constitutional_scope_hash
  archive_root
  preservation_root?
  export_root?
  timestamp_unix_ms
}

20.2 Rule

High-criticality constitutional records SHOULD be anchored to preserved archive packages.

21. Constitutional identity verification path

21.1 A verifier SHOULD be able to:

1. load chain identity record
2. verify genesis anchor linkage
3. verify launch authorization linkage
4. replay continuity records
5. inspect constitutional governance acts
6. inspect fork declarations and lineage if any
7. verify latest constitutional lineage root
8. verify archive preservation linkage

21.2 Rule

Identity verification SHOULD be possible even years later from preserved records.

22. Constitutional divergence model

22.1 Sometimes divergence is not just upgrade, but competing normativities.

22.2 divergence classes SHOULD include:

• explicit_ratified_split
• disputed_split
• accidental_split_later_ratified
• continuity_break_due_to_unratified_change
• recovery_continuity_dispute

22.3 Rule

Divergence SHOULD not be hidden under vague “version difference” language.

23. Continuity dispute record

23.1 Canonical structure

ContinuityDisputeRecord {
  dispute_id
  disputed_scope_hash
  claimant_record_root
  conflict_statement_hash
  evidence_root?
  timestamp_unix_ms
}

23.2 Rule

If continuity is materially disputed, canon SHOULD represent dispute explicitly until resolved.

24. Constitutional recovery model

24.1 Exceptional recovery after severe incident MAY raise constitutional continuity questions.

24.2 Rule

If recovery changes identity-defining state or boundaries unusually, it SHOULD generate:

• continuity record
• governance act
• archive updates
• explicit identity summary refresh

24.3 Rule

Recovery MUST NOT silently mutate constitutional memory.

25. Relationship to ordinary governance

25.1 Ordinary governance acts like parameter tuning or routine upgrades are not automatically constitutional.

25.2 They become constitutional when they:

• redefine identity;
• redefine continuity;
• authorize incompatible branch;
• ratify exceptional recovery;
• or change the authority structure of constitutional governance itself.

25.3 Rule

This distinction MUST remain explicit to avoid bloating constitutional canon with ordinary operational noise.

26. Relationship to launch canon

26.1 Constitutional canon SHOULD absorb from launch:

• genesis package identity
• launch ceremony ratification if constitutional
• launch authorization
• mainnet start record
• initial chain identity summary

26.2 Rule

Launch records that defined chain birth MUST be constitutionally preserved.

27. Relationship to upgrade and fork canon

27.1 Constitutional canon SHOULD absorb from upgrades:

• only those upgrades with constitutional effect;
• all incompatible hard fork declarations;
• continuity and lineage records;
• governance ratification of branch legitimacy if required.

27.2 Rule

Compatible upgrades MAY remain outside constitutional canon except via continuity summaries where helpful.

28. Relationship to threat and risk canon

28.1 Threat canon SHOULD include risks such as:

• identity ambiguity
• genesis substitution
• replay across branches
• disputed continuity after recovery
• constitutional archive corruption
• governance capture over constitutional acts

28.2 Rule

Constitutional record integrity is a first-class protected asset.

29. Relationship to audit export

29.1 External audit interface SHOULD support exports for:

• chain identity proof
• genesis constitutional anchor proof
• hard fork lineage proof
• continuity proof
• constitutional governance act proof
• constitutional archive verification proof

29.2 Rule

Constitutional exports SHOULD be minimally redacted and highly scope-bound.

30. Relationship to conformance claims

30.1 Some claims MAY depend on constitutional canon, for example:

• “this release is for chain X”
• “this hard fork creates a distinct identity”
• “this archive preserves the authoritative constitutional lineage”
• “this genesis package is the canonical birth artifact for network Y”

30.2 Rule

Conformance claims touching identity SHOULD reference constitutional records, not only operational documents.

31. Constitutional status model

31.1 Recommended status classes

• CONST_ACTIVE
• CONST_SUPERSEDED
• CONST_REVOKED
• CONST_HISTORICAL
• CONST_DISPUTED
• CONST_ARCHIVED

31.2 Rule

Constitutional records MUST remain historically visible even when superseded.

32. Constitutional supersession

32.1 Some records may be superseded, e.g. identity summary or continuity summary.

32.2 Rule

Supersession MUST be explicit and MUST NOT rewrite genesis, hard fork or governance act history.

32.3 Rule

Primary constitutional anchors like genesis SHOULD almost never be superseded except through explicit branch creation, not revision.

33. Constitutional revocation

33.1 Need

A record may be incorrect, forged or invalidated by better evidence.

33.2 Rule

Revocation MUST be explicit and SHOULD include:

• target record id
• reason hash
• authority basis
• replacement ref if any
• effect on lineage root

33.3 Rule

Revocation MUST preserve historical trace of the erroneous record.

34. Canon maintenance and review

34.1 Constitutional canon SHOULD be reviewed when:

• mainnet launches
• incompatible hard fork proposed or ratified
• exceptional recovery changes continuity
• constitutional governance authority changes
• archive preservation incident affects constitutional records
• external audit finds identity ambiguity

34.2 Rule

Canon review SHOULD produce updated identity summary and lineage root where needed.

35. Constitutional canon object

35.1 Canonical structure

ConstitutionalRecordCanon {
  version_major
  version_minor

  canon_id
  canon_scope_hash
  constitutional_record_root
  lineage_root
  current_identity_summary_ref
  archive_root?
  timestamp_unix_ms
}

35.2 Rule

This canon object SHOULD act as top-level constitutional entry point.

36. Anti-patterns

36.1 Systems SHOULD avoid:

1. treating chain_id alone as full constitutional identity
2. hard fork without lineage record
3. exceptional recovery with silent continuity assumptions
4. constitutional governance acts buried among ordinary governance noise
5. archive packages with no constitutional root linkage
6. rewriting launch origin after the fact
7. disputed continuity handled only socially, not canonically
8. replay-separated branches still presented as same identity
9. no explicit constitutional exports for auditors
10. no distinction between operational summary and constitutional anchor

37. Formal goals

AZ-043 urmărește aceste obiective:

37.1 Identity clarity

The network can state exactly what chain it is and why.

37.2 Continuity and branching clarity

Compatible continuation, exceptional recovery and incompatible branch split are distinguished explicitly.

37.3 Durable constitutional memory

Identity-defining records remain preserved, queryable and auditable over long horizons.

37.4 Governance legitimacy linkage

Constitutional changes are tied to visible governance acts and preserved lineage.

38. Formula documentului

Constitutional Network Identity = genesis anchor + chain identity record + launch boundary + constitutional governance acts + explicit continuity/fork lineage + preserved constitutional archive

39. Relația cu restul suitei

• AZ-034 definește upgrade și hard fork discipline.
• AZ-037 definește păstrarea pe termen lung a arhivelor.
• AZ-042 definește memoria incidentelor.
• AZ-043 definește memoria normativă ultimă a identității rețelei și a ramurilor ei.

Pe scurt: AZ-043 este stratul constituțional care spune nu doar cum funcționează rețeaua, ci ce rețea este în sens normativ ultim.

40. Ce urmează

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

1. AZ-044 — Protocol Parameter Registry Canon
2. AZ-045 — Formal Recovery Boundary and State Legitimacy Framework
3. AZ-046 — Validator Set Legitimacy and Membership Canon
4. AZ-047 — Treasury, Reserve and Public Financial Truth Canon
5. AZ-048 — Public Network Truth Export and Verification Interface

Închidere

O rețea poate avea cod, noduri, stare și utilizatori. Dar, fără memorie constituțională clară, în timp devine vulnerabilă la cea mai periculoasă formă de corupere: ambiguitatea despre cine este și de unde vine.

Acolo începe canonul constituțional real: când genesis-ul, identitatea, fork-urile și actele decisive de guvernanță devin o istorie normativă verificabilă, nu doar o tradiție povestită.