AZ-049 — Machine-Readable Protocol Constitution Bundle v1

Status

Acest document definește bundle-ul machine-readable al constituției protocolului pentru ATLAS ZERO.

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

specificația protocolului și a subsistemelor;
canoanele constituționale, parametrice, validatoriale și financiare;
disciplinele de launch, upgrade, recovery, archive și public truth export;
framework-urile de threat, conformance, audit și postmortem.

AZ-049 răspunde la întrebarea: cum transformăm întreaga constituție normativă a protocolului într-un bundle machine-readable, versionat, verificabil și suficient de stabil încât unelte, noduri, auditori și arhive să poată consuma aceeași sursă canonică de adevăr fără a depinde de interpretări manuale sau de documentație narativă dispersată?

Scopul documentului este să fixeze:

modelul bundle-ului constituțional machine-readable;
setul de canoane și manifeste incluse;
regulile de versionare, consistență și supersession;
verificarea cross-canon și derivarea rădăcinilor;
exportul public și auditabilitatea bundle-ului;
și relația dintre bundle, constitutional canon, public truth interface și arhivele de lungă durată.

Acest document se bazează pe:

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

Termeni:

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

1. Obiectiv

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

Ce este un machine-readable protocol constitution bundle?
Ce canoane normative trebuie incluse în el?
Cum sunt legate între ele aceste canoane?
Cum este versionat și identificat bundle-ul?
Cum verificăm consistența cross-canon?
Cum tratăm boundary-uri istorice, ramuri și supersession?
Cum consumă bundle-ul nodurile, verificatorii și auditorii?
Cum se leagă bundle-ul de exporturile publice și de exporturile de audit?
Cum se arhivează și se păstrează pe termen lung?
Cum evităm fragmentarea constituției în fișiere narative fără semnificație operațională unificată?

2. Principii

2.1 Constitution bundle is an executable truth interface, not a PDF substitute

Bundle-ul constituțional MUST fi consumabil de unelte și verificatoare, nu doar lizibil uman.

2.2 Canonical composition over ad hoc aggregation

Constituția machine-readable MUST compune canoanele normative existente prin rădăcini și manifeste canonice, nu prin concatenare arbitrară de fișiere.

2.3 One bundle, many projections

Același bundle SHOULD putea alimenta:

validare internă;
export public;
export de audit;
arhivă constituțională;
și toolchain-uri de verificare terță.

2.4 Cross-canon consistency is mandatory

Nu este suficient să avem canoane separate. Bundle-ul MUST putea demonstra că acestea nu se contrazic pentru același scope și boundary.

2.5 Historical and branch-aware truth

Bundle-ul SHOULD suporta atât snapshot-ul curent, cât și snapshot-uri istorice sau branch-specific.

2.6 Supersession must never erase constitutional history

Bundle-urile noi pot superseda bundle-uri vechi, dar MUST NOT șterge sau rescrie tăcut istoria constituțională.

3. Bundle purpose

3.1 The constitution bundle SHOULD answer:

care este constituția normativă activă pentru această rețea și acest boundary?
ce canoane o compun?
care sunt rădăcinile lor?
ce bundle o supersedează sau ce bundle a fost supersedat?
pe ce branch constituțional se află?
ce verificări cross-canon trebuie să treacă?

3.2 Rule

Dacă aceste întrebări nu pot fi răspunse din bundle, el este insuficient.

4. Bundle composition classes

4.1 Recommended included canon classes

ATLAS ZERO SHOULD include cel puțin:

constitutional_record_canon
protocol_parameter_registry_canon
validator_membership_canon
public_financial_truth_canon
public_network_truth_interface_ref
conformance_claim_framework_ref
residual_risk_canon_ref
audit_export_schema_ref
preservation_policy_ref

4.2 Rule

Nu toate componentele trebuie inline. Unele MAY fi incluse prin refs canonice, dar linkage-ul lor MUST fi explicit.

5. Bundle identity model

5.1 Canonical structure

ProtocolConstitutionBundleIdentity {
  version_major
  version_minor

  bundle_id
  bundle_scope_hash
  bundle_class
  constitutional_branch_ref?
  boundary_hash
  creation_time_unix_ms
  metadata_hash?
}

5.2 bundle_class examples

current_active_constitution
historical_constitution_snapshot
branch_specific_constitution
audit_export_constitution_bundle
recovery_transition_constitution_bundle

5.3 Rule

bundle_id MUST uniquely identify a specific constitution bundle for a specific scope and boundary.

