AZ-018 — Secure Artifact Vault, Integrity Chain, and File Admission Gate v1

Status

Acest document introduce stratul de protecție pentru toate artefactele produse în ecosistemul ATLAS ZERO:

• specificații,
• cod,
• manifesturi,
• fișiere de build,
• pachete de release,
• fixture-uri,
• audit notes,
• vectori de conformitate,
• și orice fișier nou adăugat în folderul de lucru.

Scopul lui este să răspundă la cerința operațională critică: niciun fișier nou nu trebuie acceptat în folder fără să treacă printr-o mașină de securitate care verifică integritatea, identitatea, unicitatea, structura și trasabilitatea.

Acest document nu pretinde „securitate absolută”. Dar definește un sistem mult mai puternic decât simpla salvare de fișiere într-un folder.

Acest document se bazează pe:

• AZ-002 până la AZ-017, și adaugă un strat transversal pentru securizarea artefactelor.

Termeni:

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

1. Obiectiv

AZ-018 răspunde la 10 întrebări:

1. Cum protejăm fișierele generate împotriva coruperii?
2. Cum prevenim duplicatele exacte și duplicatele periculoase?
3. Cum identificăm fiecare fișier în mod unic și verificabil?
4. Cum validăm orice fișier nou înainte de a intra în folder?
5. Cum păstrăm lanț de integritate între fișiere?
6. Cum detectăm modificări neautorizate sau rupturi de structură?
7. Cum tratăm fișierele suspecte, invalide sau necanonice?
8. Cum protejăm codul, specificațiile și manifesturile separat?
9. Cum facem recovery dacă un folder este corupt?
10. Cum transformăm folderul într-un vault verificabil, nu într-un director obișnuit?

2. Principii

2.1 Default deny

Orice fișier nou MUST fi tratat inițial ca neîncredere. Intrarea în folderul securizat se face doar după validare.

2.2 Content-addressed identity

Fiecare fișier MUST avea identitate derivată din conținutul său canonic, nu din numele local.

2.3 Chain of custody

Orice artefact SHOULD putea fi urmărit:

• cine l-a generat,
• când,
• din ce surse,
• cu ce hash,
• în ce versiune de protocol,
• și prin ce pipeline a fost acceptat.

2.4 Immutable evidence first

Înainte de orice mutare, redenumire sau indexare, sistemul SHOULD fixa:

• hash-ul integral,
• hash-urile pe chunk-uri,
• mime/type class,
• size,
• canonical metadata,
• verdictul de admitere.

2.5 Quarantine before trust

Fișierele suspecte, necunoscute sau incomplete MUST intra mai întâi în quarantine, nu în vault-ul principal.

2.6 No hidden overwrite

Un fișier nou MUST NOT suprascrie tăcut un fișier existent fără:

• verificare de identitate,
• verificare de versiune,
• trasabilitate,
• și regulă explicită de supersession.

3. Scope

AZ-018 se aplică la:

• documente .md, .txt, .json, .yaml
• cod sursă
• bytecode/module blobs
• manifests
• fixtures și test vectors
• genesis packages
• build artifacts
• release bundles
• audit reports
• semnături și dovezi asociate

Nu se limitează doar la text. Este un protocol de admitere și protecție pentru orice artefact care intră în spațiul proiectului.

4. Secure folder model

4.1 Folder classes

Sistemul SHOULD separa fizic și logic cel puțin:

• incoming/
• quarantine/
• staging/
• vault/
• manifests/
• indexes/
• snapshots/
• trash_or_revoked/

4.2 Semantics

incoming/

Loc de aterizare brută. Nimic din incoming/ nu este încă trusted.

quarantine/

Fișiere suspecte, nevalidate, duplicate problematice sau corupte.

staging/

Fișiere care au trecut validările tehnice de bază, dar nu au încă verdict final de admitere.

vault/

Fișiere admise oficial, indexate, hash-uite și ancorate în manifest.

manifests/

Manifesturi de lot, de folder, de versiune, de snapshot.

indexes/

Indexuri pentru lookup, fingerprinting, duplicate detection.

snapshots/

Checkpoint-uri complete ale vault-ului.

trash_or_revoked/

