AZ-040 — Formal Conformance Claim Framework v1

Status

Acest document definește cadrul formal pentru afirmațiile de conformitate în ATLAS ZERO.

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

• specificația protocolului și a subsistemelor;
• corpusul de conformitate și layout-ul lui concret;
• launch discipline, monitoring, stabilization, archive și audit export;
• canonul amenințărilor și al riscului rezidual.

AZ-040 răspunde la întrebarea: cum formulăm, clasificăm și verificăm în mod formal afirmațiile de conformitate astfel încât o implementare, un release, un upgrade, un artifact sau un proces să poată spune exact la ce este conform, în ce scope, cu ce versiuni și pe baza căror dovezi?

Scopul documentului este să fixeze:

• modelul formal de conformance claim;
• tipurile de claims;
• scope-ul, precondițiile și dependențele lor;
• bundle-urile de dovezi admise;
• criteriile de suficiență și insuficiență;
• relația dintre claims, corpus, release, upgrade, audit și residual risk.

Acest document se bazează pe:

• AZ-002 până la AZ-039, cu accent direct pe AZ-011, AZ-017, AZ-021, AZ-024, AZ-027, AZ-033, AZ-038 și AZ-039.

Termeni:

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

1. Obiectiv

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

1. Ce este un conformance claim?
2. Ce tipuri de claims trebuie să existe?
3. Cum delimităm exact scope-ul unui claim?
4. Ce dovezi sunt necesare pentru fiecare clasă de claim?
5. Cum distingem claim complet, parțial, condiționat sau invalid?
6. Cum se leagă claims de corpusul de conformitate și de versiuni?
7. Cum se leagă claims de release package, launch, upgrade și incident?
8. Cum tratăm claims supersedate, revocate sau invalidate de noi dovezi?
9. Cum exportăm claims pentru audit extern?
10. Cum evităm afirmațiile de conformitate prea vagi pentru a fi utile sau auditate?

2. Principii

2.1 A conformance claim is a bounded statement, not marketing language

Un conformance claim MUST fi o afirmație precisă, delimitată și verificabilă.

2.2 Claim without scope is weak

Orice claim MUST ancora:

• versiune de protocol;
• versiune de release;
• subset funcțional;
• corpus sau bundle de dovezi;
• eventual rol, rețea sau boundary de activare.

2.3 Evidence sufficiency must be typed

Nu orice dovadă susține orice claim. Tipul de claim determină ce tip de dovadă este suficientă.

2.4 Claim completeness must be explicit

Un claim poate fi:

• complet;
• limitat;
• condiționat;
• parțial;
• sau invalid. Acest lucru MUST fi declarat.

2.5 Claims age when scope changes

Launch, upgrade, hard fork, incident sau corpus changes MAY invalida sau superseda claims existente. Claims nu sunt eterne doar pentru că au fost adevărate la un moment dat.

2.6 Claims must connect to risk posture

Un claim de conformitate nu anulează threat model-ul sau riscul rezidual. El coexistă cu ele și SHOULD menționa limitele sale.

3. Claim purpose

3.1 A formal conformance claim SHOULD answer:

• cine face afirmația;
• despre ce implementare, artifact sau proces;
• față de ce versiune/spec/corpus;
• pentru ce subset de comportament;
• cu ce dovezi;
• și cu ce limite.

3.2 Rule

Dacă un claim nu poate răspunde acestor întrebări, este prea vag.

4. Claim target classes

4.1 Recommended target classes

ATLAS ZERO SHOULD suporta cel puțin:

• TARGET_IMPLEMENTATION
• TARGET_RELEASE_PACKAGE
• TARGET_NODE_BINARY
• TARGET_UPGRADE_ROLLOUT
• TARGET_GENESIS_PACKAGE
• TARGET_OPERATOR_PROCEDURE
• TARGET_MONITORING_PROFILE
• TARGET_ARCHIVE_PRESERVATION_PROCESS
• TARGET_AUDIT_EXPORT
• TARGET_PROTOCOL_SUBSYSTEM

4.2 Rule

Target class MUST be explicit in claim object.

5. Claim classes

5.1 Standard conformance claim classes

ATLAS ZERO SHOULD distinge cel puțin:

• CCL_CANONICAL_ENCODING
• CCL_HASH_DERIVATION
• CCL_OBJECT_VALIDATION
• CCL_STATE_TRANSITION
• CCL_CONSENSUS_AND_FINALITY
• CCL_BVM_EXECUTION
• CCL_WITNESS_AND_PROOF
• CCL_ECONOMICS
• CCL_GOVERNANCE_ACTIVATION
• CCL_RELEASE_PROVENANCE
• CCL_GENESIS_VALIDITY
• CCL_OPERATOR_PROCEDURE
• CCL_UPGRADE_COMPATIBILITY
• CCL_ARCHIVE_INTEGRITY
• CCL_AUDIT_EXPORT_VERIFIABILITY
• CCL_COMPOSITE_SYSTEM

