AZ-030 — Launch Decision Ledger v1

Status

Acest document definește registrul formal al deciziilor de launch pentru ATLAS ZERO.

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

specificația protocolului și a subsistemelor lui;
criteriile de readiness;
pachetele genesis și release;
manualul operatorilor;
ceremoniile de genesis și launch;
procedura de launch window;
checklist-urile concrete pentru operatori.

AZ-030 răspunde la întrebarea: cum păstrăm registrul oficial, auditabil și neechivoc al tuturor deciziilor critice din perioada de launch, astfel încât să putem demonstra ulterior cine a decis ce, când, în ce scope și pe baza cărei evidențe?

Scopul documentului este să fixeze:

modelul ledger-ului de decizii;
tipurile de decizii admise;
legătura cu artefactele, checklist-urile, blocker-ele și ceremoniile;
semnatarii și regulile de autoritate;
relația dintre decizie, justificare și evidență;
regulile pentru supersession, revocation și audit.

Acest document se bazează pe:

AZ-002 până la AZ-029, cu accent direct pe AZ-017, AZ-025, AZ-026, AZ-028 și AZ-029.

Termeni:

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

1. Obiectiv

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

Ce este Launch Decision Ledger?
Ce tipuri de decizii intră în ledger?
Cum este legată o decizie de scope-ul exact de launch?
Cum este legată o decizie de evidență, checklist-uri și artefacte?
Cine poate emite sau semna o decizie?
Cum se modelează HOLD, PROCEED, GO, DEFER și ABORT?
Cum se tratează decizii conflictuale, supersedate sau revocate?
Cum se păstrează lanțul temporal și autoritatea decizională?
Cum este folosit ledger-ul în audit, postmortem și readiness review?
Cum evităm decizii informale, neverificate sau imposibil de reconstruit?

2. Principii

2.1 Launch decisions are protocol-adjacent governance artifacts

Deciziile de launch nu sunt consens on-chain în sens strict, dar pentru operațiunile de lansare sunt suficient de importante încât MUST fi tratate ca artefacte de mare integritate.

2.2 Decision without scope is not a decision

Orice decizie MUST fi legată explicit de:

exact release package;
exact genesis package;
exact chain_id;
exact genesis_hash;
exact launch window sau ceremony scope.

2.3 Decision without evidence is weak

Orice decizie critică SHOULD ancora:

checklist refs;
blocker refs;
confirmation refs;
artifact refs;
incident refs dacă există.

2.4 Ledger is append-first, overwrite-never

Registrul SHOULD funcționa prin:

append,
supersession explicit,
revocation explicit, nu prin rescriere tăcută a deciziilor vechi.

2.5 Human governance needs machine-readable audit

Chiar dacă oamenii discută, hotărârea finală SHOULD exista ca obiect canonical, nu doar ca mesaj într-un chat.

2.6 Negative decisions matter too

HOLD, DEFER, NO_GO și ABORT sunt la fel de importante auditabil ca GO.

3. Ledger purpose

3.1 Launch Decision Ledger (LDL)

LDL este registrul canonical al deciziilor operaționale de lansare și pre-lansare.

3.2 It SHOULD answer:

care a fost ultima decizie activă pentru acest scope?
cine a semnat-o?
pe ce bază?
ce decizie a supersedat-o?
ce blockers erau deschiși?
când a fost luată?

3.3 Rule

LDL SHOULD be treated as launch-critical operational truth layer.

4. Decision classes

4.1 Standard decision classes

ATLAS ZERO SHOULD suporta cel puțin:

DEC_ARTIFACT_ACCEPTANCE
DEC_ARTIFACT_REJECTION
DEC_FREEZE_CONFIRMED
DEC_HOLD
DEC_PROCEED
DEC_GO
DEC_NO_GO
DEC_DEFER
DEC_ABORT
DEC_RESTRICTED_POSTURE_ENTER
DEC_RESTRICTED_POSTURE_EXIT
DEC_RESTART_APPROVED
DEC_REJOIN_APPROVED
DEC_SCOPE_QUARANTINE
DEC_SCOPE_REENABLE

4.2 Meaning

DEC_GO

Autorizează trecerea către bootstrap scope autorizat.

DEC_NO_GO

Declară explicit că launch-ul nu poate continua.