Fișiere scoase din uz, înlocuite sau revocate, dar păstrate auditabil.

5. Identity model for files

5.1 File identity

Orice fișier admis MUST avea:

• artifact_id
• content_hash
• canonical_hash
• chunk_root
• metadata_hash
• admission_record_id

5.2 content_hash

content_hash = H("AZ:FILE:RAW:" || raw_bytes)

5.3 canonical_hash

Dacă fișierul aparține unui tip care are canonical form:

canonical_hash = H("AZ:FILE:CANONICAL:" || canonical_representation)

Pentru fișiere binare brute fără canonical rewrite, canonical_hash MAY egala content_hash.

5.4 artifact_id

artifact_id = H("AZ:ARTIFACT:" || canonical_artifact_identity_record)

5.5 Rule

Numele fișierului nu este identitatea fișierului. Hash-ul și record-ul său canonical sunt identitatea.

6. Canonical artifact identity record

6.1 Structure

ArtifactIdentityRecord {
  version_major
  version_minor

  artifact_type
  content_hash
  canonical_hash
  chunk_root
  byte_size
  mime_class
  extension_class
  producer_class?
  protocol_version?
  metadata_hash
}

6.2 artifact_type examples

• spec_document
• source_code
• manifest
• fixture
• vector_bundle
• genesis_blob
• release_binary
• audit_report
• signature_bundle
• proof_blob

6.3 Rule

Același fișier cu același conținut și aceeași canonical metadata MUST produce același artifact_id.

7. Chunking and chunk root

7.1 Need

Pentru fișiere mari sau recovery granular, hash-ul integral nu este suficient.

7.2 Chunking model

Fișierul SHOULD fi împărțit în chunk-uri determinate de:

• chunk size fixă sau
• content-defined chunking, dacă sistemul este suficient de bine specificat.

V1 SHOULD favoriza chunk size fixă pentru simplitate.

7.3 Recommended initial chunk size

• text and code: 64 KiB
• large binary artifacts: 256 KiB or 1 MiB

7.4 chunk_hash

chunk_hash_i = H("AZ:FILE_CHUNK:" || chunk_index || chunk_bytes)

7.5 chunk_root

Chunk-urile MUST fi agregate într-un Merkle root sau alt root canonical:

chunk_root = MerkleRoot(chunk_hash_0 ... chunk_hash_n)

7.6 Rule

Orice recovery sau repair SHOULD putea verifica chunk-by-chunk integritatea.

8. Metadata model

8.1 Metadata fields

Fiecare fișier SHOULD avea metadata canonicală:

ArtifactMetadata {
  original_filename_hash
  normalized_filename_hash
  declared_type
  creation_time
  ingestion_time
  producer_identity?
  source_context_hash?
  parent_artifact_refs?
  supersedes_refs?
  tags_hash?
}

8.2 Rule

Metadata MUST fi separată de conținutul brut, dar ancorată prin metadata_hash.

8.3 No mutable silent metadata

Schimbarea metadata relevante MUST produce alt metadata_hash și nou record.

9. Filename normalization

9.1 Need

Numele fișierului este util operațional, dar periculos ca identificator.

9.2 Rule

Sistemul SHOULD normaliza:

• unicode form
• case policy
• separator policy
• extension parsing

9.3 Example normalized constraints

• lowercase recommended for internal index keys
• no control chars
• no path traversal
• no hidden trailing spaces/dots
• no duplicate semantically equivalent names under normalization

9.4 Rule

Vault admission MUST reject sau rename canonical fișierele cu nume periculoase sau ambigue.

10. Admission gate overview

10.1 Core principle

Orice fișier nou MUST trece printr-o mașină de admitere în mai multe faze.

10.2 Canonical order

1. landing in incoming/
2. raw fingerprinting
3. structural file sanity checks
4. type detection / type enforcement
5. canonicalization if applicable
6. duplicate detection
7. policy checks
8. integrity checks
9. security checks
10. admission verdict
11. move to staging/, vault/ or quarantine/

11. Admission states

11.1 Standard states

• RECEIVED
• FINGERPRINTED
• TYPE_CHECKED
• CANONICALIZED
• DEDUP_CHECKED
• POLICY_CHECKED
• SECURITY_CHECKED
• ADMITTED
• QUARANTINED
• REJECTED
• SUPERSEDED
• REVOKED