6. Bundle scope model

6.1 Canonical structure

ProtocolConstitutionBundleScope {
  scope_id
  target_network_class
  target_chain_id
  target_genesis_hash
  constitutional_branch_ref?
  protocol_boundary_hash
  inclusion_profile_root
}

6.2 inclusion_profile_root

Defines what canon families and projections are included.

6.3 Rule

Bundle scope MUST bind network identity, branch and boundary explicitly.

7. Inclusion profiles

7.1 Recommended inclusion profiles

CBP_MINIMAL_VERIFIER
CBP_PUBLIC_EXPORT
CBP_AUDIT_DEEP
CBP_ARCHIVE_FULL
CBP_HISTORICAL_BOUNDARY
CBP_BRANCH_SPECIFIC

7.2 Meaning

CBP_MINIMAL_VERIFIER

Enough for machine verification of active constitutional truth.

CBP_PUBLIC_EXPORT

Optimized for public truth interface projection.

CBP_AUDIT_DEEP

Includes richer evidence and refs for auditors.

CBP_ARCHIVE_FULL

Preservation-grade constitutional package.

CBP_HISTORICAL_BOUNDARY

Historical constitution at a declared boundary.

CBP_BRANCH_SPECIFIC

Focused on one branch after fork/divergence.

7.3 Rule

Inclusion profile MUST be explicit to avoid fake completeness.

8. Top-level bundle object

8.1 Canonical structure

MachineReadableProtocolConstitutionBundle {
  version_major
  version_minor

  identity
  scope
  canon_manifest_root
  consistency_root
  dependency_root?
  supersession_root?
  attestation_root?
  export_projection_root?
  metadata_hash?
}

8.2 Rule

This object SHOULD be the top-level machine-readable artifact for constitutional consumption.

9. Canon manifest model

9.1 Purpose

Declares included canons and their roots.

9.2 Canonical structure

ConstitutionCanonManifestEntry {
  entry_id
  canon_class
  canon_ref
  canon_root
  required
  inclusion_mode
}

9.3 inclusion_mode examples

inline
canonical_ref
snapshot_ref
branch_ref
export_projection_ref

9.4 Rule

Required canons MUST be explicitly marked and root-bound.

10. Canon manifest root

10.1 Derivation

canon_manifest_entry_hash_i =
  H("AZ:CONST_BUNDLE_CANON_ENTRY:" || canonical_entry_i)

canon_manifest_root = MerkleRoot(canon_manifest_entry_hash_i...)

10.2 Rule

Canonical ordering MUST be deterministic by canon_class and ref semantics.

11. Core required canons

11.1 For a serious current-active bundle, the following SHOULD be required:

constitutional_record_canon
protocol_parameter_registry_canon
validator_membership_canon
public_financial_truth_canon

11.2 Recommended additional refs

public_network_truth_interface_ref
conformance_claim_framework_ref
residual_risk_canon_ref

11.3 Rule

If a required core canon is missing, the bundle SHOULD be incomplete.

12. Cross-canon consistency model

12.1 The bundle MUST support assertions such as:

all canons bind the same chain identity and branch
active parameter set scope matches current constitutional scope
active validator set scope matches branch and boundary
public financial truth scope matches same branch and boundary
public truth interface projection matches source canons
no included canon is superseded in a way that invalidates bundle consistency

12.2 Rule

Cross-canon consistency SHOULD be machine-verifiable.

13. Consistency assertion object

13.1 Canonical structure

ConstitutionConsistencyAssertion {
  assertion_id
  assertion_class
  participating_canon_root
  assertion_scope_hash
  evidence_root?
}

13.2 assertion_class examples

shared_identity_consistent
shared_boundary_consistent
branch_lineage_consistent
validator_parameter_consistent
financial_parameter_consistent
public_projection_consistent
supersession_consistent

13.3 Rule

Assertions MUST be type-stable and queryable.

14. Consistency root derivation

14.1 Derivation

consistency_assertion_hash_i =
  H("AZ:CONST_BUNDLE_ASSERTION:" || canonical_assertion_i)

consistency_root = MerkleRoot(consistency_assertion_hash_i...)

14.2 Rule

A bundle with no valid consistency root SHOULD not be considered trustworthy.

15. Dependency model

15.1 Some bundles depend on:

specific branch identity
historical snapshot availability
archive verification state
verifier schema versions
specific export schema versions
preservation attestation state

15.2 Canonical structure

ConstitutionBundleDependency {
  dependency_id
  dependency_class
  dependency_ref
  required
}