5.2 Rule

Claim class MUST correspond to a meaningful verification family, not arbitrary prose.

6. Claim scope model

6.1 Canonical structure

ConformanceClaimScope {
  scope_id
  target_network_class?
  target_chain_id?
  target_genesis_hash?
  protocol_version
  release_version?
  corpus_id?
  subsystem_root?
  feature_profile_version?
  upgrade_boundary_ref?
}

6.2 Rule

Scope MUST be exact enough that a verifier can tell what is in and what is out.

7. Subsystem root

7.1 Need

Many claims concern only subsets.

7.2 subsystem_root MAY include refs to:

• encoding
• validation
• state engine
• consensus
• BVM
• witness/proof
• economics
• governance
• launch discipline
• upgrade rollout
• archive preservation

7.3 Rule

A subsystem claim MUST NOT be interpreted as whole-system claim unless composite scope says so.

8. Claim object model

8.1 Canonical structure

ConformanceClaim {
  version_major
  version_minor

  claim_id
  claim_class
  claim_target_class
  claim_target_ref
  claim_scope
  claim_status
  sufficiency_class
  evidence_root
  dependency_root?
  limitation_root?
  issuer_policy_ref
  issued_at_unix_ms
  expires_or_review_due_hash?
  metadata_hash?
}

8.2 claim_status

• CLAIM_ACTIVE
• CLAIM_SUPERSEDED
• CLAIM_REVOKED
• CLAIM_EXPIRED
• CLAIM_INVALIDATED

8.3 sufficiency_class

• SUFF_COMPLETE
• SUFF_COMPLETE_FOR_DECLARED_SCOPE
• SUFF_PARTIAL
• SUFF_CONDITIONAL
• SUFF_INSUFFICIENT

8.4 claim_id

claim_id = H("AZ:CONFORMANCE_CLAIM:" || canonical_claim_body)

8.5 Rule

A claim MUST be machine-identifiable and scope-bound.

9. Sufficiency classes

9.1 SUFF_COMPLETE

Strong claim that target conforms fully for the declared scope and required evidence model.

9.2 SUFF_COMPLETE_FOR_DECLARED_SCOPE

Complete, but only for explicitly bounded scope.

9.3 SUFF_PARTIAL

Only a subset of behaviors or phases are covered.

9.4 SUFF_CONDITIONAL

Claim holds only if stated preconditions remain true.

9.5 SUFF_INSUFFICIENT

Evidence or coverage exists but is not enough for reliable claim.

9.6 Rule

Most serious claims SHOULD prefer SUFF_COMPLETE_FOR_DECLARED_SCOPE rather than vague “fully compliant” language.

10. Dependency model

10.1 Need

Some claims depend on other claims or external conditions.

10.2 Canonical structure

ClaimDependency {
  dependency_id
  dependency_class
  dependency_ref
  required
}

10.3 dependency_class examples

• prior_claim
• corpus_version
• release_package
• upgrade_matrix
• monitoring_profile
• archive_verification_run
• governance_activation_record

10.4 Rule

Dependencies MUST be explicit. Hidden dependencies weaken claims.

11. Limitation model

11.1 Need

Claims often have edges and exclusions.

11.2 Canonical structure

ClaimLimitation {
  limitation_id
  limitation_class
  statement_hash
  severity_if_violated
}

11.3 limitation_class examples

• subsystem_only
• test_coverage_gap
• mixed_fleet_excluded
• emergency_scope_excluded
• feature_flag_dependent
• operator_procedure_assumed
• audit_export_redacted

11.4 Rule

Limitations SHOULD be first-class, not hidden in footnotes.

12. Evidence classes for claims

12.1 Recommended evidence classes

• conformance corpus ref
• passing run result bundle
• implementation test report
• simulation result
• release provenance record
• genesis validation record
• operator checklist record
• launch/stabilization review record
• upgrade compatibility matrix
• archive verification record
• external audit export bundle
• incident-free observation window record

12.2 Rule

Different claim classes require different evidence families. One generic test report is not enough for all claims.

13. Evidence sufficiency by claim class

13.1 Examples

CCL_CANONICAL_ENCODING

SHOULD require:

• corpus refs for encoding family
• passing run results
• negative-case coverage

CCL_CONSENSUS_AND_FINALITY

SHOULD require:

• consensus corpus refs
• simulation or replay evidence
• launch/testnet or live observation evidence where scope includes real network behavior

