AZ-032 — Post-Launch Stabilization Review Protocol v1

Status

Acest document definește protocolul formal de review pentru stabilizarea post-launch în ATLAS ZERO.

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

• specificația protocolului și a subsistemelor lui;
• criteriile de readiness;
• pachetele release și genesis;
• ceremonia de launch și launch window;
• checklist-urile concrete ale operatorilor;
• ledger-ul formal al deciziilor de launch;
• profilele de monitorizare pentru early mainnet.

AZ-032 răspunde la întrebarea: cum evaluăm formal dacă rețeaua a trecut de la starea de launch controlat la starea de stabilizare suficientă, pe baza unor dovezi explicite și a unui review disciplinat, nu doar pentru că au trecut câteva epoci fără zgomot evident?

Scopul documentului este să fixeze:

• faza de stabilizare post-launch;
• artefactele și dovezile care trebuie colectate;
• review-urile obligatorii;
• criteriile pentru stabilizare suficientă sau insuficientă;
• legătura cu restricted posture, incidentele, ledger-ul decizional și eventualele remedieri sau restricții suplimentare.

Acest document se bazează pe:

• AZ-002 până la AZ-031, cu accent direct pe AZ-015, AZ-017, AZ-028, AZ-029, AZ-030 și AZ-031.

Termeni:

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

1. Obiectiv

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

1. Ce este post-launch stabilization review?
2. Când începe și când se poate încheia?
3. Ce dovezi trebuie analizate după launch?
4. Ce criterii definesc stabilizare suficientă?
5. Ce criterii definesc stabilizare insuficientă?
6. Cine face review-ul și în ce rol?
7. Ce se întâmplă dacă apar incidente sau anomalii persistente?
8. Cum decidem dacă ridicăm restricții, păstrăm restricted posture sau introducem noi controale?
9. Cum păstrăm acest review auditabil și reproductibil?
10. Cum legăm concluziile review-ului de roadmap-ul imediat post-launch?

2. Principii

2.1 Stabilization is evidence-based

Stabilizarea MUST fi declarată pe baza:

• finality health;
• integrității artefactelor active;
• sănătății operaționale;
• absenței anomaliilor critice nerezolvate;
• și a review-urilor explicite.

2.2 Time alone is not proof of stability

Faptul că au trecut câteva ore sau epoci nu este suficient. Trebuie analizate semnalele reale.

2.3 Restricted posture exit is a review outcome

Ieșirea din restricted posture SHOULD rezulta din acest protocol de review, nu din inerție sau oboseală operațională.

2.4 Open incidents dominate the conclusion

Incidentele critice sau sistemice deschise MUST cântări mai mult decât metricile frumoase pe perioade scurte.

2.5 Stabilization review is not a vanity report

Scopul nu este să declare succesul. Scopul este să spună adevărul operațional: suficient stabil, insuficient stabil, sau stabil doar sub restricții.

2.6 Review must produce actionable outputs

Protocolul SHOULD produce:

• verdict;
• restricții menținute sau ridicate;
• remedieri;
• backlog imediat;
• eventuale update-uri pentru corpus, runbooks și monitoring.

3. Stabilization phase definition

3.1 Definition

Post-launch stabilization phase = intervalul de după bootstrap și early epochs în care:

• rețeaua este live;
• monitorizarea rămâne mai strictă decât steady state;
• schimbările sunt controlate;
• și se colectează dovezi pentru verdictul de stabilizare.

3.2 Boundaries

Stabilization phase SHOULD începe după:

• primele finalizări sănătoase;
• intrarea în restricted posture; și SHOULD se încheie numai după:
• stabilization review explicit;
• eventualul exit din restricted posture;
• sau decizia de a păstra restricții / a deschide remediere mai puternică.

3.3 Rule

The stabilization phase MUST have identifiable start and review checkpoints.

4. Stabilization states

4.1 Recommended states

• STAB_COLLECTING
• STAB_REVIEW_READY
• STAB_SUFFICIENT
• STAB_SUFFICIENT_WITH_RESTRICTIONS
• STAB_INSUFFICIENT
• STAB_INCIDENT_DOMINATED
• STAB_DEFERRED_REVIEW