11.2 Rule

Un fișier în RECEIVED sau FINGERPRINTED MUST NOT fi tratat ca trusted.

12. Structural sanity checks

12.1 Checks

Admission gate MUST verifica:

• file exists and readable
• size > 0 if type requires
• size <= allowed max for declared class
• extension and mime are consistent enough
• no path traversal or hidden path tricks
• no null-byte filename issues
• no forbidden symlink tricks if filesystem context matters

12.2 Rule

Fișierele care pică aici intră direct în quarantine sau rejection.

13. Type detection and enforcement

13.1 Need

Un fișier .md care este de fapt binar corupt nu trebuie tratat ca document.

13.2 Checks

Gate-ul SHOULD determina:

• mime_class
• extension_class
• declared_type
• artifact_type candidate

13.3 Rule

Dacă declared_type și detected_type sunt incompatibile, verdictul SHOULD fi:

• quarantine sau
• reject, în funcție de policy.

14. Canonicalization stage

14.1 Need

Pentru documente, manifeste, JSON, YAML, vectori și unele fișiere de cod, canonicalizarea reduce ambiguitatea.

14.2 Examples

• normalize line endings
• trim forbidden BOM where policy says so
• canonical JSON serialization
• canonical ordering for manifests
• stable markdown normalization policy where applicable

14.3 Rule

Canonicalization MUST NOT schimba sensul semantic. Dacă canonicalizarea ar modifica ambiguu conținutul, fișierul SHOULD fi quarantined pentru review.

15. Duplicate detection

15.1 Exact duplicates

Două fișiere cu același content_hash sunt duplicate exacte.

15.2 Canonical duplicates

Două fișiere cu content_hash diferit, dar același canonical_hash, sunt duplicate canonice.

15.3 Dangerous near-duplicates

Fișiere foarte similare dar nu identice pot fi problematice pentru:

• document drift
• conflicting specs
• subtle code tampering
• shadow copies

15.4 Rule

Sistemul SHOULD păstra cel puțin:

• exact duplicate detection
• canonical duplicate detection
• optional near-duplicate heuristic classification

15.5 Verdict guidance

• exact duplicate already admitted -> link existing artifact, do not re-admit as new truth
• canonical duplicate -> require supersession or alias rule
• suspicious near-duplicate of critical file -> quarantine

16. Supersession model for files

16.1 Need

Nu toate fișierele noi sunt duplicate; unele sunt versiuni noi legitime.

16.2 Rule

Orice fișier care înlocuiește alt fișier SHOULD declara:

• supersedes_artifact_id
• reason class
• compatibility note hash
• producer identity if relevant

16.3 Supersession classes

• patch
• revision
• canonical reformat
• security replacement
• emergency revocation replacement
• deprecated successor

16.4 Rule

Supersession MUST be explicit, not guessed from filename alone.

17. Integrity checks

17.1 Core checks

Admission gate MUST verifica:

• content_hash consistency
• canonical_hash consistency
• chunk hash list consistency
• chunk_root consistency
• byte_size consistency
• metadata_hash consistency

17.2 If any mismatch

Verdict MUST be:

• QUARANTINED or
• REJECTED

17.3 Rule

A corrupted file MUST never silently enter vault.

18. Security checks

18.1 Baseline security machine

Orice fișier nou MUST trece printr-o mașină de securitate de admitere.

18.2 The machine SHOULD check:

• integrity mismatch
• type mismatch
• duplicate collision
• filename ambiguity
• malformed canonical structure
• oversized object
• suspicious hidden binary sections in text-like files
• forbidden executable markers where not allowed
• inconsistent declared producer/source chain
• invalid signature/manifests if provided

18.3 For code files

Security machine SHOULD additionally check:

• encoding sanity
• line ending normalization policy
• forbidden hidden chars
• suspicious truncation
• syntax parse if language parser available
• manifest linkage if part of release/build set

18.4 For manifests

It MUST check:

• canonical ordering
• referenced artifact existence
• root/hash correctness
• no duplicate artifact entries
• no broken dependency chains

19. Admission policy engine

