AZ-048 — Public Network Truth Export and Verification Interface v1

Status

Acest document definește interfața publică de export și verificare a adevărului rețelei pentru ATLAS ZERO.

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

• specificația protocolului și a subsistemelor;
• canonul constituțional al identității de rețea;
• registrul parametrilor protocolari;
• canonul legitimității validatorilor;
• canonul adevărului financiar public;
• arhivele, exporturile de audit și păstrarea lor pe termen lung.

AZ-048 răspunde la întrebarea: cum expunem public, într-un format verificabil și stabil, subseturile normative ale adevărului rețelei astfel încât terții să poată valida identitatea, parametrii, validator set-ul, adevărul financiar și lineage-ul constituțional fără acces intern privilegiat și fără a depinde de interpretări informale sau de dashboard-uri opace?

Scopul documentului este să fixeze:

• modelul interfeței publice de adevăr al rețelei;
• clasele de adevăr public exportabil;
• bundle-urile, manifesturile și rădăcinile canonice;
• regulile de consistență, completitudine și versionare a exporturilor publice;
• verificarea terță independentă;
• și relația cu archive, constitutional canon, validator canon, parameter canon și public financial canon.

Acest document se bazează pe:

• AZ-002 până la AZ-047, cu accent direct pe AZ-021, AZ-033, AZ-037, AZ-038, AZ-043, AZ-044, AZ-046 și AZ-047.

Termeni:

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

1. Obiectiv

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

1. Ce este Public Network Truth Interface?
2. Ce subseturi de adevăr normativ trebuie să poată fi exportate public?
3. Cum este modelat exportul public astfel încât să fie verificabil și reproductibil?
4. Cum poate un terț să valideze identitatea rețelei fără acces intern?
5. Cum sunt exportate și verificate parametrii activi?
6. Cum este exportat și verificat validator set-ul legitim?
7. Cum este exportat și verificat adevărul financiar public?
8. Cum se leagă exportul public de lineage-ul constituțional și de branch-uri?
9. Cum tratăm refresh, supersession și boundary-uri istorice?
10. Cum evităm divergența dintre “adevărul public” și “adevărul intern normativ”?

2. Principii

2.1 Public truth is a projection of internal normative truth, not a separate reality

Interfața publică MUST proiecta adevărul normativ intern relevant, nu să creeze o versiune paralelă, incompletă sau reinterpretată a acestuia.

2.2 Public export must be verifiable without trust in presentation layer

Terții SHOULD putea verifica exportul public fără a avea încredere în API-ul, dashboard-ul sau prezentarea care l-a servit.

2.3 Public truth must be scope-bound

Orice export public MUST declara:

• rețeaua;
• identitatea de chain;
• boundary-ul temporal sau istoric;
• branch-ul dacă există divergență constituțională;
• și clasele de adevăr incluse.

2.4 Minimality and completeness must both be explicit

Un export public MAY fi minimal sau complet pentru un scope dat. Dar MUST spune clar ce include și ce nu include.

2.5 Historical verifiability matters

Interfața publică SHOULD permite nu doar “ce este adevărat acum”, ci și “ce era adevărat la boundary-ul X”.

2.6 Public truth must remain compatible with audit truth

Exporturile publice SHOULD fi compatibile cu exporturile de audit și cu arhivele interne, astfel încât lanțul de verificare să rămână coerent.

3. Public network truth purpose

3.1 Interfața SHOULD răspunde public la întrebări precum:

• ce rețea este aceasta?
• care este identitatea și lineage-ul ei constituțional?
• care este setul activ de parametri?
• care este validator set-ul legitim pentru boundary-ul curent?
• care este adevărul financiar public curent?
• ce branch este considerat canonic?
• ce snapshot public este activ pentru boundary-ul X?

3.2 Rule

Dacă nu poate răspunde clar acestor întrebări, interfața publică este incompletă.

4. Public truth classes

4.1 Recommended truth classes

ATLAS ZERO SHOULD suporta cel puțin:

• PT_IDENTITY
• PT_CONSTITUTIONAL_LINEAGE
• PT_ACTIVE_PARAMETERS
• PT_ACTIVE_VALIDATOR_SET
• PT_PUBLIC_FINANCIAL_STATE
• PT_LAUNCH_AND_CONTINUITY_SUMMARY
• PT_UPGRADE_AND_BRANCH_STATUS
• PT_HISTORICAL_BOUNDARY_SNAPSHOT
• PT_PUBLIC_OBLIGATION_STATE
• PT_PUBLIC_VERIFICATION_METADATA

4.2 Rule

Truth class MUST be explicit per bundle și per export.

