AZ-045 — Formal Recovery Boundary and State Legitimacy Framework v1

Status

Acest document definește cadrul formal pentru:

• recovery boundary;
• legitimitatea stării după incidente grave;
• continuitatea versus ruptura legitimă;
• și recordurile prin care recuperarea devine auditabilă, guvernabilă și constituțional clară.

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

• specificația protocolului și a subsistemelor;
• modelul de incident response, recovery operațional, launch, upgrade și hard fork;
• canonul constituțional al identității de rețea;
• registrul parametrilor protocolari;
• arhivele, exporturile de audit și canonul postmortem-urilor.

AZ-045 răspunde la întrebarea: ce înseamnă recovery legitim al unei rețele vii după incident grav, unde este granița dintre restaurare legitimă și rescriere nelegitimă a istoriei, și cum păstrăm clar, verificabil și ratificat adevărul despre ce stare este recunoscută ca legitimă după o astfel de tranziție?

Scopul documentului este să fixeze:

• noțiunea de recovery boundary;
• clasele de recovery;
• modelul de legitimitate a stării;
• obiectele de ratificare, continuitate și divergență;
• regulile pentru replay, snapshot, restore, rollback și reissue de identitate;
• relația cu constitutional canon, hard fork canon, archive și governance.

Acest document se bazează pe:

• AZ-002 până la AZ-044, cu accent direct pe AZ-015, AZ-016, AZ-017, AZ-026, AZ-028, AZ-032, AZ-033, AZ-034, AZ-037, AZ-042, AZ-043 și AZ-044.

Termeni:

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

1. Obiectiv

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

1. Ce este un recovery boundary?
2. Ce face o stare „legitimă” după incident?
3. Când este recovery doar restaurare și când devine schimbare constituțională?
4. Ce recorduri ratifică alegerea unei stări post-incident?
5. Cum distingem rollback legitim, replay legitim și rescriere nelegitimă?
6. Cum tratăm stările concurente sau disputate?
7. Cum se leagă recovery-ul de hard fork, continuity și constitutional canon?
8. Cum exportăm și audităm legitimitatea stării recuperate?
9. Cum evităm improvizația sub presiune în incidente severe?
10. Cum păstrăm pe termen lung memoria exactă a acestei tranziții?

2. Principii

2.1 Recovery legitimacy is a first-class protocol governance concern

Legitimitatea stării după recovery MUST fi tratată ca problemă normativă și de guvernanță, nu doar ca problemă tehnică de infrastructură.

2.2 Not every restore is constitutionally neutral

Unele acțiuni de restore/replay sunt simple recuperări operaționale. Altele mută granița adevărului istoric. Această diferență MUST fi explicită.

2.3 State legitimacy must be reconstructible

Pentru o stare post-incident, un auditor SHOULD putea reconstrui:

• de ce a fost aleasă;
• ce alternative existau;
• ce boundary a fost folosit;
• ce dovezi au susținut alegerea;
• ce autoritate a ratificat-o.

2.4 Recovery should preserve maximum legitimate continuity

Sistemul SHOULD prefera recovery care păstrează cât mai multă continuitate legitimă posibilă, dar nu cu prețul ambiguității sau al continuării sub stare nesigură.

2.5 Dispute must be explicit, not suppressed

Dacă există ambiguitate materială sau conflict despre starea legitimă, canonul SHOULD reprezenta disputa explicit până la rezolvare.

2.6 Recovery records must outlive the crisis

Recordurile de recovery MUST rămâne parte din memoria normativă și auditabilă a rețelei, nu doar artefacte temporare de incident.

3. Recovery purpose

3.1 Framework-ul SHOULD răspunde:

• care a fost ultima stare legitimă necontestată?
• ce boundary de recovery a fost ales?
• ce s-a păstrat și ce s-a abandonat?
• a continuat aceeași rețea legitimă sau s-a creat o ramură nouă?
• ce autoritate a aprobat și pe ce bază?
• cum poate fi verificată această decizie mai târziu?

3.2 Rule

Fără aceste răspunsuri, recovery-ul rămâne vulnerabil la reinterpretare retrospectivă.

4. Recovery classes

4.1 Recommended recovery classes

ATLAS ZERO SHOULD distinge cel puțin:

• RC_LOCAL_NODE_RESTORE
• RC_CLUSTER_REPLAY_RECOVERY
• RC_NETWORK_SAFE_MODE_RECOVERY
• RC_CHECKPOINT_ROLLBACK_RECOVERY
• RC_STATE_RECONSTRUCTION_RECOVERY
• RC_EXCEPTIONAL_CONSTITUTIONAL_RECOVERY
• RC_FORKED_RECOVERY_CONTINUATION
• RC_ABORTED_RECOVERY_ATTEMPT

4.2 Meaning

RC_LOCAL_NODE_RESTORE