DEC_DEFER

Declară că launch-ul este amânat, cu posibilă reluare ulterioară.

DEC_ABORT

Oprește tentativa curentă și o invalidează ca path de continuare.

DEC_HOLD

Pauză scurtă, controlată, pentru clarificare.

DEC_PROCEED

Continuare explicită după hold sau checkpoint review.

4.3 Rule

Decision class MUST be explicit and machine-readable.

5. Decision scope

5.1 Need

O decizie trebuie să aibă scope precis.

5.2 Canonical structure

LaunchDecisionScope {
  scope_class
  release_package_id
  genesis_package_id
  chain_id
  genesis_hash
  launch_window_id?
  ceremony_id?
  node_group_scope_hash?
}

5.3 scope_class examples

artifact_scope
ceremony_scope
launch_window_scope
bootstrap_scope
restricted_posture_scope
operator_cluster_scope
restart_scope

5.4 Rule

Scope incomplet pentru decizie critică SHOULD invalidate or downgrade the decision.

6. Launch decision object

6.1 Canonical structure

LaunchDecisionRecord {
  version_major
  version_minor

  decision_id
  decision_class
  decision_scope
  decision_status
  issued_at_unix_ms
  issuer_role_class
  issuer_policy_ref
  justification_hash
  evidence_root?
  blocker_root?
  supersedes_decision_id?
  expires_at_unix_ms?
  metadata_hash?
  signature_envelopes
}

6.2 decision_id

decision_id = H("AZ:LAUNCH_DECISION:" || canonical_decision_body)

6.3 decision_status

ACTIVE
SUPERSEDED
REVOKED
EXPIRED
ARCHIVED

6.4 Rule

Semnăturile MUST acoperi exact forma canonicală a deciziei.

7. Issuer role classes

7.1 Recommended issuer roles

ROLE_LAUNCH_COORDINATOR
ROLE_GO_NO_GO_SIGNER
ROLE_RELEASE_MANAGER
ROLE_GENESIS_CUSTODIAN
ROLE_CONSENSUS_LEAD
ROLE_OPS_LEAD
ROLE_SECURITY_LEAD
ROLE_INCIDENT_COMMANDER
ROLE_RECOVERY_OPERATOR

7.2 Rule

Nu toate rolurile pot emite toate tipurile de decizie. Matricea de autoritate MUST fi explicită.

7.3 Recommendation

For DEC_GO, DEC_ABORT, DEC_DEFER, DEC_RESTRICTED_POSTURE_EXIT, multi-role approval SHOULD be preferred.

8. Decision authority matrix

8.1 The policy SHOULD define, per decision class:

who may issue
whether one signer is enough
whether multiple distinct roles are required
whether evidence root is mandatory
whether blocker root is mandatory
whether expiration is required

8.2 Example guidance

DEC_HOLD

May be issued by:

launch coordinator
consensus lead
ops lead
incident commander Single signer MAY be enough if policy says so.

DEC_GO

SHOULD require:

go/no-go signer set
launch coordinator
possibly ops/security/consensus roles depending on policy

DEC_ABORT

SHOULD require at least one authority capable of stopping launch quickly, with subsequent review if unilateral.

8.3 Rule

Decision authority MUST be explicit before launch, not invented during crisis.

9. Justification hash

9.1 Purpose

Links a decision to the semantic reason without making free-form text the only truth.

9.2 Recommended derivation

justification_hash = H("AZ:LAUNCH_DECISION_JUSTIFICATION:" || canonical_justification_payload)

9.3 Examples of justification payload

all freeze checks passed
blocker list empty
role readiness threshold satisfied
critical mismatch discovered
latest advisory introduced blocker
early epoch stability threshold met

9.4 Rule

A decision SHOULD have justification payload precise enough for later audit.

10. Evidence root

10.1 Need

Decisions should bind to supporting evidence.

10.2 Evidence MAY include refs to:

checklist records
ceremony confirmations
checkpoint records
artifact ids
package manifests
live status records
incident records
reproduction or anomaly records

10.3 Canonical structure

DecisionEvidenceEntry {
  evidence_class
  evidence_ref
}

10.4 evidence_root

Derived from ordered evidence entries:

evidence_root = MerkleRoot(H("AZ:DECISION_EVIDENCE:" || entry_i)...)

10.5 Rule

For critical decisions, evidence_root SHOULD be mandatory.

11. Blocker root

11.1 Need

Negative or conditional decisions often depend on open blockers.

11.2 Structure

DecisionBlockerEntry {
  blocker_id
  blocker_class
  severity
  blocker_status
}

11.3 blocker_root

blocker_root = MerkleRoot(H("AZ:DECISION_BLOCKER:" || entry_i)...)

11.4 Rule

DEC_HOLD, DEC_DEFER, DEC_NO_GO, DEC_ABORT SHOULD generally include blocker_root or equivalent evidence of why.

12. Expiration model

12.1 Need

Some decisions are temporary.

12.2 Decision classes that MAY expire

hold
proceed
restart approval
rejoin approval
temporary quarantine
temporary restricted posture permission

12.3 Rule

If decision is temporary, expires_at_unix_ms SHOULD be present.

12.4 Rule

Expired decision MUST NOT remain active authority for future action.

13. Supersession model

13.1 Need

Launch decisions evolve over time.

13.2 Rule

A new decision MAY supersede an older one through supersedes_decision_id.

13.3 Examples

DEC_PROCEED supersedes an earlier DEC_HOLD
DEC_ABORT supersedes pending DEC_PROCEED
DEC_RESTRICTED_POSTURE_EXIT supersedes earlier enter-state as active control decision
new defer decision supersedes old hold decision

13.4 Rule

Supersession graph MUST be acyclic and scope-consistent.

14. Revocation model

14.1 Need

A decision may need to be revoked if issued in error or on compromised basis.

14.2 Rule

Revocation MUST be explicit through separate revocation record or allowed decision class semantics, not by deleting prior decision.

14.3 Effects

Revocation MAY:

render decision inactive
restore prior decision if policy says so
force new decision issuance before action continues

14.4 Rule

Critical revoked decisions SHOULD remain fully visible in audit history.

15. Active decision derivation

15.1 For a given scope and decision family, active decision is one that:

exists
has valid signatures
matches scope
is not revoked
is not superseded
is not expired

15.2 Rule

Operators and coordinators SHOULD use active decision state, not merely latest message timestamp.

16. Conflict model

16.1 Conflicts examples

active GO and active ABORT for same exact launch scope
active HOLD and active PROCEED without supersession relation
two GO decisions for same scope with different evidence roots and no supersession
decision signed by unauthorized role

16.2 Rule

Decision conflicts in launch-critical scope SHOULD fail closed. The scope must not proceed until resolved.

17. Ledger chain model

17.1 Need

Decisions form a history, not isolated objects.

17.2 LaunchDecisionLedgerEntry

LaunchDecisionLedgerEntry {
  ledger_entry_id
  prev_ledger_hash?
  decision_id
  decision_scope_hash
  entry_timestamp_unix_ms
}

17.3 Ledger tip hash

ledger_hash_i = H("AZ:LAUNCH_LEDGER_ENTRY:" || entry_i || ledger_hash_{i-1})

17.4 Rule

The ledger SHOULD be append-only and hash-chained.

18. Ledger segmentation

18.1 Recommended scopes

The system MAY maintain:

global launch ledger
per-network ledger
per-launch-window ledger
per-cluster/operator subgroup ledger as long as linkage is explicit

18.2 Recommendation

V1 SHOULD at least have one authoritative ledger for launch-critical decisions of a given network scope.

19. Decision families by launch phase

19.1 Prelaunch

artifact acceptance
artifact rejection
freeze confirmed
scope quarantine
restart/rejoin pre-approval

19.2 Ceremony

hold
proceed
go
no-go
defer
abort

19.3 Early live phase

restricted posture enter
restart approved
rejoin approved
scope quarantine
scope re-enable
restricted posture exit

19.4 Rule

Decision classes SHOULD be phase-aware and not overused outside their natural phase.

20. DEC_HOLD semantics

20.1 Use

Short pause for clarification or bounded issue resolution.

20.2 MUST include

exact scope
hold reason / blocker root
issuer role
time
optional expiration

20.3 Rule

Hold does not authorize launch, and does not kill launch. It freezes progress until follow-up decision.

21. DEC_PROCEED semantics