CCL_RELEASE_PROVENANCE

SHOULD require:

• build provenance records
• attestations
• release manifest linkage
• artifact identity verification

CCL_OPERATOR_PROCEDURE

SHOULD require:

• checklist templates
• completed checklist evidence
• runbook refs
• outcome observations

CCL_ARCHIVE_INTEGRITY

SHOULD require:

• archive manifest
• verification runs
• preservation records

13.2 Rule

The framework SHOULD maintain a claim-to-evidence policy matrix.

14. Claim-to-evidence policy matrix

14.1 Canonical structure

ClaimEvidencePolicyMatrix {
  matrix_id
  policy_version
  rule_root
}

14.2 Each rule SHOULD specify

• claim_class
• minimum evidence classes
• whether live observation is required
• whether external audit is required
• whether conformance corpus is mandatory
• whether launch or upgrade scope records are mandatory
• whether residual risk disclosure is mandatory

14.3 Rule

Claims SHOULD be judged against this matrix, not ad hoc expectations.

15. Issuer model

15.1 Claim issuers MAY include:

• reference implementation maintainer
• release authority
• audit authority
• governance authority
• archive preservation authority
• operator governance body
• external auditor, if policy allows auditor-issued claims

15.2 Rule

Issuer class and authority MUST be explicit. Not everyone can make every claim.

16. Claim attestation model

16.1 Claims SHOULD be attested or signed where material.

16.2 Canonical structure

ConformanceClaimAttestation {
  attestation_id
  claim_id
  attestation_class
  attestor_policy_ref
  timestamp_unix_ms
  signature_envelopes
}

16.3 attestation_class examples

• claim_issued
• claim_reviewed
• claim_approved
• claim_superseded
• claim_revoked

16.4 Rule

Serious launch, upgrade and audit-facing claims SHOULD carry attestations.

17. Composite system claims

17.1 Need

Sometimes the claim concerns an entire release or network posture.

17.2 Composite claims SHOULD be built from claim subsets such as:

• encoding claim
• validation claim
• consensus claim
• provenance claim
• genesis claim
• operator procedure claim
• archive claim

17.3 Rule

Composite system claims MUST enumerate component claims or component evidence roots.

18. Conditional claims

18.1 Many claims are only true under conditions like:

• active feature profile
• no hard fork after boundary X
• operator checklist compliance
• release package exact id
• no open critical incidents
• archive verification no older than Y

18.2 Rule

Conditional claims MUST declare those conditions in dependency or limitation roots.

19. Claim invalidation

19.1 A claim MAY become invalid because:

• upgrade changed active semantics
• new critical incident contradicted assumption
• corpus version changed and target not reevaluated
• audit exposed evidence insufficiency
• release artifact was revoked
• archive integrity failed materially

19.2 Rule

Invalidation MUST be explicit, not passive forgetfulness.

20. Claim invalidation object

20.1 Canonical structure

ConformanceClaimInvalidation {
  invalidation_id
  claim_id
  invalidation_reason_class
  evidence_root?
  timestamp_unix_ms
  issuer_policy_ref
}

20.2 invalidation_reason_class examples

• superseded_by_new_scope
• upgrade_changed_semantics
• incident_contradicted_claim
• evidence_insufficient
• artifact_revoked
• corpus_outdated
• archive_failure

20.3 Rule

Invalidated claims remain historically visible.

21. Claim supersession

21.1 Need

A newer claim may replace older one for same scope family.

21.2 Rule

Supersession MUST be explicit:

• prior_claim_id
• new_claim_id
• scope relation
• reason class

21.3 Rule

Older claims MUST NOT be silently rewritten.

22. Claim review triggers

22.1 Claims SHOULD be reviewed when:

• release candidate changes
• launch scope changes
• upgrade activates
• hard fork occurs
• critical incident occurs
• new conformance corpus released
• residual risk canon materially changes
• audit export requested for external review
• preservation verification fails

22.2 Rule

Claims are living artifacts, not one-time labels.

23. Formal claim families by lifecycle phase

23.1 Pre-launch

• release provenance claims
• genesis validity claims
• operator procedure readiness claims
• launch readiness composite claims

23.2 Launch / early mainnet

• launch execution conformance claims
• monitoring profile effectiveness claims
• restricted posture adherence claims

23.3 Upgrade / fork

• compatibility claims
• rollout claims
• cutover correctness claims

23.4 Archive / long-term

• archive integrity claims
• preservation schedule compliance claims
• export verifiability claims

23.5 Rule

Claim families SHOULD match lifecycle realities.

24. Relationship to residual risk canon

24.1 Claims SHOULD NOT erase residual risk.