5. Public truth interface definition

5.1 Public Network Truth Interface (PNTI)

PNTI este setul de:

• obiecte canonice;
• bundle-uri publice;
• manifesturi;
• rădăcini de verificare;
• și reguli de query/export, prin care adevărul public al rețelei este expus și verificat.

5.2 Rule

PNTI SHOULD fi suficient de stabil încât terții să-și poată construi verificatoare și oglinzi independente.

6. Public truth scope model

6.1 Canonical structure

PublicTruthScope {
  public_truth_scope_id
  target_network_class
  target_chain_id
  target_genesis_hash
  constitutional_branch_ref?
  boundary_hash
  truth_class_root
}

6.2 Rule

Niciun export public serios MUST NOT fie servit fără scope explicit.

7. Boundary model

7.1 Public exports SHOULD support boundaries such as:

• current_active_boundary
• finalized_epoch_boundary
• finalized_block_boundary
• launch_boundary
• upgrade_activation_boundary
• recovery_boundary
• branch_split_boundary
• explicit_historical_snapshot_boundary

7.2 Rule

Boundary semantics MUST be deterministic and auditable.

8. Public truth export manifest

8.1 Canonical structure

PublicTruthExportManifest {
  version_major
  version_minor

  export_id
  export_scope
  truth_bundle_root
  consistency_root
  source_canon_root
  completeness_class
  redaction_root?
  generation_time_unix_ms
  metadata_hash?
}

8.2 completeness_class

• complete_for_declared_scope
• minimal_for_declared_classes
• partial_historical
• branch_specific_complete

8.3 Rule

Manifestul MUST fi entry point-ul principal pentru verificare publică.

9. Source canon root

9.1 Need

Exportul public trebuie să rămână legat de canoanele normative sursă.

9.2 source_canon_root SHOULD summarize refs to:

• constitutional record canon
• parameter registry canon
• validator membership canon
• public financial truth canon
• archive or preservation ref where relevant

9.3 Rule

Public truth without source canon linkage is weak.

10. Truth bundle model

10.1 Canonical structure

PublicTruthBundle {
  bundle_id
  truth_class
  bundle_scope_hash
  normative_entry_root
  required
  notes_hash?
}

10.2 Rule

Each truth class SHOULD map to a distinct bundle or clearly identifiable sub-bundle.

11. Identity bundle

11.1 PT_IDENTITY SHOULD include:

• chain identity record
• genesis anchor ref
• network identity summary ref
• current continuity ref if any
• current branch status if relevant

11.2 Rule

Public identity bundle SHOULD be sufficient for a third party to answer “what network is this exactly?”

12. Constitutional lineage bundle

12.1 PT_CONSTITUTIONAL_LINEAGE SHOULD include:

• constitutional lineage entries
• continuity records
• hard fork declarations if any
• constitutional governance acts relevant to current identity
• current lineage root summary

12.2 Rule

Branches and discontinuities MUST remain visible in public truth where they matter.

13. Active parameter bundle

13.1 PT_ACTIVE_PARAMETERS SHOULD include:

• active parameter set ref
• parameter set root
• selected parameter identities and active values
• activation boundary of current set
• parameter registry snapshot ref

13.2 Rule

Public parameter truth SHOULD allow third parties to verify the exact currently active parameter set.

14. Validator set bundle

14.1 PT_ACTIVE_VALIDATOR_SET SHOULD include:

• active validator set record
• validator membership root
• role assignment root
• validator legitimacy review ref if recent major transition occurred
• branch-specific assignment indicators if relevant

14.2 Rule

Public validator truth SHOULD identify the legitimate active set, not just a peer-discovered live set.

15. Public financial state bundle

15.1 PT_PUBLIC_FINANCIAL_STATE SHOULD include:

• active financial state ref
• container identity subset
• container balance root
• obligation root if relevant
• recent reconciliation ref
• branch-specific financial truth indicators if applicable

15.2 Rule

Public financial truth SHOULD be sufficient to verify current treasury/reserve/public obligations scope.

16. Launch and continuity summary bundle

16.1 PT_LAUNCH_AND_CONTINUITY_SUMMARY MAY include:

• launch boundary summary
• mainnet start ref
• latest continuity event
• latest recovery continuity classification
• latest restricted/normalized status if policy exposes it publicly

16.2 Rule

This bundle SHOULD remain summary-level and point back to canonical sources.

17. Upgrade and branch status bundle

17.1 PT_UPGRADE_AND_BRANCH_STATUS SHOULD include where relevant:

• current active protocol version scope
• current upgrade activation summary
• compatibility regime summary
• branch canonicality status
• current fork lineage summary

