AZ-038 — External Audit Interface and Evidence Export Format v1

Status

Acest document definește interfața de audit extern și formatul de export al dovezilor pentru ATLAS ZERO.

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

• specificația protocolului și a subsistemelor lui;
• vault-ul de artefacte, manifesturile și atestările;
• pachetele release/genesis;
• launch discipline, monitoring, review și archive;
• upgrade, hard fork, key rotation și long-term archive preservation.

AZ-038 răspunde la întrebarea: cum exportăm dovezile relevante pentru audit extern astfel încât auditorii să poată verifica afirmațiile critice despre launch, upgrade, incident, stabilizare și conservare, fără să depindă de acces complet la infrastructura internă și fără să pierdem integritatea, trasabilitatea sau delimitarea dintre date normative și date sensibile?

Scopul documentului este să fixeze:

• interfața de audit extern;
• clasele de audit și de pachete exportate;
• formatul canonic al bundle-urilor de dovezi;
• regulile de reducție, redacție și minimizare;
• verificabilitatea exporturilor;
• relația dintre export, manifest, atestări și provenance;
• și comportamentul la supersession, revocation și refresh de dovezi.

Acest document se bazează pe:

• AZ-002 până la AZ-037, cu accent direct pe AZ-018 până la AZ-037.

Termeni:

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

1. Obiectiv

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

1. Ce este External Audit Interface?
2. Ce tipuri de audit extern trebuie suportate?
3. Ce bundle-uri de dovezi pot fi exportate?
4. Cum păstrăm verificabilitatea după export?
5. Cum reducem sau redactăm datele sensibile fără să distrugem auditabilitatea?
6. Cum leagă auditorul exportul de artefactele și manifesturile originale?
7. Cum se modelează scope-ul exact al unui export?
8. Cum tratăm exporturi parțiale, incremental refresh și supersession?
9. Cum poate un auditor extern verifica un export fără acces intern complet?
10. Cum evităm exporturi haotice, incomplete sau imposibil de validat?

2. Principii

2.1 Exported evidence must remain cryptographically and semantically anchored

Un export de audit MUST rămâne legat de:

• manifesturile originale;
• identitățile artefactelor;
• atestările și deciziile relevante;
• scope-ul exact pentru care a fost produs.

2.2 Least disclosure compatible with auditability

Interfața SHOULD expune minimum necesar pentru verificare. Nu tot ce este intern trebuie exportat, dar tot ce susține afirmația auditată MUST fi verificabil.

2.3 Redaction must be explicit, not silent omission

Dacă unele date sunt reduse sau redactate, acest lucru MUST fi explicit și reprezentat ca atare în export.

2.4 Export is a view, not new truth

Exportul nu devine sursa normativă primară. El este o vedere verificabilă și scope-bound asupra adevărului deja existent.

2.5 Auditors need reproducible entry points

Auditorul extern SHOULD primi:

• un manifest principal;
• bundle-uri tipizate;
• instrucțiuni minime de verificare;
• mapping clar între afirmație și dovadă.

2.6 Partial export must not pretend completeness

Un export parțial MUST spune clar că este parțial și pentru ce afirmații este suficient.

3. External audit interface purpose

3.1 External Audit Interface (EAI)

EAI este setul de:

• formate canonice;
• manifesturi;
• bundle-uri de export;
• reguli de redactare;
• și proceduri de verificare, prin care ATLAS ZERO poate furniza dovezi externe verificabile.

3.2 Rule

EAI SHOULD support both:

• auditors with deep technical capability;
• external reviewers who need structured, self-describing bundles.

4. Audit classes

4.1 Recommended audit classes

ATLAS ZERO SHOULD suporta cel puțin:

• AUD_LAUNCH_READINESS
• AUD_MAINNET_LAUNCH
• AUD_EARLY_MAINNET_STABILIZATION
• AUD_INCIDENT_RESPONSE
• AUD_UPGRADE_AND_FORK
• AUD_KEY_SECURITY
• AUD_ARCHIVE_PRESERVATION
• AUD_CONFORMANCE_RELEASE
• AUD_PROVENANCE_AND_RELEASE_PIPELINE
• AUD_GOVERNANCE_ACTION