4.2 Meaning

STAB_SUFFICIENT

Rețeaua este suficient de stabilă pentru a ieși din restricted posture conform politicii.

STAB_SUFFICIENT_WITH_RESTRICTIONS

Stabilitate acceptabilă, dar unele restricții rămân temporar.

STAB_INSUFFICIENT

Stabilizarea nu este suficientă; restricted posture sau alte controale trebuie păstrate ori întărite.

STAB_INCIDENT_DOMINATED

Incidentele active domină verdictul; review-ul nu poate declara stabilizare.

5. Review actors

5.1 Recommended actor roles

• ROLE_LAUNCH_COORDINATOR
• ROLE_OPS_LEAD
• ROLE_CONSENSUS_LEAD
• ROLE_SECURITY_LEAD
• ROLE_INCIDENT_COMMANDER
• ROLE_AUDIT_SCRIBE
• ROLE_MONITORING_LEAD
• ROLE_RELEASE_MANAGER
• ROLE_GOVERNANCE_LIAISON
• ROLE_VALIDATOR_OPERATOR_REPRESENTATIVE

5.2 Rule

Stabilization review SHOULD be multi-perspective. Nu trebuie făcut doar de monitoring sau doar de release.

6. Stabilization review inputs

6.1 Mandatory inputs SHOULD include

• LaunchWindowRecord
• LaunchCheckpointRecords
• LaunchDecisionLedger active decisions and history for launch scope
• MonitoringSnapshotRecords
• MonitoringAnomalyRecords
• incident records and statuses
• first epoch / restricted posture observations
• operator checklist results
• restart/rejoin decision history
• relevant artifact revocation/supersession records
• known issue register for launch scope
• residual risk register

6.2 Optional but recommended inputs

• public testnet lessons map for matched anomaly classes
• post-launch bug intake summaries
• conformance gap notes discovered post-launch
• governance or emergency action records if any

6.3 Rule

A review without structured inputs becomes anecdotal and weak.

7. Stabilization evidence families

7.1 The review SHOULD evaluate evidence from at least these families:

1. consensus/finality evidence
2. artifact integrity evidence
3. operator health evidence
4. monitoring health evidence
5. incident evidence
6. BVM health evidence if active
7. witness/proof health evidence if active
8. governance/activation evidence
9. decision ledger and checklist evidence
10. post-launch bug intake evidence

7.2 Rule

No single family SHOULD dominate by default unless a critical incident justifies it.

8. Consensus/finality review block

8.1 Review questions

• Was finality cadence acceptable across the review window?
• Were there unexplained no-finality intervals?
• Were role participation levels within launch expectations?
• Did any contradictory notarization or major consensus anomaly occur?
• Were any replay mismatches observed?

8.2 Verdict guidance

• sustained healthy finality + no unexplained divergence => positive signal
• repeated degraded finality or unexplained no-finality => negative signal
• contradictory notarization or deterministic split sign => severe negative signal

8.3 Rule

Consensus/finality evidence SHOULD heavily influence the final stabilization verdict.

9. Artifact integrity review block

9.1 Review questions

• Did any node or operator report binary/release/genesis mismatch?
• Did any critical artifact become revoked, superseded or quarantined after launch?
• Did any scope confusion appear between release and genesis package?
• Did any launch-critical artifact require emergency replacement?

9.2 Rule

Post-launch artifact truth instability SHOULD strongly bias toward insufficient stabilization.

10. Operator health review block

10.1 Review questions

• Were restart/rejoin counts within expected launch norms?
• Did operators remain able to validate and sign safely?
• Were local safe mode events isolated or widespread?
• Were any signer failures or key-path anomalies significant?
• Did any operator cluster show repeated instability?

10.2 Rule

Repeated operator cluster instability SHOULD delay normalization or justify targeted restrictions.

11. Monitoring health review block

11.1 Review questions

