AZ-023 — Reference Implementation Milestone Map v1

Status

Acest document definește harta de milestone-uri pentru implementarea de referință ATLAS ZERO.

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

• specificația conceptuală și normativă,
• formatul obiectelor,
• regulile de validare,
• consensul și finalitatea,
• BVM,
• witness/proof,
• economia,
• controlul agenților,
• guvernanța,
• securitatea,
• conformitatea,
• arhitectura nodului,
• slashing evidence,
• runbooks,
• genesis,
• vault-ul de artefacte,
• politica de atestare,
• pipeline-ul de build/release,
• și pachetul genesis concret.

AZ-023 răspunde la întrebarea: în ce ordine concretă implementăm sistemul astfel încât să maximizăm corectitudinea, testabilitatea și progresul real, fără să construim prea devreme componente dependente de fundații încă instabile?

Scopul documentului este să fixeze:

• ordinea de implementare;
• dependențele dintre subsisteme;
• milestone-urile minime pentru devnet;
• milestone-urile pentru internal/public testnet;
• milestone-urile pentru mainnet-candidate;
• criteriile de intrare/ieșire pentru fiecare etapă.

Acest document se bazează pe:

• AZ-002 până la AZ-022.

Termeni:

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

1. Obiectiv

AZ-023 răspunde la 10 întrebări practice de execuție:

1. Ce se construiește întâi?
2. Ce componente sunt fundaționale și blochează restul?
3. Ce este minimul pentru un devnet real?
4. Ce lipsește încă înainte de un testnet credibil?
5. Ce ordine minimizează refactorizările periculoase?
6. Cum separăm milestone-urile de specificație, implementare și operațiuni?
7. Ce artefacte de verificare trebuie produse la fiecare etapă?
8. Când poate o componentă fi considerată „stabilă” pentru a construi peste ea?
9. Cum evităm să pornim prea devreme cu optimizări sau features high-risk?
10. Ce definește un mainnet-candidate implementation?

2. Principii

2.1 Correctness before breadth

Mai bine mai puține subsisteme corecte decât multe subsisteme incomplete și incompatibile.

2.2 Deterministic core first

Tot ce influențează:

• hashing,
• canonical decode,
• validare,
• state transition,
• BVM semantics,
• consens, trebuie construit înainte de straturile bogate de produs.

2.3 Build what can be tested

Ordinea SHOULD favoriza componente pentru care putem produce:

• vectori,
• replay,
• diff testing,
• invariant checks.

2.4 Avoid upside-down implementation

Nu construim întâi:

• UI,
• automation bogată,
• agent orchestration high-impact,
• optimizări agresive, când încă nu există nucleul determinist stabil.

2.5 Promotion by evidence

O componentă nu trece la milestone-ul următor doar pentru că „pare făcută”. Trece când are:

• criterii de ieșire,
• testare,
• conformance,
• review minim.

3. Implementation layers

3.1 Layer A — Foundational canonical core

• canonical encoding/decoding
• hash derivation
• object schemas
• error classes
• test vectors

3.2 Layer B — Validation and state core

• policy engine
• transaction validation
• state engine
• receipts
• deterministic replay

3.3 Layer C — Execution core

• BVM verifier
• BVM interpreter/runtime
• effect accounting
• boundedness enforcement

3.4 Layer D — Consensus core

• committee derivation
• candidate DAG/front builder
• verifier voting
• notarization/finality

3.5 Layer E — Witness / proof / economic core

• witness lifecycle
• proof verification
• fee/rent/reward/slash calculations

3.6 Layer F — Governance / recovery / ops core

• governance activation engine
• incident/recovery flows
• slashing evidence path
• snapshots and rebuild

3.7 Layer G — Artifact and release integrity

• vault
• manifest chain
• attestation policy
• build/release pipeline
• genesis package

3.8 Layer H — High-level protocol services

• agent control hooks
• release automation
• validator/operator tooling
• dashboards and observability enhancements