4.2 Rule

Every export SHOULD declare exact audit class and question scope.

5. Evidence export classes

5.1 Recommended export classes

• EE_SUMMARY_ONLY
• EE_VERIFIABLE_MINIMAL
• EE_SCOPE_COMPLETE
• EE_INCREMENTAL_REFRESH
• EE_REDACTED_SCOPE_COMPLETE
• EE_FULL_AUDIT_MIRROR

5.2 Meaning

EE_SUMMARY_ONLY

Human-oriented, low-assurance summary export. Insufficient for serious verification by itself.

EE_VERIFIABLE_MINIMAL

Minimum evidence necessary to verify a narrow claim set.

EE_SCOPE_COMPLETE

Complete export for a defined audit scope.

EE_INCREMENTAL_REFRESH

Exports only deltas since earlier export, with continuity proofs.

EE_REDACTED_SCOPE_COMPLETE

Complete enough for a defined scope but with explicit redactions.

EE_FULL_AUDIT_MIRROR

Near-complete external mirror of an internal audit package.

5.3 Rule

Serious external audits SHOULD prefer EE_VERIFIABLE_MINIMAL, EE_SCOPE_COMPLETE or EE_REDACTED_SCOPE_COMPLETE.

6. Export scope model

6.1 Canonical structure

AuditExportScope {
  export_scope_id
  audit_class
  target_network_class
  target_chain_id?
  target_genesis_hash?
  target_release_package_id?
  target_launch_window_id?
  target_upgrade_proposal_id?
  target_incident_id?
  target_archive_id?
  claim_scope_root
}

6.2 claim_scope_root

Anchors the exact claims the export is meant to support.

6.3 Rule

Export scope MUST be explicit and bounded.

7. Claim model

7.1 Need

Audits test claims, not only files.

7.2 Canonical structure

AuditClaim {
  claim_id
  claim_class
  scope_hash
  statement_hash
  required_evidence_root
}

7.3 claim_class examples

• release_artifact_integrity
• genesis_package_validity
• launch_go_decision_supported
• restricted_posture_exit_supported
• upgrade_cutover_authorized
• key_rotation_auditable
• archive_rebuild_verified

7.4 Rule

Evidence exports SHOULD be organized around claims or claim families, not arbitrary document dumps.

8. Export manifest

8.1 Canonical structure

ExternalAuditExportManifest {
  version_major
  version_minor

  export_id
  export_class
  export_scope
  claim_root
  normative_bundle_root
  auxiliary_bundle_root?
  redaction_root?
  attestation_root?
  source_archive_refs_root?
  generation_time_unix_ms
  metadata_hash?
}

8.2 export_id

export_id = H("AZ:EXTERNAL_AUDIT_EXPORT:" || canonical_export_manifest)

8.3 Rule

The export manifest MUST be the normative entry point for external verification.

9. Normative bundle classes

9.1 Recommended normative bundle classes

• NB_ARTIFACT_IDENTITY
• NB_MANIFEST_CHAIN
• NB_ATTESTATION_CHAIN
• NB_DECISION_LEDGER_SUBSET
• NB_CHECKLIST_SUBSET
• NB_CEREMONY_SUBSET
• NB_MONITORING_EVIDENCE
• NB_INCIDENT_EVIDENCE
• NB_STABILIZATION_EVIDENCE
• NB_ARCHIVE_VERIFICATION_EVIDENCE
• NB_CONFORMANCE_LINKAGE

9.2 Rule

Normative bundles MUST be machine-verifiable and declared in manifest.

10. Auxiliary bundle classes

10.1 Recommended auxiliary bundle classes

• AB_HUMAN_SUMMARY
• AB_DIAGRAMS
• AB_REVIEW_NOTES
• AB_STATUS_TIMELINE
• AB_PUBLIC_ADVISORY_SNAPSHOT
• AB_DASHBOARD_EXPORT
• AB_REDACTION_EXPLANATION

10.2 Rule