15.3 dependency_class examples

archive_bundle
schema_bundle
verifier_toolchain
public_export_schema
historical_snapshot
branch_ancestry_ref

15.4 Rule

Dependencies MUST be explicit for long-term reproducibility.

16. Attestation model

16.1 Serious constitution bundles SHOULD carry attestations such as:

bundle_issued
consistency_verified
archive_preserved
public_projection_verified
supersession_declared

16.2 Canonical structure

ConstitutionBundleAttestation {
  attestation_id
  bundle_id
  attestation_class
  attestor_policy_ref
  timestamp_unix_ms
  signature_envelopes
}

16.3 Rule

Attestations add confidence but MUST NOT replace root-level machine verification.

17. Supersession model

17.1 A newer bundle MAY supersede an older one because:

boundary advanced;
branch status changed;
included canon root refreshed;
new branch-specific truth emerged;
previous bundle was incomplete or corrected.

17.2 Canonical structure

ConstitutionBundleSupersession {
  supersession_id
  prior_bundle_id
  new_bundle_id
  supersession_reason_class
  scope_relation_hash
}

17.3 supersession_reason_class examples

fresher_boundary
corrected_consistency
branch_specific_split
historical_snapshot_refinement
audit_complete_replacement

17.4 Rule

Supersession MUST preserve discoverability of prior bundle lineage.

18. Historical bundle model

18.1 Historical bundles SHOULD support exact reconstruction of:

identity and lineage at boundary X
parameter truth at boundary X
validator set at boundary X
public financial truth at boundary X
branch status at boundary X

18.2 Rule

Historical bundles MUST remain immutable once issued, except via explicit supersession records.

19. Branch-specific bundle model

19.1 After hard fork or constitutional split, branch-specific bundles SHOULD include:

branch identity ref
parent lineage linkage
branch-specific parameter set
branch-specific validator set
branch-specific financial truth
branch-specific public export projection if available

19.2 Rule

Branch bundles MUST NOT hide branch divergence behind generic network naming.

20. Recovery transition bundle

20.1 During exceptional recovery, a bundle MAY represent:

pre-recovery constitutional truth
proposed recovered truth
ratified recovered truth
disputed transition state

20.2 Rule

Recovery transition bundles SHOULD clearly distinguish candidate and ratified constitutional truth.

21. Projection model

21.1 One constitution bundle MAY produce projections for:

public network truth interface
external audit export
verifier-minimal bundle
preservation archive bundle

21.2 Canonical structure

ConstitutionProjectionRecord {
  projection_id
  source_bundle_id
  projection_class
  projected_root
  projection_scope_hash
}

21.3 projection_class examples

public_truth_projection
audit_projection
verifier_projection
archive_projection

21.4 Rule

Projections MUST remain traceable to source constitution bundle.

22. Minimal verifier bundle

22.1 A minimal verifier-oriented constitution bundle SHOULD include:

chain identity canon ref
active parameter set ref
active validator set ref
financial state summary ref
consistency assertions
schema metadata

22.2 Rule

This profile SHOULD be enough for third-party verification of current active constitutional truth.

23. Audit-deep bundle

23.1 An audit-deep constitution bundle SHOULD additionally include:

historical continuity refs
branch lineage refs
legitimacy review refs
selected attestation refs
supersession lineage
archive preservation linkage

23.2 Rule

Audit-deep does not mean dumping everything. It means richer, traceable constitutional evidence.

24. Bundle schema and parsing

24.1 Bundle consumers SHOULD have access to:

schema versions
canonicalization rules
hash derivation rules
ordering rules
inclusion profile definitions
supersession semantics

24.2 Rule

A machine-readable constitution bundle without durable parsing rules is weak.

25. Verification path for a machine consumer

25.1 A verifier SHOULD be able to:

load top-level bundle
verify bundle identity and scope
verify canon manifest root
resolve required canon roots
verify consistency assertions
resolve supersession status if needed
derive projection or answer scope-specific questions

25.2 Rule

Verification MUST not depend on undocumented conventions.

26. Verification path for a human auditor

26.1 A human auditor SHOULD be able to:

identify current branch and boundary
identify included canons
see active parameter and validator truth
verify public financial summary linkage
understand whether bundle is current, historical or branch-specific
trace supersession and archival lineage

26.2 Rule

Human readability is secondary, but navigability SHOULD still exist.

27. Query model

27.1 Useful queries