4. Dependency graph

4.1 Hard dependencies

Canonical core blocks everything

Without Layer A, nothing else is trustworthy.

Validation/state core depends on canonical core

Without Layer B, there is no stable notion of valid/invalid or post-state.

BVM depends on canonical core + state core

Without A+B, BVM semantics cannot be integrated safely.

Consensus depends on validation/state

Without B and enough of C, consensus can produce unverifiable candidate states.

Witness/economics depend on validation/state and often BVM

Because they need deterministic state access and policy resolution.

Governance/recovery depend on state, consensus and economic/witness semantics

Otherwise activations and incident handling cannot be anchored correctly.

Vault/build/genesis packaging depends on policy, manifests and release semantics

But parts of vault can start earlier as implementation discipline.

4.2 Soft dependencies

• Agent layer SHOULD wait until witness/economics/governance/recovery are sufficiently mature.
• UI and dashboards SHOULD follow stable APIs rather than drive protocol order.

5. Milestone model

5.1 Standard milestone states

Each implementation domain SHOULD use:

• M0_NOT_STARTED
• M1_PROTOTYPE
• M2_DETERMINISTIC_CORE
• M3_DEVNET_READY
• M4_INTERNAL_TESTNET_READY
• M5_PUBLIC_TESTNET_READY
• M6_MAINNET_CANDIDATE

5.2 Rule

Advancing to a higher state SHOULD require explicit exit criteria, not just calendar time.

6. Milestone 0 — Specification lock foundation

6.1 Goal

Freeze enough of the critical semantics to begin coding safely.

6.2 Required scope

At minimum SHOULD be closed enough:

• AZ-002 object schemas
• AZ-003 validation flow
• AZ-004 consensus/finality high-level rules
• AZ-005 BVM principles
• AZ-011 conformance vector philosophy
• AZ-012 reference node boundaries

6.3 Entry criteria

• documents drafted
• top-level contradictions identified
• unresolved critical ambiguities tracked

6.4 Exit criteria

• canonical object classes stable enough
• basic validation order stable
• no unknown blocker in hash/encoding rules
• reference implementation can start Layer A

7. Milestone 1 — Canonical Core Prototype

7.1 Scope

Implement:

• canonical decoder
• object schema validator
• hash derivation for core objects
• artifact-independent test harness
• error code taxonomy baseline

7.2 Deliverables

• encoding library
• hash library
• schema tests
• initial AZ-011 vectors for encoding/hashing
• parser conformance report

7.3 Exit criteria

• deterministic encode/decode across environments
• stable object ids for core families
• negative cases reject consistently
• no unresolved canonicalization divergence

7.4 This milestone is blocker for:

• tx validation
• manifest/vault correctness
• genesis derivation
• policy engine correctness

8. Milestone 2 — Validation and State Core Prototype

8.1 Scope

Implement:

• policy engine
• tx validation engine
• state engine
• receipt generation
• reference resolution
• replay harness for state transitions

8.2 Minimum supported tx types

SHOULD include:

• TX_VALUE_TRANSFER
• TX_MACHINE_DEPLOY skeleton or placeholder validation path
• TX_MACHINE_CALL shell integration path
• TX_WITNESS_EMIT baseline
• TX_GUARD_HALT baseline
• TX_EPOCH_NOTARIZE validation shell

8.3 Deliverables

• in-memory state engine first
• deterministic receipt generator
• state transition vector suite
• basic reference node core loop without consensus

8.4 Exit criteria

• ApplyTx deterministic replay passes
• policy evaluation stable
• state roots stable
• invalid inputs rejected consistently
• core validation order aligned with AZ-003/AZ-011

9. Milestone 3 — BVM Core Interpreter

9.1 Scope

Implement:

• BVM bytecode parser
• static verifier
• interpreter
• effect accumulator
• exec unit accounting
• state host interface stubs then integrated host interface