19.1 Purpose

Nu toate artefactele au aceeași politică de admitere.

19.2 Policy classes

• permissive_dev
• strict_spec
• strict_release
• critical_genesis
• critical_binary
• archive_only
• quarantine_only

19.3 Rule

Fișierele critice (genesis, release binaries, manifests, security docs, protocol specs) MUST trece prin politici mai stricte decât fișierele auxiliare.

20. File classes by criticality

20.1 Criticality tiers

• TIER_0_INFO
• TIER_1_NORMAL
• TIER_2_IMPORTANT
• TIER_3_CRITICAL
• TIER_4_CONSTITUTIONAL

20.2 Examples

TIER_0_INFO

notes, drafts, non-normative text

TIER_1_NORMAL

general docs, examples

TIER_2_IMPORTANT

test vectors, code modules, fixtures

TIER_3_CRITICAL

spec docs, manifests, release artifacts, node binaries

TIER_4_CONSTITUTIONAL

genesis, constitutional docs, mainnet release manifests, root registries

20.3 Rule

Higher tier => stricter admission checks, stronger signature requirements, stricter duplicate/supersession handling.

21. Signature and attestation layer for files

21.1 Need

Hashes protect integrity. Signatures protect provenance and approval.

21.2 Optional but recommended structure

ArtifactAttestation {
  artifact_id
  attestor_policy
  attestation_type
  signature_bundle
  issued_at
  scope_hash?
}

21.3 attestation types

• generated_by_pipeline
• reviewed
• approved_for_vault
• approved_for_release
• revoked
• superseded

21.4 Rule

Critical artifacts SHOULD require attestation before entering final vault or release class.

22. Manifest chain

22.1 Need

Un fișier singur este insuficient pentru securizarea întregului folder. Trebuie manifesturi care leagă loturile și stările folderului.

22.2 Manifest classes

• batch manifest
• folder manifest
• snapshot manifest
• release manifest
• revocation manifest

22.3 Batch manifest

BatchManifest {
  batch_id
  artifact_ids
  artifact_hashes_root
  created_at
  producer_policy?
  parent_manifest_ref?
}

22.4 Folder manifest

Reprezintă starea curentă a vault-ului sau a unui subset controlat.

22.5 Rule

Vault-ul SHOULD fi reconstruibil din manifest chain.

23. Append-only journal

23.1 Need

Pentru a preveni coruperea tăcută sau ștergerile invizibile, sistemul SHOULD ține jurnal append-only.

23.2 Journal entries

• file received
• file fingerprinted
• file canonicalized
• file admitted
• file quarantined
• file rejected
• file superseded
• file revoked
• manifest created
• snapshot created
• restore executed

23.3 Rule

Journal-ul MUST fi hash-chained.

23.4 Entry format

VaultJournalEntry {
  entry_id
  prev_entry_hash?
  entry_type
  artifact_id?
  manifest_id?
  timestamp
  event_hash
}

24. Hash chain and root anchoring

24.1 Need

Pentru a detecta coruperi sau rescrieri retroactive, jurnalul și manifesturile SHOULD forma lanț de integritate.

24.2 Journal chain

entry_hash_i = H("AZ:VAULT_JOURNAL:" || entry_i || entry_hash_{i-1})

24.3 Snapshot root

Periodic, sistemul SHOULD deriva:

vault_snapshot_root = H("AZ:VAULT_SNAPSHOT:" || manifest_root || journal_tip_hash || index_root)

24.4 Rule

Snapshot root SHOULD fi salvat în mai multe copii și, ideal, semnat.

25. Quarantine model

25.1 Quarantine reasons

• hash mismatch
• canonical mismatch
• duplicate conflict
• suspicious near-duplicate critical file
• type mismatch
• malformed structure
• signature failure
• broken manifest chain
• unexpected overwrite attempt
• policy failure

25.2 Rule

Quarantine is not deletion. It is containment.

25.3 Quarantine outcome

Fișierul poate fi:

• admitted after manual/automated review
• rejected permanently
• reclassified
• superseded
• archived as hostile/suspect sample

26. Recovery model for folder corruption

26.1 Need

Dacă folderul principal este corupt, sistemul trebuie să poată reveni la un checkpoint sigur.