Recovery local, fără schimbare de adevăr protocolar.

RC_CLUSTER_REPLAY_RECOVERY

Refacere prin replay/rejoin în același adevăr de rețea.

RC_NETWORK_SAFE_MODE_RECOVERY

Recuperare coordonată sub restricții de rețea.

RC_CHECKPOINT_ROLLBACK_RECOVERY

Revenire la checkpoint anterior recunoscut.

RC_STATE_RECONSTRUCTION_RECOVERY

Reconstrucție formală din artefacte și dovezi, nu doar replay simplu.

RC_EXCEPTIONAL_CONSTITUTIONAL_RECOVERY

Recuperare care atinge legitimitatea istoriei sau a identității și cere ratificare constituțională.

RC_FORKED_RECOVERY_CONTINUATION

Recuperare care creează sau recunoaște ramură separată.

4.3 Rule

Recovery class MUST be explicit because legitimacy and governance implications differ radically.

5. Recovery boundary definition

5.1 A recovery boundary is the exact boundary at which:

• system truth is re-anchored;
• state legitimacy is reasserted;
• recovery actions become effective;
• old post-boundary history may be abandoned, disputed or superseded.

5.2 Boundary classes SHOULD include:

• finalized_epoch_boundary
• finalized_block_boundary
• snapshot_root_boundary
• replay_cutoff_boundary
• constitutional_recovery_boundary
• fork_boundary

5.3 Rule

Boundary MUST be explicit and verifiable.

6. Recovery boundary object

6.1 Canonical structure

RecoveryBoundaryRecord {
  version_major
  version_minor

  recovery_boundary_id
  boundary_class
  target_network_class
  target_chain_id
  reference_state_root
  reference_finalized_root?
  reference_epoch_index?
  reference_block_height?
  timestamp_unix_ms?
  scope_hash
}

6.2 Rule

Fields used MUST match boundary_class exactly. No ambiguous hybrid boundary unless explicitly modeled.

7. State legitimacy model

7.1 A state is legitimate for scope X when:

• it is derivable or reconstructible from accepted canonical inputs;
• it is ratified or recognized by the appropriate authority for that scope;
• it does not conflict with higher-priority constitutional truth still in force;
• and its lineage to prior accepted state is explicit or explicitly broken.

7.2 Rule

Legitimacy MUST be modeled separately from mere availability or convenience.

8. State legitimacy classes

8.1 Recommended classes

• SL_NATIVE_CONTINUATION
• SL_RECOVERED_CONTINUATION
• SL_EXCEPTIONAL_BUT_RATIFIED
• SL_DISPUTED
• SL_SUPERSEDED
• SL_INVALID
• SL_BRANCH_SPECIFIC

8.2 Meaning

SL_NATIVE_CONTINUATION

Normal continuation with no exceptional legitimacy questions.

SL_RECOVERED_CONTINUATION

Legitimate state restored through recovery, but continuity remains same.

SL_EXCEPTIONAL_BUT_RATIFIED

Exceptional state accepted through stronger authority and process.

SL_DISPUTED

State legitimacy materially contested or unresolved.

SL_BRANCH_SPECIFIC

State legitimate only on a specific branch after fork/divergence.

8.3 Rule

State legitimacy class SHOULD be part of recovery records and audit exports.

9. Legitimate state record

9.1 Canonical structure

LegitimateStateRecord {
  version_major
  version_minor

  legitimate_state_id
  recovery_boundary_ref
  resulting_state_root
  legitimacy_class
  continuity_ref?
  governance_act_ref?
  evidence_root?
  timestamp_unix_ms
  notes_hash?
}

9.2 Rule

This record SHOULD be the canonical statement that a given resulting state is recognized as legitimate for the declared scope.

10. Continuity versus rupture

10.1 Continuity exists when:

• the recovered state is accepted as lawful continuation of prior chain identity;
• replay or restore stays within authorized boundaries;
• constitutional canon confirms the continuation.

10.2 Rupture exists when:

• recovered state requires new identity;
• prior history after some boundary is not accepted as continuing same network truth;
• hard fork or constitutional split occurs.

10.3 Rule

The system MUST explicitly choose continuity or rupture when recovery reaches constitutional significance.

11. Recovery continuity record

11.1 Canonical structure

RecoveryContinuityRecord {
  continuity_id
  prior_legitimate_state_ref
  new_legitimate_state_ref
  continuity_class
  justification_hash
  timestamp_unix_ms
}

11.2 continuity_class examples

• replay_continuity
• checkpoint_restore_continuity
• ratified_exceptional_continuity
• branch_specific_continuity
• discontinuity_split

11.3 Rule

Continuity records SHOULD align with constitutional canon and network identity canon.

12. Recovery legitimacy authority

12.1 Different recovery scopes may require different authorities:

• local operator authority for purely local restore
• cluster/operator authority for non-constitutional replay
• governance / constitutional authority for exceptional state legitimacy
• hard fork authority for branch-forming recovery

12.2 Rule

Authority class MUST be explicit and proportional to legitimacy impact.

13. Recovery ratification record

13.1 Canonical structure

RecoveryRatificationRecord {
  ratification_id
  recovery_class
  recovery_boundary_ref
  resulting_state_ref
  ratification_scope_hash
  authority_root
  decision_root
  evidence_root?
  timestamp_unix_ms
}

13.2 Rule

Exceptional or disputed recovery SHOULD require explicit ratification.

14. State reconstruction model

14.1 Some incidents require state reconstruction from:

• archived checkpoints
• finalized roots
• replayable transactions
• witness/proof records
• governance acts
• approved recovery manifests

14.2 Rule

State reconstruction MUST be deterministic enough to be audited and replayed by independent verifiers where feasible.

14.3 Rule

Reconstruction that relies on undocumented manual edits is illegitimate.

15. Recovery manifest

15.1 Canonical structure

RecoveryManifest {
  manifest_id
  recovery_class
  recovery_boundary_ref
  source_artifact_root
  reconstruction_method_root
  expected_resulting_state_root
  validation_plan_root
  archive_target_root?
}

15.2 Rule

Material recovery SHOULD produce explicit recovery manifest before final ratification.

16. Source artifact root

16.1 Recovery source artifacts MAY include:

• trusted checkpoint snapshots
• launch or upgrade archives
• decision ledger extracts
• governance acts
• witness bundles
• parameter snapshots
• conformance or replay references
• archive verification outputs

16.2 Rule

Source artifact root MUST preserve provenance of everything used to justify resulting state.

17. Validation plan for recovery

17.1 A recovery validation plan SHOULD include:

• replay checks
• state root checks
• consistency checks against known finalized roots
• parameter set consistency
• validator set legitimacy checks
• operator drill or dry-run if possible
• constitutional or governance review if required

17.2 Rule

Recovery without validation plan SHOULD be treated as weak and potentially illegitimate.

18. Recovery decision linkage

18.1 Recovery SHOULD integrate with decision ledger via decisions like:

• recovery_hold
• recovery_proceed
• recovery_authorized
• recovery_rejected
• branch_recovery_authorized
• constitutional_recovery_ratified
• recovered_state_accepted
• recovered_state_disputed

18.2 Rule

Critical recovery decisions MUST be explicit and archivable.

19. Disputed state model

19.1 A disputed state exists when:

• multiple candidate resulting states exist;
• different authorities or evidence sets support different continuations;
• or continuity classification is contested.

19.2 Canonical structure

DisputedStateRecord {
  dispute_state_id
  disputed_scope_hash
  candidate_state_root
  claimant_root
  evidence_root?
  timestamp_unix_ms
}

19.3 Rule

Disputed states SHOULD remain visible until resolved or branched constitutionally.

20. Recovery resolution model

20.1 Resolution outcomes SHOULD include:

• same-chain continuation ratified
• rollback boundary ratified
• branch-specific legitimacy ratified
• new chain identity issued
• dispute remains open
• recovery attempt abandoned

20.2 Rule

Resolution outcome MUST be explicit and SHOULD update constitutional canon where material.

21. Rollback versus illegitimate rewriting

21.1 Legitimate rollback MAY exist if:

• recovery policy and governance allow it;
• exact boundary is explicit;
• legitimacy is ratified by correct authority;
• resulting history is clearly represented as continuation or branch.

21.2 Illegitimate rewriting includes:

• silent replacement of state with no ratification;
• manual state edits outside canonical process;
• retroactive denial of previously recognized state with no continuity or fork record;
• pretending rollback never happened.

21.3 Rule

The difference between rollback and illegitimate rewriting is procedural and constitutional explicitness, not only technical effect.

22. Recovery and hard fork interaction

22.1 Some recoveries become hard fork events when:

• incompatible state truth must be adopted;
• replay protection is needed;
• same identity continuation would be misleading or unsafe;
• governance ratifies split rather than same-chain continuation.

22.2 Rule

When recovery crosses into fork territory, AZ-034 and AZ-043 records SHOULD be emitted as well.

23. Recovery and launch canon interaction

23.1 Post-launch severe incidents MAY require recovery that references:

• launch authorization
• launch archive
• early mainnet stabilization findings
• constitutional launch memory

23.2 Rule

Recovery SHOULD preserve linkage back to original launch truth wherever continuity is claimed.

24. Recovery and parameter canon interaction

24.1 Legitimate recovered state MUST bind to:

• active parameter set at boundary;
• any ratified parameter adjustments made as part of recovery;
• any parameter deactivations or emergency restrictions applied.