9.2 Recommended order inside BVM

1. module parser
2. type verifier
3. function verifier
4. basic arithmetic/runtime
5. host read/write primitives
6. effect accounting
7. bounds and traps
8. export invocation
9. execution result canonicalization

9.3 Deliverables

• reference interpreter
• verifier result object
• BVM-specific vector suite
• deterministic replay of machine call results
• initial machine deploy validation

9.4 Exit criteria

• bytecode verification stable
• basic machine calls deterministic
• effect digest stable
• bounds enforced
• no known interpreter/verifier semantic mismatch

10. Milestone 4 — Devnet Core

10.1 Goal

First end-to-end runnable network with minimal but real protocol path.

10.2 Required scope

• node networking basic
• mempool/candidate pool
• state engine integrated
• BVM integrated for minimal machine calls
• committee derivation minimal
• block proposal and validation
• notarization minimal path
• finalized checkpoint creation
• genesis loading
• basic snapshots

10.3 Recommended simplifications

Devnet MAY:

• use small validator set
• use simplified economics
• keep agent layer mostly disabled
• limit witness/proof families
• run fewer committee roles in same process for convenience if semantics preserved

10.4 Deliverables

• genesis package devnet
• reference node can boot a multi-node devnet
• first finalized epochs
• replay from checkpoint
• local safe mode/recovery drills

10.5 Exit criteria

• devnet finalizes reproducibly
• state replay works
• genesis derivation stable
• node architecture boundaries exercised
• no known deterministic split in devnet scope

11. Milestone 5 — Witness, Proof and Economic Core

11.1 Scope

Implement:

• witness lifecycle engine
• proof verifier registry for launch-set families
• revocation/supersession logic
• fee calculation
• rent logic
• reward/slash calculations
• economic parameter state activation

11.2 Recommended order

1. witness validation + indexing
2. proof type registry and verifier dispatch
3. revocation and supersession
4. fee formulas
5. rent tracking
6. slash record path
7. reward distribution path

11.3 Deliverables

• witness/proof vectors
• economics vectors
• spam simulation harness
• slash computation harness
• reporter reward logic baseline

11.4 Exit criteria

• witness active status stable
• proof families critical to launch verified deterministically
• economics calculations exact and replayable
• no obvious cheap abuse path in internal simulation baseline

12. Milestone 6 — Consensus Hardening

12.1 Scope

Turn minimal devnet consensus into testnet-grade consensus.

12.2 Additions

• full front builder
• front scoring
• tie-breakers
• verifier vote processing
• notary quorum tracking
• fraud proof path for consensus faults
• better partition/no-finality handling

12.3 Deliverables

• consensus simulation suite
• partition/no-finality drills
• double-signing fraud proof generation
• slash path for consensus faults
• metrics for finality health

12.4 Exit criteria

• front selection deterministic in simulations
• invalid notarizations rejected
• no-finality path understood and tested
• double-signing evidence path works end-to-end
• internal testnet can survive expected fault drills

13. Milestone 7 — Governance and Recovery Core

13.1 Scope

Implement:

• governance proposals/reviews/votes/outcomes/activations
• parameter activation boundaries
• emergency restriction path
• recovery manifests
• replay/rebuild tooling
• incident runbook integration hooks

13.2 Deliverables

• governance state engine
• activation scheduler
• challenge/timelock checks
• emergency expiry handling
• recovery manifest handling
• audit trail for governance/recovery

13.3 Exit criteria

• governance activation deterministic
• challenge window behavior test-covered
• emergency restrictions scoped and expiring
• rebuild from trusted snapshot demonstrated
• no governance ambiguity in parameter state

14. Milestone 8 — Vault, Attestation and Release Integrity

14.1 Scope

Implement:

• secure artifact vault
• manifest chain
• attestation verification
• build provenance records
• secure build/release pipeline
• genesis package validation tooling

14.2 Deliverables