Instead, claim objects MAY include limitation refs or dependency on residual risk canon snapshot.

24.2 Rule

A strong claim MAY coexist with known residual risks if those risks are declared and do not falsify the claim scope.

25. Relationship to external audit exports

25.1 Claims SHOULD map naturally to external audit export scopes.

25.2 An export SHOULD be able to say:

• these are the claims being audited
• these bundles support them
• these redactions exist
• this completeness class applies

25.3 Rule

Claim framework and audit export format MUST reinforce each other.

26. Claim verification path

26.1 A verifier SHOULD be able to:

1. load claim object
2. verify claim scope
3. inspect sufficiency class
4. inspect dependencies and limitations
5. verify evidence bundle root
6. verify evidence policy matrix satisfaction
7. conclude whether claim is supported for declared scope

26.2 Rule

Claim verification SHOULD be reproducible, not personality-driven.

27. Claim query model

27.1 Useful queries

• What claims are active for release X?
• Which claims were invalidated by upgrade Y?
• Which claims support launch scope Z?
• Which claims are only partial?
• Which claims depend on corpus version Q?
• Which claims remain active after incident I?

27.2 Rule

Claims SHOULD be indexed or queryable by scope, class and target.

28. Claim package for release

28.1 A release MAY include a claim package containing:

• release provenance claim
• protocol subsystem claims
• genesis compatibility claim
• operator procedure readiness claim
• archive expectation claim
• known limitations bundle

28.2 Rule

Release claim package SHOULD remain bounded; avoid implying system-wide perfection.

29. Claim package for upgrade

29.1 Upgrade claim package MAY include:

• compatibility claim
• rollout safety claim
• mixed-fleet tolerance claim
• activation-boundary claim
• post-upgrade observation claim

29.2 Rule

Each upgrade claim SHOULD bind to exact proposal and matrix ids.

30. Claim package for archive preservation

30.1 Archive claim package MAY include:

• archive completeness claim
• archive integrity claim
• preservation schedule compliance claim
• rebuild-verifiability claim
• export verifiability claim

30.2 Rule

These claims SHOULD be linked to archive verification runs and preservation records.

31. Claim failure modes

31.1 Claims may fail because:

• scope underspecified
• evidence incomplete
• evidence outdated
• target changed
• corpus mismatch
• residual risk contradicts claim strength
• dependencies invalidated
• redactions hide required support

31.2 Rule

The framework SHOULD allow rejection of overbroad or undersupported claims.

32. Overclaiming anti-patterns

32.1 Systems SHOULD avoid:

1. “fully compliant” with no scope
2. “production ready” with no claim class or evidence
3. release claims ignoring operator procedure assumptions
4. compatibility claims with no matrix
5. security claims ignoring residual risk canon
6. archive claims with no preservation evidence
7. audit claims relying only on human narrative
8. partial claims phrased as full claims
9. claims never reviewed after hard fork or major incident
10. claim bundles too broad to falsify

33. Formal goals

AZ-040 urmărește aceste obiective:

33.1 Precise conformity language

The system can express conformance in bounded, typed, auditable statements.

33.2 Evidence discipline

Each claim class has an evidence sufficiency model.

33.3 Lifecycle resilience

Claims evolve safely across launch, upgrade, incident and archive preservation.

33.4 Audit usability

External and internal reviewers can verify claims without guessing intent.

34. Formula documentului

Formal Conformance Claim Framework = typed claims + explicit scope + evidence policy matrix + dependencies and limitations + claim lifecycle (review/supersession/invalidation)

35. Relația cu restul suitei

• AZ-024 definește corpusul de conformitate.
• AZ-038 definește exportul de dovezi pentru audit.
• AZ-039 definește canonul de risc rezidual.
• AZ-040 definește limbajul formal prin care toate acestea se transformă în afirmații verificabile de conformitate.

Pe scurt: AZ-024 produce probe, AZ-038 le exportă, AZ-039 le limitează prin risc, iar AZ-040 spune exact ce putem afirma pe baza lor.

36. Ce urmează

După AZ-040, documentul corect este:

AZ-041 — Economic Attack Simulation and Red-Team Evaluation Protocol

Acolo trebuie fixate:

• clasele de atac economic;
• scenariile de simulare;
• red-team objectives;
• metricile de succes sau eșec;
• și cum transformăm rezultatele în residual risk updates, conformance additions și rollout restrictions.

Închidere

Conformitatea reală începe când nu mai spui doar „pare corect”. Începe când poți spune: aceasta este afirmația, acesta este scope-ul, acestea sunt dovezile, acestea sunt limitele, și acestea sunt motivele pentru care afirmația este suficientă — sau nu.

Acolo începe limbajul auditat al conformității.