26.2 Recovery inputs

• latest valid snapshot manifest
• journal tip up to trusted point
• chunk store
• artifact identity records
• attestation records if used

26.3 Recovery steps

1. select trusted snapshot
2. verify snapshot root
3. verify manifest chain
4. verify chunk roots for critical artifacts
5. rebuild indexes
6. compare current filesystem against reconstructed truth
7. quarantine mismatches
8. restore trusted vault view

26.4 Rule

Recovery MUST prefer verified older truth over newer unverified state.

27. Corruption detection model

27.1 Corruption classes

• byte corruption
• truncation
• hidden append
• metadata drift
• renamed shadow duplicate
• chunk loss
• manifest mismatch
• journal gap

27.2 Detection signals

• content_hash mismatch
• byte_size mismatch
• chunk root mismatch
• missing artifact in manifest
• orphan file
• artifact in index but absent on disk
• duplicate path with different identity

27.3 Rule

Any critical corruption signal MUST trigger:

• quarantine or freeze for affected scope
• snapshot verification
• audit event

28. Duplicate and anti-duplication controls

28.1 Exact duplicate policy

Do not store as new truth. Reference existing artifact_id.

28.2 Canonical duplicate policy

Require explicit alias or supersession rule.

28.3 Conflicting duplicate policy

If same normalized filename points to different artifact_id in critical tier:

• quarantine new file
• do not auto-replace
• require signed supersession

28.4 Near-duplicate critical documents

If near-duplicate of:

• genesis,
• constitutional docs,
• release manifests,
• protocol specs, the system SHOULD flag as suspicious and require manual/attested approval.

29. Anti-code-break protections

29.1 For source code and structured configs

Security machine SHOULD check:

• encoding validity
• no hidden control characters except allowed whitespace
• parser success where parser exists
• no truncation at EOF for classes requiring newline discipline
• manifest/dependency link consistency
• reproducible hash from canonical normalization policy

29.2 For binary/code artifacts

It SHOULD check:

• magic bytes if format-defined
• section lengths
• hash and signature
• referenced manifest inclusion
• forbidden debug/experimental flag mismatch in release class

29.3 Rule

A file that appears syntactically broken or structurally inconsistent MUST NOT enter release-tier vault.

30. Anti-silent-overwrite protections

30.1 Need

Overwriting is one of the easiest paths to accidental corruption.

30.2 Rule

The vault SHOULD enforce write-once semantics for admitted artifact objects. A new file does not overwrite old bytes. It creates:

• new artifact object
• optional supersession link

30.3 Critical classes

For TIER_3 and TIER_4, direct overwrite MUST be forbidden.

31. Policy for folder additions

31.1 Rule of entry

No process SHOULD place files directly into vault/. All additions MUST come through incoming/ and the admission machine.

31.2 Exceptions

None for critical artifacts. Even trusted producers SHOULD go through the same gate, maybe with extra attestation, not bypass.

31.3 Why

The moment you allow manual drops into vault, you lose chain of custody.

32. Vault indexes

32.1 Required indexes

• artifact_id -> path
• content_hash -> artifact_ids
• canonical_hash -> artifact_ids
• normalized_filename -> artifact_ids
• supersession graph
• manifest membership
• attestation index
• quarantine reason index

32.2 Rule

Indexes are derived views. They MUST be rebuildable from vault truth, not the other way around.

33. Snapshot policy

33.1 Snapshot classes

• rolling snapshots
• release snapshots
• constitutional snapshots
• pre-recovery snapshots
• post-recovery snapshots

33.2 Rule

Critical milestones SHOULD trigger forced snapshot creation.

33.3 Minimum triggers

• admission of genesis
• admission of release manifest
• admission of constitutional doc revision
• large batch import
• before and after recovery

34. Release-grade protection

34.1 Critical release artifacts

• genesis file
• release binary
• release manifest
• conformance corpus official version
• governance bootstrap package
• initial validator set package

34.2 Must-have protections

• strict policy class
• attestation required
• manifest inclusion required
• snapshot after admission
• duplicate conflict hard-fail
• overwrite forbidden
• off-folder backup copies
• integrity verification on read/use