• vault admission gate
• manifest validator
• attestation policy engine
• build pipeline provenance artifacts
• release candidate validator
• genesis package validator
• release publication tooling

14.3 Exit criteria

• critical artifacts admitted only by policy
• manifest chain rebuild works
• release candidate creation and validation works
• genesis package integrity verified end-to-end
• release artifacts scope-locked and attestable

15. Milestone 9 — Internal Testnet Ready

15.1 Goal

A serious internal network that exercises nearly all launch-critical semantics.

15.2 Required scope

• stable node
• consensus hardening
• BVM stable for launch subset
• witness/proof subset stable
• economics active
• governance active
• recovery tooling active
• vault/release pipeline usable
• genesis package concrete and reusable

15.3 Required operational practices

• on-call rotation lightweight
• incident drills
• reproducible build checks
• release candidate promotion flow
• snapshot restore drills

15.4 Exit criteria

• internal testnet runs long enough without unexplained deterministic anomalies
• critical drills passed
• release process can publish internal candidates
• incident response workable by actual operators

16. Milestone 10 — Public Testnet Ready

16.1 Goal

Expose protocol to adversarial but non-mainnet conditions.

16.2 Additional requirements

• public testnet genesis package
• public documentation subset
• validator/operator instructions
• stronger telemetry
• bug reporting path
• more complete conformance corpus
• stronger witness/proof and governance review

16.3 Public testnet SHOULD include

• realistic network behavior
• economics close enough to stress core assumptions
• fault drills behind scenes or rehearsed
• release pipeline for public binaries
• clear versioning and deprecation policy

16.4 Exit criteria

• public testnet demonstrates stable finality
• critical bug intake process working
• no repeated unexplained deterministic anomalies
• launch subset features proven under broader use

17. Milestone 11 — Mainnet-Candidate Core

17.1 Goal

Freeze the launch subset and prove it is candidate-grade.

17.2 Required scope

• release artifacts reproducible/verified enough
• full launch subset conformance passing
• security audits integrated
• slashing evidence path complete
• governance bootstrap finalized
• mainnet genesis package finalized
• mainnet readiness record nearly complete

17.3 Deliverables

• launch candidate binaries
• launch candidate genesis package
• conformance reports
• audit closure bundle
• residual risk register
• runbook package
• operator package

17.4 Exit criteria

• zero unresolved criticals
• zero unresolved deterministic divergence
• launch package fully attested
• rollback/replace process prepared pre-launch

18. Milestone 12 — Mainnet Ready / Launch Preparation

18.1 Goal

No new feature work. Only stabilization, evidence closure and launch discipline.

18.2 Work allowed

• critical fixes
• audit remediation
• release packaging
• operator rehearsal
• genesis/release final validation
• documentation closure
• launch window preparation

18.3 Work disallowed by default

• new high-risk features
• semantics-changing refactors
• large architectural rewrites
• opportunistic performance hacks without deep review

18.4 Exit criteria

Aligned with AZ-017 mainnet readiness checklist.

19. Cross-milestone workstreams

19.1 Workstream W1 — Spec and conformance

Runs continuously. Produces:

• clarified specs
• new vectors
• ambiguity closures

19.2 Workstream W2 — Security and audits

Runs from early prototype onward. Produces:

• threat model updates
• review notes
• audit packages
• issue closure evidence

19.3 Workstream W3 — Operations and drills

Starts early in devnet, becomes serious by internal testnet.

19.4 Workstream W4 — Toolchain and release engineering

Starts before internal testnet and must mature before public testnet.

20. Domain-by-domain milestone table

20.1 Canonical core

• M1 prototype
• M2 deterministic core
• stable before M4 devnet

20.2 State/validation core

• M2 prototype
• stable before M4 devnet
• hardened before M9 internal testnet

20.3 BVM

• parser/verifier/interpreter by M3
• integrated by M4
• hardened by M9
• launch subset frozen by M11

20.4 Consensus