21.1 Use

Explicit continuation after prior hold or checkpoint review.

21.2 SHOULD include

supersedes_decision_id of prior hold
evidence root showing blocker resolved or acceptable
exact same or narrower scope

21.3 Rule

Proceed without clear relation to the prior hold is weak and SHOULD be avoided.

22. DEC_GO semantics

22.1 Use

Formal authorization that launch may continue to bootstrap.

22.2 MUST include

exact launch scope
evidence root sufficient for go criteria
issuer authority satisfying launch policy
blocker root empty or only explicitly accepted residual blockers under policy
issuance timestamp

22.3 Rule

GO SHOULD be single-source-of-truth for launch authorization basis, even if separate LaunchAuthorizationRecord exists downstream.

23. DEC_NO_GO semantics

23.1 Use

Formal statement that launch must not proceed now.

23.2 SHOULD include

blocker root
evidence root
whether scope remains retryable after mitigation
exact issuance authority

23.3 Rule

NO_GO is stronger than HOLD and SHOULD close the current decision path unless superseded later by a new scoped decision.

24. DEC_DEFER semantics

24.1 Use

Launch is postponed, typically with stable scope but inadequate timing/readiness.

24.2 SHOULD include

reason root
blockers or unresolved readiness items
whether same artifact scope remains candidate for future launch
recommended reevaluation boundary if known

24.3 Rule

Defer is not equivalent to abort. It preserves possibility of later retry with explicit new decision flow.

25. DEC_ABORT semantics

25.1 Use

Terminate the current launch attempt or specific scope immediately.

25.2 SHOULD include

critical reason
evidence root
superseded decision refs if applicable
whether artifact scope is now invalid or only current window invalid

25.3 Rule

Abort SHOULD be explicit and high-integrity. For launch-critical scope, ambiguous abort is dangerous.

26. DEC_RESTRICTED_POSTURE_ENTER / EXIT

26.1 Enter

Marks early-mainnet strict mode as active.

26.2 Exit

Marks explicit transition to more normal operation.

26.3 Rule

Both decisions SHOULD bind to:

launch window scope
observation evidence
operator health / anomaly status

26.4 Rule

Exit SHOULD require stronger evidence than enter.

27. DEC_RESTART_APPROVED / DEC_REJOIN_APPROVED

27.1 Use

Operator-level or cluster-level permission to resume participation after local issue.

27.2 SHOULD include

node/group scope
evidence of replay/preflight/health
expiration if approval is temporary
exact role set allowed after restart or rejoin

27.3 Rule

These decisions SHOULD NOT be confused with launch-wide GO.

28. DEC_SCOPE_QUARANTINE / REENABLE

28.1 Use

Temporary control over problematic scope:

operator cluster
artifact subset
service domain
role class
feature scope

28.2 SHOULD include

scope narrowed as much as possible
reason and evidence
whether local-only or network-wide policy context applies

28.3 Rule

Quarantine and re-enable decisions MUST be clearly paired if both occur.

29. Checklist linkage

29.1 Need

Checklist completion should feed decisions.

29.2 Rule

A critical decision SHOULD reference relevant checklist records, such as:

prelaunch artifacts checklist
preflight checklist
launch final checks checklist
first epochs checklist
incident response checklist
restart/rejoin checklist

29.3 Benefit

This makes decisions traceable to actual operator execution steps.

30. Ceremony linkage

30.1 Decisions SHOULD reference:

GenesisCeremonyRecord or confirmations
LaunchCeremonyRecord or confirmations
LaunchWindowRecord
checkpoint records
hold records
proceed records

30.2 Rule

Ceremony and ledger MUST reinforce each other, not diverge.

31. Artifact linkage

31.1 Decision evidence SHOULD include direct refs to:

release package id
release manifest id
genesis package id
genesis package manifest id
chain_id
genesis_hash
relevant artifact hashes

31.2 Rule

Launch-critical decision without direct artifact linkage SHOULD be considered weak.

32. Decision review and sign-off

32.1 Recommended sign-off classes

single-signer
dual-role approval
threshold approval
committee approval

32.2 Rule

Decision class and scope SHOULD determine required sign-off class.

32.3 Strong recommendation

GO and ABORT for mainnet-class scope SHOULD require more than one critical role or an explicit policy exception.