17.2 Rule

This bundle SHOULD avoid hiding branch splits or upgrade ambiguity.

18. Historical snapshot bundle

18.1 PT_HISTORICAL_BOUNDARY_SNAPSHOT SHOULD support:

• identity at boundary
• parameters at boundary
• validator set at boundary
• financial truth at boundary
• continuity classification at boundary

18.2 Rule

Historical public snapshots MUST be explicit and immutable once published, with supersession only via new export records.

19. Public obligation bundle

19.1 PT_PUBLIC_OBLIGATION_STATE SHOULD include:

• pending obligations root
• matured obligations root if relevant
• obligation class summaries
• authority linkage for material obligations

19.2 Rule

Obligations SHOULD remain public when they affect economic truth materially.

20. Verification metadata bundle

20.1 PT_PUBLIC_VERIFICATION_METADATA SHOULD include:

• schema versions
• canonicalization rules
• hash derivation notes
• verifier tool refs or versions
• export freshness metadata
• supersession or revocation refs if any

20.2 Rule

Terții SHOULD have enough metadata to verify exports independently.

21. Normative entry model

21.1 Canonical structure

PublicTruthEntry {
  entry_id
  entry_class
  record_ref
  required
  historical
}

21.2 entry_class examples

• chain_identity_record
• lineage_entry
• parameter_set_record
• validator_set_record
• financial_state_record
• legitimacy_review_record
• continuity_record
• public_summary_record

21.3 Rule

Entries MUST be canonically ordered and hash-rooted inside bundles.

22. Consistency model

22.1 Public export MUST prove or assert consistency across bundles such as:

• chain identity matches all other bundle scopes
• active parameter set matches upgrade/boundary context
• validator set scope matches constitutional branch and boundary
• financial state scope matches same branch and boundary
• launch or continuity summaries do not contradict active identity

22.2 Rule

Cross-bundle consistency SHOULD be summarized in a consistency root.

23. Consistency root model

23.1 Canonical structure

PublicTruthConsistencyAssertion {
  assertion_id
  assertion_class
  assertion_scope_hash
  evidence_ref_root?
}

23.2 assertion_class examples

• identity_scope_consistent
• parameter_scope_consistent
• validator_scope_consistent
• financial_scope_consistent
• lineage_scope_consistent
• branch_scope_consistent

23.3 Rule

The manifest SHOULD hash these assertions into consistency_root.

24. Freshness model

24.1 Need

Public truth may be current or historical.

24.2 Each export SHOULD indicate:

• generation time
• boundary time or boundary ref
• whether it is current-active or historical snapshot
• whether newer export exists for same truth class and broader freshness

24.3 Rule

No public export SHOULD imply currentness ambiguously.

25. Supersession model for public truth

25.1 A newer public export MAY supersede an older one for:

• same scope class but fresher boundary
• corrected consistency issue
• richer completeness class
• branch-specific clarification

25.2 Rule

Supersession MUST be explicit and SHOULD preserve historical visibility of older exports.

26. Revocation model for public truth

26.1 Need

A public export may later be found wrong, incomplete or misleading.

26.2 Rule

Revocation MUST be explicit and SHOULD include:

• target export id
• reason hash
• affected truth classes
• replacement export if any

26.3 Rule

Revoked public truth exports MUST remain auditable as revoked.

27. Public verification path

27.1 A third-party verifier SHOULD be able to:

1. load export manifest
2. verify export scope
3. verify truth bundle roots
4. verify source canon linkage
5. verify consistency assertions
6. inspect included records and historical refs
7. conclude truth for declared scope and boundary

27.2 Rule

This path SHOULD avoid requiring private infrastructure access.

28. Public query model

28.1 Useful public queries

• what is the current chain identity?
• what constitutional branch is active?
• what parameter set is active now?
• what validator set is currently legitimate?
• what is the latest public financial state?
• what was the truth at boundary X?
• has export Y been superseded or revoked?

28.2 Rule

Public query semantics SHOULD match canonical export objects, not undocumented API quirks.

29. Public truth interface object

29.1 Canonical structure

PublicNetworkTruthInterfaceRecord {
  version_major
  version_minor

  interface_id
  supported_truth_class_root
  current_export_root
  historical_export_root?
  schema_root
  timestamp_unix_ms
}

29.2 Rule

This record SHOULD be the top-level entry point for discoverability of public truth exports.

30. Minimal public truth export

30.1 A minimal export SHOULD include at least:

• identity bundle
• constitutional lineage summary
• active parameter set summary
• active validator set summary
• current financial state summary
• verification metadata
• source canon linkage