• Did monitoring remain trustworthy and timely?
• Were there telemetry blind spots during critical moments?
• Did alerting routes work?
• Were thresholds too noisy or too weak?
• Did monitoring evidence support or hinder decision-making?

11.2 Rule

If monitoring was blind during key parts of early mainnet, stabilization confidence SHOULD be reduced materially.

12. Incident review block

12.1 Review questions

• Which incidents opened during launch or stabilization?
• Which are closed, mitigated, or still active?
• Did any incident require emergency action or special restriction?
• Were any incidents merely local, or did they reflect systemic risk?

12.2 Rule

Any open critical or systemic incident SHOULD strongly bias toward STAB_INSUFFICIENT or STAB_INCIDENT_DOMINATED.

13. BVM review block

13.1 If BVM active in launch scope, review SHOULD ask:

• Were machine calls deterministic across operators?
• Were trap/revert/error patterns within expectations?
• Did any effect digest anomalies appear?
• Were any modules or families quarantined?
• Did any boundedness concern appear?

13.2 Rule

Consensus-relevant BVM anomaly after launch SHOULD weigh heavily against declaring sufficient stabilization.

14. Witness / proof review block

14.1 If witness/proof active in launch scope, review SHOULD ask:

• Were critical witness families healthy?
• Were proof verification failure patterns acceptable?
• Did any unauthorized emission or contradiction anomaly appear?
• Did any witness-driven operational control path misbehave?

14.2 Rule

Witness/proof anomalies in halt, treasury, governance or safety-critical domains SHOULD be treated conservatively.

15. Governance / activation review block

15.1 Review questions

• Did any unexpected governance activation occur?
• Did any challenge/timelock mismatch signal arise?
• Were any emergency actions triggered?
• Is governance state stable and understood?

15.2 Rule

Unexpected governance behavior post-launch SHOULD block full normalization until understood.

16. Bug intake review block

16.1 Review questions

• Which post-launch bug reports are confirmed?
• Are any high/critical bugs newly discovered?
• Do any reports indicate launch-critical hidden classes of failure?
• Were new regression/conformance cases created?

16.2 Rule

Fresh confirmed high/critical bugs in launch subset SHOULD feed directly into stabilization verdict and post-launch action plan.

17. Stabilization review object model

17.1 Canonical structure

StabilizationReviewRecord {
  version_major
  version_minor

  review_id
  target_network_class
  target_chain_id
  target_genesis_hash
  linked_launch_window_id
  review_window_hash
  evidence_root
  review_status
  overall_verdict
  notes_hash?
}

17.2 review_status

• OPEN
• IN_REVIEW
• COMPLETED
• SUPERSEDED

17.3 overall_verdict

• STAB_SUFFICIENT
• STAB_SUFFICIENT_WITH_RESTRICTIONS
• STAB_INSUFFICIENT
• STAB_INCIDENT_DOMINATED
• STAB_DEFERRED_REVIEW

17.4 Rule

One stabilization review record SHOULD correspond to one explicit review window and launch scope.

18. Review evidence root

18.1 Evidence entry structure

StabilizationEvidenceEntry {
  evidence_class
  evidence_ref
}

18.2 evidence_class examples

• monitoring_snapshot
• anomaly_record
• incident_record
• checklist_record
• decision_record
• artifact_record
• bug_report
• bug_closure
• conformance_update
• review_note_bundle

18.3 evidence_root

evidence_root = MerkleRoot(H("AZ:STAB_EVIDENCE:" || canonical_entry_i)...)

18.4 Rule

Critical verdicts SHOULD be evidence-backed through explicit evidence_root.

19. Review findings model

19.1 Recommended structure

StabilizationFinding {
  finding_id
  review_id
  finding_class
  severity
  summary_hash
  evidence_refs?
  remediation_required
  restriction_implication
}

19.2 finding_class examples

• consensus_healthy
• consensus_degraded
• artifact_scope_issue
• operator_cluster_instability
• monitoring_gap
• incident_open
• bug_backlog_concern
• bvm_family_restriction_needed
• governance_uncertainty
• telemetry_blind_spot

19.3 restriction_implication