Auxiliary bundles MUST be clearly marked non-authoritative unless separately given canonical semantics.

11. Evidence bundle object

11.1 Canonical structure

EvidenceBundle {
  bundle_id
  bundle_class
  bundle_scope_hash
  entry_root
  required
  normative
  notes_hash?
}

11.2 Rule

Each bundle MUST declare whether it is required and normative.

12. Evidence bundle entry object

12.1 Canonical structure

EvidenceBundleEntry {
  entry_id
  entry_class
  artifact_ref?
  record_ref?
  manifest_ref?
  attestation_ref?
  auxiliary_ref?
  required
}

12.2 entry_class examples

• artifact_identity_record
• package_manifest
• decision_record
• checklist_record
• ceremony_record
• monitoring_snapshot
• anomaly_record
• incident_record
• review_record
• conformance_case_ref
• summary_note

12.3 Rule

All required entries MUST be explicitly marked and root-hashed.

13. Source archive linkage

13.1 Purpose

An export should remain linked to source internal archives or vault artifacts.

13.2 Canonical structure

SourceArchiveRef {
  archive_id
  archive_class
  source_manifest_ref
}

13.3 Rule

Serious exports SHOULD include source archive refs or equivalent provenance refs.

14. Redaction model

14.1 Need

Some exports need to hide:

• local operator identifiers;
• internal topology;
• sensitive logs;
• private contact paths;
• non-essential internal notes.

14.2 Rule

Redaction MUST be explicit and scoped.

14.3 Canonical structure

RedactionEntry {
  redaction_id
  target_entry_ref
  redaction_class
  justification_hash
  effect_class
}

14.4 redaction_class examples

• personal_identity_minimization
• infrastructure_topology_minimization
• security_sensitive_path_removal
• legal_privacy_requirement
• third_party_confidentiality

14.5 effect_class

• removed
• replaced_with_hash_only
• replaced_with_summary
• partially_masked

14.6 Rule

A redacted export MUST show what was redacted and why, at least at structural level.

15. Redaction root

15.1 Derivation

redaction_entry_hash_i = H("AZ:EXPORT_REDACTION:" || canonical_redaction_entry_i)
redaction_root = MerkleRoot(redaction_entry_hash_i...)

15.2 Rule

No redactions => use standard empty-root convention or omit by policy consistently.

16. Minimal export for narrow audit claim

16.1 A minimal verifiable export SHOULD include:

• export manifest
• claim list
• only the normative bundles required by those claims
• source archive refs
• attestation refs proving export integrity/completeness for declared scope
• redaction manifest if redacted

16.2 Rule

Minimal export MUST still be sufficient for the declared claims, not merely “small”.

17. Scope-complete export

17.1 A scope-complete export SHOULD include:

• all required records for the declared audit scope
• all claim-supporting bundles
• enough manifest chain and linkage to reconstruct scope truth
• evidence of no missing required entry for scope
• attestation of completeness

17.2 Rule

A scope-complete export SHOULD be auditable without requesting hidden missing pieces for that exact scope.

18. Incremental refresh export

18.1 Need

Audits sometimes happen over time and need delta refreshes.

18.2 Canonical structure

IncrementalExportLinkage {
  linkage_id
  prior_export_id
  current_export_id
  delta_root
  continuity_proof_root
}

18.3 Rule

Incremental refresh MUST prove continuity to earlier export and SHOULD identify superseded or new entries explicitly.

19. Completeness attestation

19.1 Need

Auditor should know whether export is claimed complete for scope.

19.2 Canonical structure

ExportCompletenessAttestation {
  attestation_id
  export_id
  export_scope_hash
  completeness_class
  attestor_policy_ref
  timestamp_unix_ms
  signature_envelopes
}

19.3 completeness_class

• complete_for_declared_scope
• minimal_for_declared_claims
• partial_with_known_omissions
• redacted_complete_for_scope

19.4 Rule

This attestation MUST NOT overclaim beyond actual export scope.

20. Export integrity attestation

20.1 Canonical structure