30.2 Rule

This is the practical minimum for meaningful public verification of current network truth.

31. Historical public truth export

31.1 A historical export SHOULD include:

• exact historical boundary
• identity and branch status at that boundary
• parameter set at that boundary
• validator set at that boundary
• financial state at that boundary
• continuity/recovery context if relevant

31.2 Rule

Historical exports SHOULD not be retroactively rewritten when later events occur.

32. Branch-specific public truth

32.1 After constitutional split or hard fork, public truth MUST allow branch-specific export.

32.2 Branch-specific export SHOULD indicate:

• branch identity
• parent linkage
• current canonicality status
• branch-local parameter set
• branch-local validator set
• branch-local financial truth

32.3 Rule

Branch ambiguity MUST NOT be hidden under one flattened “network status”.

33. Relationship to audit exports

33.1 Public truth export is not identical to full external audit export.

33.2 Public export SHOULD:

• be more minimal;
• focus on stable normative truth;
• omit unnecessary sensitive detail;
• remain compatible with audit exports via source refs and canon roots.

33.3 Rule

Public export MUST NOT diverge semantically from audit export for overlapping claims.

34. Relationship to preservation

34.1 Public exports SHOULD themselves be preservable and historically queryable.

34.2 Canon SHOULD preserve:

• public manifest versions
• supersession lineage
• revocation lineage
• historical snapshot exports
• verifier metadata versions

34.3 Rule

Public network truth history SHOULD survive interface or infrastructure changes.

35. Relationship to conformance claims

35.1 Some claims MAY reference public truth exports, for example:

• current active parameter set claim
• validator set legitimacy export claim
• public financial truth claim
• branch identity claim
• historical boundary export claim

35.2 Rule

Public truth exports SHOULD be claim-usable without requiring private interpretation.

36. Relationship to constitutional canon

36.1 Public truth MUST respect constitutional canon for:

• identity;
• lineage;
• continuity;
• branch split;
• exceptional recovery classification.

36.2 Rule

If constitutional canon changes, public truth exports SHOULD refresh accordingly with explicit supersession.

37. Relationship to validator and financial canons

37.1 Public truth SHOULD project the currently legitimate:

• validator set;
• role assignment summary where public;
• treasury/reserve/public obligations scope;
• branch-specific financial state if relevant.

37.2 Rule

Projection MUST remain traceable to source canons and boundary.

38. Anti-patterns

38.1 Systems SHOULD avoid:

1. public dashboards with no export manifest
2. public API returning current values with no boundary or scope
3. flattening branch-specific truths into one status page
4. current parameter display with no canonical set root
5. public validator list derived only from live peer gossip
6. public treasury balances with no reconciliation lineage
7. revoking public export silently by replacing files in place
8. historical snapshots overwritten by fresher exports
9. public interface that cannot be independently verified
10. public truth diverging from internal canonical records

39. Formal goals

AZ-048 urmărește aceste obiective:

39.1 Public verifiability

Third parties can verify key network truths without privileged access.

39.2 Unified truth projection

Identity, parameters, validators, finance and lineage appear in one coherent public interface.

39.3 Historical and branch-aware clarity

Public truth remains meaningful across time, recovery and branch splits.

39.4 Durable compatibility with audit and preservation

Public exports remain linkable to deeper audit packages and long-term archives.

40. Formula documentului

Public Network Truth Interface = scope-bound export manifest + classed truth bundles + source canon linkage + consistency assertions + public verification metadata + historical and branch-aware snapshots

41. Relația cu restul suitei

• AZ-043 definește constitutional identity canon.
• AZ-044 definește parameter canon.
• AZ-046 definește validator membership canon.
• AZ-047 definește public financial canon.
• AZ-048 le unifică într-o interfață publică verificabilă.

Pe scurt: AZ-048 este poarta publică prin care adevărul normativ al rețelei devine verificabil de către terți.

42. Ce urmează

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

1. AZ-049 — Machine-Readable Protocol Constitution Bundle
2. AZ-050 — Formal Capability Matrix for Nodes, Operators and External Verifiers
3. AZ-051 — Public Historical Snapshot Canon and Time-Bound Verification Rules
4. AZ-052 — Cross-Canon Consistency and Integrity Verification Framework
5. AZ-053 — Protocol Documentation Closure and Canon Index

Închidere

O rețea publică matură nu cere oamenilor să o creadă pe cuvânt. Le dă un mod verificabil de a vedea: ce rețea este, ce reguli sunt active, cine o validează legitim, ce adevăr financiar public are, și pe ce ramură constituțională se află.

Acolo începe adevărul public verificabil al rețelei.