• none
• keep_restricted_posture
• narrow_scope
• quarantine_scope
• open_incident
• emergency_review

20. Review recommendation model

20.1 Recommended outputs

The review SHOULD produce explicit recommendations such as:

• exit restricted posture
• keep restricted posture unchanged
• keep restricted posture but lift specific restriction
• keep restricted posture and tighten specific restriction
• quarantine scope X
• require conformance/regression update
• require post-launch patch planning
• defer normalization review by N epochs/time
• open governance/security/ops follow-up review

20.2 Rule

Recommendations SHOULD be explicit and traceable, not implied.

21. Stabilization sufficiency criteria

21.1 A review MAY declare STAB_SUFFICIENT only if:

• finality has been healthy across review window
• no unresolved critical incident remains
• no unresolved artifact truth instability remains
• monitoring health is sufficient
• operator cluster health is acceptable
• no launch-critical bug remains unbounded in scope
• restricted posture exit conditions are met

21.2 Rule

All of these SHOULD be explicitly checked, not assumed.

22. Stabilization sufficiency with restrictions

22.1 STAB_SUFFICIENT_WITH_RESTRICTIONS is appropriate when:

• core launch subset is stable enough,
• but some bounded restrictions should remain, for example:
• keep one optional feature disabled
• keep one machine family quarantined
• maintain tighter restart approvals
• maintain elevated monitoring for one domain

22.2 Rule

Remaining restrictions MUST be explicit and justified.

23. Stabilization insufficiency criteria

23.1 STAB_INSUFFICIENT is appropriate when:

• finality remains degraded or inconsistent
• repeated role participation instability persists
• artifact scope confusion remains unresolved
• monitoring is not trustworthy enough
• important launch-critical bugs remain unbounded
• restricted posture exit criteria are not met

23.2 Rule

This verdict SHOULD not be softened for optics.

24. Incident-dominated criteria

24.1 STAB_INCIDENT_DOMINATED is appropriate when:

• active critical incident remains open
• systemic security or protocol anomaly is unresolved
• emergency action or emergency review dominates current operating truth
• continuing stabilization review would falsely imply normality

24.2 Rule

In this state, the incident flow SHOULD dominate over normalization flow.

25. Deferred review

25.1 STAB_DEFERRED_REVIEW is appropriate when:

• not enough evidence window has elapsed
• important data missing
• review quorum incomplete
• a short wait is justified without major new risk

25.2 Rule

Deferred review SHOULD specify:

• why it was deferred
• what evidence is still needed
• when reevaluation occurs

26. Review checkpoints

26.1 Recommended checkpoints

• first restricted posture midpoint review
• first restricted posture end-of-window review
• post-major anomaly review
• pre-normalization review

26.2 Rule

If early mainnet is longer or more turbulent than expected, additional checkpoints SHOULD be allowed.

27. Restricted posture decision linkage

27.1 The review SHOULD feed one of:

• DEC_RESTRICTED_POSTURE_EXIT
• maintain existing restricted posture decision
• new DEC_SCOPE_QUARANTINE
• new DEC_SCOPE_REENABLE
• new defer/hold style operational decision in ledger

27.2 Rule

Stabilization review without decision linkage is incomplete for operational closure.

28. Review quorum

28.1 Recommendation

A serious stabilization review SHOULD include at least:

• ops lead
• consensus lead
• monitoring lead
• audit scribe
• security or incident representative if anomalies occurred

28.2 Rule

If launch policy requires broader sign-off, that MUST be explicit.

29. Review timeline discipline

29.1 The review SHOULD record:

• review open time
• evidence cutoff window
• review participants
• findings issuance times
• final verdict time
• linked decision time if any

29.2 Rule

Without review timeline, later audits cannot reconstruct the reasoning boundary properly.

30. Review ledger linkage

30.1 The stabilization review SHOULD be linkable from:

• Launch Decision Ledger
• launch audit package
• post-launch stabilization archive
• operator advisory updates

30.2 Rule

The final review verdict SHOULD influence active operational truth, not remain a detached summary.

31. Review package / archive