ExportIntegrityAttestation {
  attestation_id
  export_id
  export_manifest_hash
  normative_bundle_root
  redaction_root?
  attestor_policy_ref
  timestamp_unix_ms
  signature_envelopes
}

20.2 Rule

Every serious export SHOULD include integrity attestation.

21. Export verification path for external auditor

21.1 Auditor SHOULD be able to:

1. load export manifest
2. verify export_id
3. verify normative bundle roots
4. verify attestation bundle
5. inspect claim list
6. resolve evidence entries supporting each claim
7. verify source archive or artifact refs where included
8. assess redactions and completeness claims
9. conclude whether declared claims are supported

21.2 Rule

Export format SHOULD support this path without hidden internal dependencies wherever possible.

22. Sensitive data minimization rules

22.1 Export SHOULD minimize:

• raw personally identifying operator details
• internal-only hostnames or addresses unless directly material
• secrets or secret-adjacent data
• unnecessary raw logs with unrelated noise
• private communications not needed for claim support

22.2 Rule

Minimization MUST NOT remove evidence required for declared claim verification.

23. Normalization of exported paths and containers

23.1 Need

External export may be packaged into portable container.

23.2 Rule

Outer container MAY vary, but SHOULD normalize:

• file ordering
• timestamps if possible
• path naming
• compression behavior if reproducibility desired

23.3 Rule

Container format MUST NOT alter normative artifact bytes.

24. Export package layout

24.1 Recommended layout

external_audit_export/
  export_manifest/
  claims/
  normative/
  auxiliary/
  redactions/
  attestations/
  source_refs/
  checksums/
  docs/

24.2 Meaning

claims/

Claim objects and mapping files.

normative/

Normative evidence bundles.

auxiliary/

Human summaries and context aids.

redactions/

Explicit redaction records and optional rationales.

source_refs/

Links or references to source archives / archive ids / manifests.

docs/

Export guide, verification notes, scope explanation.

24.3 Rule

This layout is recommended for predictability; manifest truth remains canonical.

25. Export claim-to-evidence mapping

25.1 Canonical structure

ClaimEvidenceMap {
  map_id
  claim_id
  supporting_bundle_root
  supporting_entry_root
}

25.2 Rule

Auditor SHOULD not have to guess which files support which claim.

26. Export verification note bundle

26.1 Purpose

Human-readable, non-normative explanation of how to verify bundle.

26.2 MAY include

• bundle classes used
• expected toolchain versions
• summary of redactions
• scope statement
• claim summary table

26.3 Rule

Verification note bundle MUST NOT replace manifest and attestation logic.

27. Export statuses

27.1 Recommended statuses

• EXPORTED_DRAFT
• EXPORTED_REVIEWED
• EXPORTED_RELEASED
• EXPORTED_SUPERSEDED
• EXPORTED_REVOKED

27.2 Rule

Serious audit handoff SHOULD happen only after reviewed or released export state.

28. Export supersession

28.1 Need

A newer export may clarify scope or add evidence.

28.2 Rule

Supersession MUST be explicit:

• prior_export_id
• new_export_id
• supersession_reason
• whether prior export was incomplete, redacted differently or merely refreshed

28.3 Rule

Superseded exports remain historically relevant and SHOULD not disappear.

29. Export revocation

29.1 Need

An export may later be found broken, misleading or scope-inaccurate.

29.2 Rule

Revocation MUST be explicit and SHOULD include:

• export_id
• reason hash
• affected claim scope
• replacement export if any

29.3 Rule

Revoked exports MUST remain auditable as revoked, not silently deleted.

30. Audit-facing filtering policy

30.1 The system SHOULD support filters by:

• audit class
• network scope
• launch window
• upgrade proposal
• incident id
• archive id
• claim class
• sensitivity class

30.2 Rule

Filters MUST NOT silently produce incomplete export while claiming completeness for full broader scope.

31. Evidence export for launch audits

31.1 Launch audit export SHOULD typically include:

• release/genesis package refs
• ceremony records
• go/no-go and authorization records
• operator checklist subset
• launch monitoring evidence
• first epoch observations
• stabilization entry decisions

31.2 Rule