33. Decision publication and visibility

33.1 Internal visibility

All critical decisions SHOULD be visible to launch-critical operators.

33.2 Public visibility

Public publication MAY vary by policy and disclosure mode, but major outcomes like GO, DEFER or ABORT for public launch SHOULD eventually be communicable clearly.

33.3 Rule

Decision visibility policy MUST NOT hide necessary operational truth from the people who depend on it.

34. Launch Decision Ledger root manifest

34.1 Recommended structure

LaunchDecisionLedgerRoot {
  ledger_id
  target_network_class
  target_chain_id
  scope_root
  entry_count
  ledger_tip_hash
  active_decision_root
  archived_decision_root?
}

34.2 active_decision_root

Represents active decisions by scope and class.

34.3 Rule

Ledger root SHOULD be recomputable from decision entries and entry chain.

35. Decision evidence minimality

35.1 Principle

Evidence root should be sufficient, not bloated.

35.2 Rule

A decision SHOULD include enough evidence refs to justify itself, but not attempt to inline entire logs or packages if stable refs already exist.

35.3 Recommendation

Use refs to canonical artifacts and records whenever possible.

36. Audit queries the ledger SHOULD answer

36.1 Examples

What was the active GO decision for launch window X?
Which blockers caused DEFER on date Y?
Which HOLD was superseded by PROCEED?
Which operator cluster received REJOIN approval?
Was restricted posture exit explicitly approved?
Which evidence and checklist records supported GO?

36.2 Rule

If the ledger cannot answer these questions, its structure is insufficient.

37. Postmortem and review usage

37.1 Launch decision ledger SHOULD be used in:

post-launch stabilization review
aborted launch review
incident postmortems
readiness retrospectives
governance review of launch discipline

37.2 Rule

It should not be treated merely as archival ornament.

38. Retention and archival

38.1 Critical decision records MUST be retained through:

launch window
early-mainnet restricted posture
post-launch review period
long-term audit horizon appropriate to network importance

38.2 Rule

Deleting or truncating launch decision history SHOULD be prohibited for serious scopes.

39. Anti-patterns

Systems SHOULD avoid:

GO decision as informal chat message only
hold with no blocker root or expiry
proceed with no link to prior hold
abort with no scope clarity
conflicting active decisions with no fail-closed behavior
decisions by unauthorized roles
decisions that refer only to filenames and not artifact ids/hashes
restarts/rejoins approved with no evidence of local health
no append-only ledger chain
no linkage between decision and ceremony/checklist evidence

40. Formal goals

AZ-030 urmărește aceste obiective:

40.1 Decision traceability

Every launch-critical decision can be traced to issuer, time, scope and evidence.

40.2 Conflict resistance

The system can detect and fail closed on conflicting active decisions.

40.3 Authority clarity

It is explicit who was authorized to issue each class of decision.

40.4 Audit durability

The history of launch decisions remains reconstructible and useful for later review.

41. Formula documentului

Launch Decision Ledger = append-only decision chain + scope-bound decision records + evidence roots + explicit supersession/revocation + active decision derivation

42. Relația cu restul suitei

AZ-026 definește ceremonia și verdicturile de launch.
AZ-028 definește procedura din launch window.
AZ-029 definește checklist-urile concrete.
AZ-030 definește registrul formal care leagă aceste verificări și verdicturi într-un istoric auditat.

Pe scurt: AZ-026 și AZ-028 spun ce decizii trebuie luate; AZ-030 spune cum rămân ele adevăr operațional verificabil după ce au fost luate.

43. Ce urmează

După AZ-030, documentul corect este:

AZ-031 — Early Mainnet Monitoring Profiles

Acolo trebuie fixate:

profilele concrete de monitorizare pentru primele epoci;
metricile și pragurile;
clasele de alerte;
diferența dintre healthy, degraded și incident-open;
și legătura cu restricted posture și decision ledger.

Închidere

O lansare serioasă nu are doar artefacte bune și operatori pregătiți. Are și memorie instituțională exactă despre deciziile care au dus la start: cine a spus hold, cine a spus go, cine a spus abort, pe ce bază și ce a rămas activ după toate aceste schimbări.

Acolo începe istoria auditabilă reală a lansării.