35. Read-time verification

35.1 Need

Protection only at write-time is insufficient.

35.2 Rule

Critical artifacts SHOULD be reverified on read/use:

• hash check
• size check
• manifest membership
• attestation presence
• snapshot consistency if required

35.3 Use cases

• before loading genesis
• before signing release
• before using node binary
• before replaying conformance corpus

36. Security machine decision function

36.1 Abstract function

EvaluateArtifactAdmission(File F, Context C) ->
  ADMIT |
  ADMIT_WITH_ATTESTATION |
  STAGE_ONLY |
  QUARANTINE |
  REJECT |
  SUPERSEDE_EXISTING

36.2 Inputs

• raw bytes
• normalized filename
• declared artifact class
• producer identity if present
• manifest context
• policy tier
• duplicate/supersession state
• current vault roots

36.3 Rule

For critical artifacts, ADMIT_WITH_ATTESTATION or stronger SHOULD be the default, not plain ADMIT.

37. Audit trail for every file

37.1 Minimal audit fields

For every admitted file, system SHOULD retain:

• artifact_id
• ingress timestamp
• admission timestamp
• original and normalized filename hashes
• producer identity if known
• policy class used
• verdict
• manifest membership
• supersession links
• snapshot membership

37.2 Rule

If a file exists in vault without audit trail, vault integrity is compromised.

38. Threat model for file vault

38.1 Threats addressed

• accidental corruption
• duplicate proliferation
• silent overwrite
• format confusion
• hidden rename collision
• manifest drift
• chunk loss
• incomplete recovery
• release artifact substitution
• shadow spec/code versioning confusion

38.2 Threats reduced but not eliminated

• malicious signer
• compromised host OS
• deliberate insider with vault write permissions and key access
• cryptographic break

38.3 Rule

Vault security is layered integrity and process discipline, not magic immunity.

39. Anti-patterns

System designers SHOULD avoid:

1. storing truth by filename only
2. manual copy directly into vault
3. deleting old artifacts instead of superseding them
4. single flat folder with no quarantine/staging
5. no manifest chain
6. no chunk hashes for large files
7. no read-time verification
8. hidden metadata changes with same identity
9. allowing exact duplicate critical files under different names without linkage
10. treating backup copies as trusted without re-verification

40. Formal goals

AZ-018 urmărește aceste obiective:

40.1 Artifact integrity

Orice fișier admis poate fi verificat byte-for-byte și chunk-for-chunk.

40.2 Artifact uniqueness control

Duplicatele și supersession-urile sunt controlate explicit, nu accidental.

40.3 Admission soundness

Niciun fișier corupt sau nevalid nu intră în vault ca adevăr oficial.

40.4 Recoverable vault truth

Starea vault-ului poate fi reconstruită din manifesturi, jurnal și snapshots verificate.

41. Formula documentului

Secure Artifact Vault = content-addressed identity + admission gate + canonical manifests + hash-chained journal + quarantine + snapshot-based recovery

42. Relația cu restul suitei

• AZ-016 definește genesis.
• AZ-017 definește readiness pentru mainnet.
• AZ-018 definește cum păstrăm toate artefactele proiectului fără corupere, duplicare haotică sau pierdere de trasabilitate.

Pe scurt: dacă suitea anterioară definește protocolul, AZ-018 definește cum păstrezi corpul protocolului viu fără să-l lași să se degradeze în fișiere necontrolate.

43. Ce urmează

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

1. AZ-019 — Concrete Vault Manifest Schema
2. AZ-020 — Artifact Signing and Attestation Policy
3. AZ-021 — Secure Build and Release Pipeline
4. AZ-022 — Concrete Genesis Package
5. AZ-023 — Reference Implementation Milestone Map
6. AZ-024 — Conformance Corpus Concrete Layout

Închidere

Un folder obișnuit păstrează fișiere. Un vault păstrează adevăr verificabil despre fișiere.

Diferența este exact aceasta: fiecare artefact are identitate, traseu, verificare, carantină, manifest și posibilitate de recovery. Fără asta, proiectul se poate pierde prin corupere tăcută, copii confuze și suprascrieri aparent nevinovate.

Acolo începe protecția reală a artefactelor.