• minimal by M4
• hardened by M6
• stable testnet by M9/M10
• launch-grade by M11

20.5 Witness/proof

• minimal indexing may start M4/M5
• hardened by M9
• launch subset frozen by M10/M11

20.6 Economics

• simplified at M4
• realistic by M5/M9
• launch-grade by M11

20.7 Governance/recovery

• minimal scaffolding by M7
• serious by M9
• launch-grade by M11

20.8 Vault/release/genesis package

• foundational vault earlier if team can
• practical by M8
• serious by M9
• launch-grade by M11

20.9 Agents

• minimal hooks may appear earlier
• high-impact execution SHOULD lag behind core readiness
• if not fully ready by M11, feature SHOULD remain disabled at launch

21. Minimum feature set for devnet

21.1 MUST include

• genesis load
• canonical decode/hash
• tx validation
• state transition
• basic consensus/finality
• BVM minimal execution
• snapshot/replay
• node networking basic

21.2 SHOULD defer or simplify

• advanced governance
• advanced oracle/proof families
• high-impact agents
• complex economic tuning
• polished release workflow

21.3 Rule

Devnet is for truth of semantics, not product completeness.

22. Minimum feature set for public testnet

22.1 MUST include

• realistic finality path
• stable genesis package
• release candidate flow
• core economics
• witness/proof families used by public features
• governance path for active parameters
• safe mode / recovery drills
• telemetry and incident response

22.2 MAY keep disabled

• highest-risk agent features
• optional complex proof families
• advanced optimization/JIT paths if not ready

23. Minimum feature set for mainnet-candidate

23.1 MUST include

• all launch-scope protocol semantics frozen
• conformance suites complete for launch subset
• reproducible or strongly verified release path
• genesis package finalization
• slashing path for critical faults
• governance bootstrap finalized
• incident and recovery procedures tested
• audit closures complete enough

23.2 MUST exclude or explicitly defer

Anything not fully launch-ready. Deferred features SHOULD be feature-flag disabled and documented.

24. Entry/exit criteria template for each milestone

24.1 Each milestone SHOULD define

• objective
• included scope
• excluded scope
• dependencies
• required deliverables
• exit criteria
• known accepted limitations
• blockers

24.2 Rule

If exit criteria are fuzzy, milestone completion claims will be unreliable.

25. Stability definition

25.1 A subsystem becomes "stable enough to build on" when:

• core semantics match spec and vectors
• no known deterministic divergence
• failure modes understood
• APIs/internal boundaries documented enough
• critical blockers absent
• at least one realistic integration path tested

25.2 Rule

“Stable enough” is not same as “done forever”. It means safe as dependency for next layer.

26. Refactor policy by milestone

26.1 Early milestones

Refactors are cheap and expected.

26.2 Mid milestones

Refactors MUST be more disciplined. Need:

• migration notes
• vector updates
• replay impact analysis

26.3 Late milestones

Semantics-changing refactors SHOULD be exceptional and well-justified. Near M11/M12, they are dangerous and often blocker-worthy.

27. Performance work policy

27.1 Performance optimization SHOULD start after deterministic reference paths exist.

27.2 Allowed order

1. simple correct path
2. vector-backed reference path
3. profiling
4. optimized path
5. differential validation against reference path

27.3 Rule

Never let performance path define semantics before reference path exists.

28. Parallelization guidance

28.1 Some workstreams MAY progress in parallel:

• vault/build pipeline
• docs/conformance corpus
• operator tooling
• monitoring stack
• basic governance scaffolding

28.2 But these SHOULD wait for core stability:

• high-performance runtime
• public feature-rich agent stack
• aggressive release automation
• multi-implementation promotion to critical trust

29. Deliverable classes per milestone

29.1 Code deliverables

• modules
• libraries
• node services
• tooling

29.2 Verification deliverables

• conformance vectors
• replay cases
• property tests
• simulation outputs
• fuzz harnesses