31.1 Recommended archive contents

• StabilizationReviewRecord
• findings
• evidence root mapping
• linked incident summaries
• monitoring summary bundle
• operator summary bundle
• decision ledger subset
• recommendations and action plan
• restricted posture decision outputs

31.2 Rule

The archive SHOULD be immutable once finalized, with supersession only via new review.

32. Supersession of reviews

32.1 Need

A later review may supersede an earlier one.

32.2 Rule

A superseding review MUST:

• reference prior review_id
• justify why new evidence changes or finalizes the earlier verdict
• preserve prior review visibility

32.3 Rule

Past reviews MUST NOT be silently rewritten.

33. Action plan output

33.1 Each review SHOULD produce action items grouped as:

• immediate operational changes
• restricted posture changes
• monitoring threshold changes
• corpus/conformance additions
• code or release remediation
• documentation updates
• governance/security follow-up

33.2 Rule

Without action items, review risks becoming descriptive only.

34. Conformance and regression linkage

34.1 If the review discovers:

• previously unknown anomaly class
• weak monitoring threshold
• replay ambiguity
• bug confirmed post-launch

Then it SHOULD trigger:

• new conformance case
• regression case
• corpus update
• or explicit note why not.

34.2 Rule

Stabilization review SHOULD improve future readiness, not only judge past launch.

35. Communication outputs

35.1 Internal outputs SHOULD include

• verdict
• active restrictions
• notable anomalies
• required follow-ups
• exit/continue restricted posture decision

35.2 Public-facing outputs MAY include

• high-level network health summary
• restricted posture status
• known issue status
• operator advisories
• confidence statement bounded by actual evidence

35.3 Rule

Public communication MUST NOT overstate stability beyond review evidence.

36. Anti-patterns

Systems SHOULD avoid:

1. declaring stabilization complete because no one complained loudly
2. ending restricted posture without explicit review artifact
3. ignoring unresolved high-severity bugs because consensus still finalizes
4. treating incident silence as proof of absence
5. not reviewing monitoring blindness as its own problem
6. allowing review to be purely verbal
7. rewriting review conclusions after the fact instead of superseding them
8. using only average metrics and ignoring burst anomalies
9. separating review from decision ledger and operator action
10. failing to produce concrete remediation backlog

37. Formal goals

AZ-032 urmărește aceste obiective:

37.1 Honest stabilization assessment

The system can say whether launch stabilized sufficiently, insufficiently or only under restrictions.

37.2 Evidence-backed normalization

Exit from restricted posture rests on explicit evidence and review, not inertia.

37.3 Audit-grade post-launch memory

The first post-launch period remains reconstructible and analyzable later.

37.4 Feedback into future safety

The review improves conformance, monitoring, runbooks and future launches.

38. Formula documentului

Post-Launch Stabilization Review = bounded review window + structured evidence + explicit findings + stabilization verdict + linked operational decisions + remediation plan

39. Relația cu restul suitei

• AZ-028 definește launch window și restricted posture entry.
• AZ-030 definește ledger-ul deciziilor.
• AZ-031 definește profilele de monitorizare.
• AZ-032 definește review-ul formal care decide dacă acea fază a produs stabilizare suficientă.

Pe scurt: AZ-031 produce semnalele; AZ-032 le transformă în verdict operațional și decizii de stabilizare.

40. Ce urmează

După AZ-032, documentul corect este:

AZ-033 — Mainnet Artifact Archive and Audit Package

Acolo trebuie fixate:

• ce artefacte de launch, stabilizare și early-mainnet se arhivează;
• cum se împachetează pentru audit;
• ce manifesturi și atestări sunt necesare;
• și cum se păstrează istoria completă a lansării și a primei stabilizări fără degradare sau ambiguitate.

Închidere

Lansarea nu este completă când rețeaua pornește. Este completă abia când putem spune, pe bază de dovezi, că primele ei etape au fost suficient de sănătoase, că anomaliile au fost înțelese sau încadrate, și că ieșirea din regimul strict nu este un salt de credință.

Acolo începe stabilizarea post-launch reală.