what is the latest active constitution bundle for chain X?
which bundle was active at boundary Y?
which branch-specific bundle superseded the prior active bundle after fork Z?
what canon roots compose bundle B?
is bundle B consistent with public truth export E?
which bundle is preserved as archive-grade constitutional memory?

27.2 Rule

The bundle ecosystem SHOULD be queryable by branch, boundary, scope and supersession lineage.

28. Relationship to public truth interface

28.1 PNTI SHOULD be derivable as projection from the constitution bundle or from the same canon roots.

28.2 Rule

Public truth MUST NOT semantically drift away from constitution bundle truth.

28.3 Rule

A public export SHOULD point back to its source constitution bundle where feasible.

29. Relationship to archive and preservation

29.1 Constitution bundles SHOULD be:

archived;
preserved long-term;
periodically verified;
exportable for audit and public consumption.

29.2 Rule

The constitution bundle is itself a preservation-critical artifact.

30. Relationship to conformance claim framework

30.1 Conformance claims MAY reference:

exact constitution bundle id
included canon roots
projection roots
current/historical boundary scope

30.2 Rule

Claims about “current network truth” SHOULD point to constitution bundle or compatible public truth projection.

31. Relationship to threat canon

31.1 Threat canon SHOULD treat these as protected surfaces:

canon omission
cross-canon inconsistency
stale public projection
broken supersession lineage
archive degradation of constitutional bundle
branch ambiguity

31.2 Rule

Bundle integrity and consistency are security-relevant, not merely documentation concerns.

32. Bundle archival layout

32.1 Recommended layout

constitution_bundle/
  bundle_manifest/
  canon_refs/
  assertions/
  projections/
  attestations/
  schemas/
  supersession/
  docs/

32.2 Meaning

bundle_manifest/

Top-level bundle object and scope metadata.

canon_refs/

Manifested canon refs or inlined canon snapshots.

assertions/

Consistency assertions and roots.

projections/

Public, audit, verifier or archive projections.

attestations/

Bundle attestations.

schemas/

Schema and parsing rules.

supersession/

Supersession and lineage records.

docs/

Human-readable navigation notes.

32.3 Rule

Layout is recommended, but canonical roots remain the real authority.

33. Public discoverability model

33.1 For public-facing deployment, the system SHOULD expose:

latest active bundle id
latest branch-specific bundle ids
historical bundle discovery endpoints or refs
schema and verification metadata
supersession chain discovery

33.2 Rule

Discoverability SHOULD not depend on tribal knowledge.

34. Anti-patterns

34.1 Systems SHOULD avoid:

calling a folder of json files a constitution bundle with no top-level root
composing canons manually with no consistency assertions
public truth export not traceable to source constitution bundle
historical bundle overwritten in place
branch-specific truth hidden under one active bundle
no schema/version metadata
supersession with no preserved lineage
machine-readable bundle that still requires prose interpretation for scope
missing required canons for current-active scope
bundle treated as documentation convenience rather than normative artifact

35. Formal goals

AZ-049 urmărește aceste obiective:

35.1 Unified machine-readable constitution

The protocol has one composable machine-readable artifact representing active constitutional truth.

35.2 Cross-canon coherence

Identity, parameters, validator membership and public financial truth remain internally consistent inside one bundle.

35.3 Verifier and auditor usability

Tools and humans can both consume the same normative package without semantic drift.

35.4 Durable preservation and projection

The constitution bundle can be archived, exported and projected publicly without losing traceability.

36. Formula documentului

Machine-Readable Constitution Bundle = top-level scope-bound bundle + included canon roots + consistency assertions + projection records + supersession lineage + durable schema metadata

37. 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 definește public truth interface.
AZ-049 le compune într-un singur pachet normativ machine-readable.

Pe scurt: AZ-049 este forma executabilă și verificabilă a constituției protocolului.

38. Ce urmează

După AZ-049, documentul corect este:

AZ-050 — Formal Capability Matrix for Nodes, Operators and External Verifiers

Acolo trebuie fixate:

ce capabilități are fiecare clasă de actor;
ce poate valida, consuma, exporta sau decide;
ce bundle-uri și adevăruri îi sunt accesibile;
și cum evităm confuzia dintre rolurile de nod, operator, auditor și verificator extern.

Închidere

O constituție de protocol devine matură abia când nu mai trăiește doar în texte separate. Devine matură când poate fi consumată direct ca adevăr unificat: identitate, parametri, validatori, adevăr financiar, lineage, proiecții publice și reguli de verificare.

Acolo începe bundle-ul constituțional machine-readable real.