29.3 Ops deliverables

• runbooks
• dashboards
• alerts
• snapshot tooling
• recovery scripts

29.4 Artifact deliverables

• manifests
• attestations
• provenance records
• release candidates
• genesis packages

30. Milestone review board concept

30.1 Recommendation

Before promoting a milestone, there SHOULD be lightweight review by leads for:

• protocol correctness
• security
• implementation
• ops/release
• conformance/test

30.2 Rule

Milestone promotion SHOULD be recorded, not implicit.

31. Risk register by milestone

31.1 Each milestone SHOULD maintain:

• unresolved blockers
• accepted limitations
• known high-risk assumptions
• deferred features
• rollback plan for milestone failure

31.2 Rule

This prevents confusing “not yet built” with “built and safe”.

32. Failure criteria per milestone

32.1 A milestone SHOULD be considered failed or reverted if:

• deterministic divergence discovered in included scope
• core deliverable incomplete or untestable
• required vectors missing
• critical blocker discovered and unmitigated
• ops assumptions proven false for the milestone goal

32.2 Rule

Milestone failure is not project failure. It is a controlled truth signal.

33. Suggested concrete milestone ordering summary

33.1 Order

1. Canonical core
2. Policy + validation + state
3. BVM verifier/interpreter
4. Minimal devnet
5. Witness/proof + economics
6. Consensus hardening
7. Governance + recovery
8. Vault + attestation + release integrity
9. Internal testnet
10. Public testnet
11. Mainnet-candidate
12. Launch preparation

33.2 Rationale

This order minimizes:

• semantic churn,
• release confusion,
• fragile ops,
• and high-risk features built over unstable foundations.

34. Anti-patterns

Teams SHOULD avoid:

1. building agent automation before stable validation/state core
2. building fancy release pipeline before artifact identity and vault truth exist
3. optimizing BVM before reference interpreter is correct
4. public testnet before replay and conformance are usable
5. mainnet-candidate while governance/bootstrap/genesis still fluid
6. using devnet stability as proof of economic or operational readiness
7. shipping many optional proof/witness families before launch subset is hardened
8. allowing milestone completion by subjective optimism
9. tying protocol milestone decisions to marketing deadlines
10. treating unresolved ambiguity as “we’ll align later”

35. Formal goals

AZ-023 urmărește aceste obiective:

35.1 Dependency correctness

Subsystems are implemented in an order that respects what truly depends on what.

35.2 Verification-first progress

Each milestone produces artifacts that can be tested and replayed.

35.3 Controlled expansion

Feature breadth grows only after core determinism and safety stabilize.

35.4 Launch discipline

By the time mainnet readiness is evaluated, the implementation has followed a staged path rather than improvisation.

36. Formula documentului

Reference Implementation Roadmap = dependency-aware milestone order + explicit entry/exit criteria + verification artifacts + staged promotion from devnet to launch

37. Relația cu restul suitei

• AZ-017 spune când ai dreptul să lansezi.
• AZ-023 spune în ce ordine ajungi realist acolo.

Pe scurt: AZ-017 definește criteriul de sosire; AZ-023 definește drumul.

38. Ce urmează

După AZ-023, pașii cu valoare maximă sunt:

1. AZ-024 — Concrete Conformance Corpus Layout
2. AZ-025 — Validator and Operator Launch Manual
3. AZ-026 — Genesis Ceremony and Launch Ceremony Protocol
4. AZ-027 — Public Testnet Program and Bug Intake Flow
5. AZ-028 — Mainnet Launch Window Procedure

Închidere

Un protocol mare eșuează adesea nu pentru că ideea lui este slabă, ci pentru că implementarea începe în ordinea greșită. Dacă construiești prea sus prea devreme, totul devine refactorizare, improvizație și risc ascuns. Dacă ordinea este corectă, fiecare strat devine fundație verificabilă pentru următorul.

Acolo începe construcția disciplinată reală.