This export SHOULD be sufficient to prove that launch was executed under explicit artifact and decision scope.

32. Evidence export for upgrade / hard fork audits

32.1 Upgrade export SHOULD include:

• upgrade proposal
• compatibility matrix
• rollout policy
• threshold evidence
• cutover decisions
• post-activation monitoring
• stabilization or post-upgrade findings
• operator guidance refs

32.2 Rule

Hard fork exports SHOULD also include identity separation and boundary treatment evidence.

33. Evidence export for incident audits

33.1 Incident audit export SHOULD include:

• incident classification and timeline
• relevant anomaly records
• decisions taken
• affected scopes and artifacts
• recovery or remediation records
• post-incident review and closure status

33.2 Rule

Incident exports MAY require stronger redaction due to sensitivity, but redactions must remain explicit.

34. Evidence export for archive preservation audits

34.1 Preservation export SHOULD include:

• archive manifest
• preservation schedule refs
• verification runs
• migration records
• recovery test records
• degradation findings
• retention policy refs

34.2 Rule

This allows external audit of long-term memory integrity, not just launch-time behavior.

35. Tooling and schema preservation

35.1 The export SHOULD include or reference:

• schema versions
• canonicalization rules
• verifier tool versions or source refs
• bundle class definitions

35.2 Rule

An auditor years later SHOULD still have enough information to parse and verify the export.

36. Query model external auditors SHOULD be able to answer

36.1 Examples

• Which evidence supports claim X?
• Was export Y complete for declared scope?
• What was redacted and why?
• Which source archives back this export?
• Which decision authorized launch or upgrade?
• Was stabilization verdict supported by monitoring and incident evidence?
• Has this export been superseded or revoked?

36.2 Rule

If the export format cannot answer these, it is under-specified.

37. Anti-patterns

Systems SHOULD avoid:

1. sending auditors a flat folder with no export manifest
2. over-redacting until claims become unverifiable
3. under-redacting and leaking unnecessary sensitive data
4. no claim mapping between findings and evidence
5. summary PDF-like exports with no machine-verifiable roots
6. export containers that change normative bytes silently
7. no linkage back to source archive ids
8. partial exports mislabeled as complete
9. no supersession/revocation model for exports
10. relying on tribal explanations instead of export schemas

38. Formal goals

AZ-038 urmărește aceste obiective:

38.1 Verifiable external review

External auditors can verify important claims without privileged internal access to everything.

38.2 Controlled disclosure

Sensitive information is minimized or redacted explicitly without destroying auditability.

38.3 Claim-centered evidence delivery

Evidence arrives organized around the questions being audited.

38.4 Durable audit interface

The export format remains useful across launch, upgrade, incident and preservation audits.

39. Formula documentului

External Audit Interface = scope-bound export manifest + claim model + normative evidence bundles + explicit redaction records + completeness/integrity attestations + source archive linkage

40. Relația cu restul suitei

• AZ-033 definește arhiva internă de launch și audit.
• AZ-037 definește conservarea ei pe termen lung.
• AZ-038 definește cum extragi din aceste surse bundle-uri externe verificabile pentru audit.

Pe scurt: AZ-033 și AZ-037 păstrează adevărul; AZ-038 îl face exportabil și verificabil în afara graniței operaționale interne.

41. Ce urmează

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

1. AZ-039 — Threat Model Consolidation and Residual Risk Canon
2. AZ-040 — Formal Conformance Claim Framework
3. AZ-041 — Economic Attack Simulation and Red-Team Evaluation Protocol
4. AZ-042 — Incident Postmortem Canon and Lessons Registry
5. AZ-043 — Constitutional Record and Network Identity Canon

Închidere

Un audit extern bun nu are nevoie să primească tot. Are nevoie să primească exact suficient, într-o formă care păstrează legătura dintre afirmație și dovadă, dintre bundle și sursa lui, dintre redacție și motivul ei.

Acolo începe interfața de audit matură: nu când trimiți multe fișiere, ci când trimiți o vedere verificabilă, delimitată și onestă asupra adevărului pe care vrei să îl auditezi.