24.2 Rule

Recovered state legitimacy SHOULD fail if parameter truth is ambiguous.

25. Recovery and validator legitimacy interaction

25.1 Recovery MAY require explicit validator set legitimacy review:

• which validators are recognized at resulting state;
• which role bindings remain valid;
• whether compromised or laggard validators are excluded;
• whether rejoin thresholds apply.

25.2 Rule

Recovered state SHOULD not leave validator legitimacy implicit.

26. Recovery evidence export

26.1 External audit export SHOULD support:

• recovery manifest
• recovery boundary proof
• legitimacy record
• continuity or rupture record
• ratification evidence
• source artifact proof
• resulting state verification proof

26.2 Rule

Recovery legitimacy should be externally auditable for serious scopes.

27. Recovery archive bundle

27.1 A serious recovery SHOULD archive:

• incident records
• recovery decisions
• recovery manifest
• resulting legitimate state record
• continuity or fork records
• validation evidence
• post-recovery monitoring and stabilization data
• constitutional updates if any

27.2 Rule

Recovery memory SHOULD be durable and queryable.

28. Post-recovery stabilization

28.1 After recovery, system SHOULD re-enter a stabilization mode that asks:

• is resulting state behaving consistently?
• are validators and parameters legitimate and aligned?
• are incident causes actually contained?
• does continuity claim still hold under live observation?

28.2 Rule

Recovered legitimacy SHOULD be monitored, not merely declared.

29. Recovery review triggers

29.1 Recovery legitimacy SHOULD be reviewed when:

• severe incident recovery proposed
• rollback boundary proposed
• replay fails to match expected state
• alternative candidate states emerge
• constitutional authority changes continuity classification
• external audit challenges legitimacy basis

29.2 Rule

Recovery legitimacy is not one-and-done if new evidence appears.

30. Recovery review record

30.1 Canonical structure

RecoveryLegitimacyReviewRecord {
  review_id
  recovery_scope_hash
  candidate_state_root
  legitimacy_assessment_class
  evidence_root
  finding_root?
  timestamp_unix_ms
}

30.2 legitimacy_assessment_class

• sufficient_for_continuation
• sufficient_for_branch_specific_legitimacy
• insufficient
• disputed
• requires_constitutional_review

30.3 Rule

This review SHOULD feed ratification and constitutional canon updates.

31. Recovery anti-patterns

31.1 Systems SHOULD avoid:

1. “restore from backup” with no legitimacy record
2. replay or rollback with no boundary definition
3. same-chain continuation claimed after incompatible recovery with no ratification
4. manual state edit treated as harmless operational fix
5. disputed resulting states hidden to preserve appearance of certainty
6. recovery that ignores parameter or validator legitimacy
7. archive not updated with recovery truth
8. branch split treated as mere operational divergence
9. no audit export for recovery that changed constitutional history
10. post-recovery stabilization skipped because crisis pressure ended

32. Formal goals

AZ-045 urmărește aceste obiective:

32.1 Legitimate recovery clarity

The system can say exactly why a recovered state is legitimate, for whom and under what authority.

32.2 Explicit boundary between restore and rewrite

Recovery actions that change historical legitimacy are distinguished from ordinary operational restore.

32.3 Constitutional continuity discipline

When continuity holds or breaks, the canon records that explicitly.

32.4 Durable recovery memory

A future reviewer can reconstruct recovery truth without relying on oral history.

33. Formula documentului

Formal Recovery Boundary = explicit recovery boundary + resulting legitimate state record + continuity/rupture classification + ratification authority + auditable source artifacts + post-recovery stabilization

34. Relația cu restul suitei

• AZ-034 definește hard fork discipline.
• AZ-043 definește constitutional identity canon.
• AZ-044 definește parameter truth canon.
• AZ-045 definește cum o rețea grav afectată poate reveni legitim — sau cum se separă legitim într-o ramură distinctă.

Pe scurt: AZ-045 este puntea dintre incident sever și adevărul normativ revalidat al stării.

35. Ce urmează

După AZ-045, documentul corect este:

AZ-046 — Validator Set Legitimacy and Membership Canon

Acolo trebuie fixate:

• ce înseamnă validator legitim;
• cum este menținut și schimbat setul de validatori;
• cum se leagă membership-ul de keys, governance, slashing, recovery și continuity;
• și cum rămâne istoria membership-ului auditabilă și constituțional clară.

Închidere

O rețea nu este recuperată legitim doar pentru că pornește din nou. Este recuperată legitim când putem spune exact: de la ce boundary am repornit, ce stare recunoaștem, de ce o recunoaștem, cine a ratificat-o, și dacă acea recunoaștere păstrează continuitatea sau marchează o ruptură.

Acolo începe recovery-ul care nu repară doar infrastructura, ci repară și adevărul normativ al rețelei.