60 / ARTIFACT STORE / PRODUCTION FABRIC
60 / PRODUCTION / BLOBS · REFERENCES · VERSIONED OUTPUTS · DURABLE FILES

ARTIFACT
STORE.

Artifact Store — долговременное хранилище крупных или файловых результатов AI-системы: документов, изображений, аудио, архивов, datasets, generated reports, sandbox outputs, parsed page images, model-generated files, evaluation bundles и других binary/text artifacts.

Главный принцип: state, memory и queue не должны превращаться в файловую помойку. Крупный результат хранится как artifact, а остальные компоненты передают стабильную ссылку artifact_ref + version/hash/metadata.
00. ARCHITECTURAL STATUS

ПОЯВЛЯЕТСЯ, КАК ТОЛЬКО СИСТЕМА НАЧИНАЕТ ПРОИЗВОДИТЬ ФАЙЛЫ И КРУПНЫЕ ОБЪЕКТЫ

Для text-only локального прототипа можно начать с обычной директории. Для production нужны stable references, checksums, tenant isolation, upload/download lifecycle, retention, access control и separation between metadata and bytes.
TYPEPRODUCTIONDurable blob/object storage layer.
DEFAULTCONDITIONALНужен, когда есть files/big outputs.
ENABLE WHENARTIFACTS EXISTDocs/images/audio/archives/reports/datasets.
SEPARATE COMPONENTYESMetadata and bytes lifecycle deserve own boundary.
LIVES INPRODUCTION FABRICShared supporting infrastructure.
COMPLEXITYLOW → MEDIUMFilesystem → object storage + metadata DB.
IMPLEMENT: AS SOON AS FILES MATTER
Минимум 80% ценности: immutable-ish artifact IDs, content hash, tenant/owner, MIME/type/size, object path/key hidden behind artifact_ref, upload finalize step, access checks, retention/delete state, derived-from metadata, signed/authorized download path и orphan cleanup. Не нужен отдельный AI-agent: это deterministic storage service.
01A. ARCHITECTURE BOUNDARIES & OPERATIONS

EXPLICIT SYSTEM CONTRACT

A. BOUNDARY WITH NEIGHBORS

№10 State Management хранит текущую операционную позицию процесса; Artifact Store хранит durable files/large outputs. №07 Memory хранит retained facts/preferences/episodes; artifact может быть источником/attachment, но не memory semantics. №55 Ingestion & Sync отслеживает source objects/version/checkpoints; №60 может хранить fetched raw blobs. №56 Document Parsing создаёт derived artifacts: page images, tables, IR bundles. №57 Queue передаёт artifact refs вместо giant payloads. №61 Provenance/Lineage владеет полным origin/transform graph; №60 хранит минимальные parent/source references и immutable object identity.

B. PREREQUISITES / CROSS-REFERENCES

Prerequisites: №10 State, №46 Observability, №50 Contracts, №51 Permissions & Secrets, №55 Ingestion, №56 Parsing, №57 Queues. Forward references: №61 Provenance/Lineage, №62 Caching, №63 Retry, №66 Vector DB/Embeddings, №76 Data Governance & Privacy.

C. PLANE PLACEMENT

REQUEST-TIME: YES — upload/download/fetch artifact refs. CONTROL PLANE: retention classes, access policies, storage classes, quotas, lifecycle state. DATA PLANE: bytes/objects and artifact metadata. OFFLINE: garbage collection, integrity scan, migration, lifecycle transitions, backup/restore tests.

D. FAILURE & OPERATIONS CONTRACT

Success: bytes are durably stored, integrity verified, metadata committed, artifact_ref resolvable under access policy. Retryable: transient upload/object-store/network failures. Permanent: forbidden type/size, access deny, invalid checksum, unsupported storage class. Idempotency: finalize by artifact_id/upload_id/content hash. Persist: artifact metadata, state, object key, checksum, owner/tenant, source/parent refs, retention. Trace: create→upload→verify→finalize→read/delete. Security: raw object keys/credentials never grant cross-tenant access.

E. WHAT THIS TOPIC DOES NOT OWN

№60 не владеет domain meaning of files, knowledge indexing, memory semantics, process state, provenance graph, backup strategy for every database or user-facing file manager. Она владеет DURABLE STORAGE, IDENTITY, INTEGRITY, ACCESS AND LIFECYCLE OF ARTIFACT OBJECTS.

01. WHAT COUNTS AS AN ARTIFACT?

НЕ ТОЛЬКО «ФАЙЛ, КОТОРЫЙ СКАЧИВАЕТ USER»

SOURCE BLOB

Raw input

PDF, DOCX, image, audio, archive fetched by ingestion.

DERIVED FILE

Processing output

Page images, extracted tables, normalized JSON bundles, thumbnails.

GENERATED OUTPUT

User-facing result

Report, spreadsheet, HTML, PDF, presentation, exported dataset.

SANDBOX OUTPUT

Execution artifact

Logs, generated code, archives, plots, build/test output.

MODEL MEDIA

Image/audio/video

Generated or transformed multimodal outputs.

EVAL BUNDLE

Evidence of run

Trace exports, scorer outputs, snapshots, regression reports.

CHECKPOINT

Large serialized state

Only when state is intentionally externalized as a blob; metadata remains elsewhere.

CACHE SOURCE

Reusable immutable data

Artifact may later be cached/referenced, but cache semantics belong to №62.

02. ARTIFACT REF

ВНУТРИ СИСТЕМЫ ПЕРЕДАВАТЬ REFERENCE, НЕ STORAGE PATH

PRODUCER

Creates artifact / upload intent.

Does not expose bucket/path details to model.

ARTIFACT STORE

Stores bytes + metadata, returns artifact://tenant_A/....

CONSUMER

Uses artifact_ref via authorized resolver/download API.

Storage implementation может измениться: local filesystem → S3-compatible storage → cloud object storage. Stable artifact_ref позволяет не менять prompts/jobs/workflows.
03. ARTIFACT METADATA CONTRACT

BYTES БЕЗ METADATA — ПЛОХОЙ SYSTEM OBJECT

{
  "artifact_ref": "artifact://tenant_A/01J...",
  "artifact_id": "01J...",
  "tenant_id": "tenant_A",
  "owner_ref": "task://...",
  "kind": "DOCUMENT",
  "mime_type": "application/pdf",
  "filename": "report.pdf",
  "bytes": 1842230,
  "sha256": "sha256:...",
  "state": "READY",
  "storage_class": "STANDARD",
  "created_at": "...",
  "expires_at": null,
  "source_ref": "doc://...",
  "parent_artifacts": [
    "artifact://tenant_A/raw-..."
  ],
  "metadata": {
    "pages": 42
  }
}
MINIMUM FIELDS

Enough to operate safely

  • artifact_id/ref;
  • tenant/owner;
  • kind/MIME;
  • size;
  • content checksum;
  • state;
  • storage class/key internally;
  • created/expires timestamps;
  • source/parent refs;
  • optional user filename.

Filename не должен быть primary identity.

04. ARTIFACT STATE MACHINE

UPLOAD И READY — РАЗНЫЕ СОСТОЯНИЯ

ALLOCATED
   ↓
UPLOADING
   ├─ abort/timeout ─────→ ABORTED
   ↓
UPLOADED
   ↓ verify size/hash/type
VERIFYING
   ├─ mismatch ─────────→ REJECTED
   ↓
READY
   ├─ lifecycle expiry ─→ EXPIRED
   ├─ explicit delete ──→ DELETING
   └─ quarantine ───────→ QUARANTINED
                             ↓
                           READY / DELETING

DELETING
   ↓
DELETED / TOMBSTONED
Consumer получает artifact только в разрешённом состоянии, обычно READY. Нельзя считать «upload HTTP 200» достаточным proof, что object verified/finalized.
05. TWO-PHASE UPLOAD

ALLOCATE → UPLOAD → FINALIZE

CREATE INTENTExpected type/size/tenant/owner.
UPLOAD TARGETScoped upload URL/path/token.
UPLOAD BYTESClient/worker writes object.
VERIFYExists, size, checksum, content policy.
FINALIZEMetadata state → READY.
RETURN REFConsumers receive stable artifact_ref.
Для маленькой локальной системы phases могут быть одной функцией. Но conceptual split полезен: incomplete uploads и finalized artifacts не смешиваются.
06. IMMUTABILITY & VERSIONING

ЛУЧШЕ СОЗДАТЬ НОВЫЙ ARTIFACT, ЧЕМ ТИХО ПЕРЕПИСАТЬ СТАРЫЙ

IMMUTABLE BYTES

Strong default

После READY содержимое artifact_id не меняется. Новый результат → новый artifact_id.

MUTABLE METADATA

Operational fields

Lifecycle state, labels, retention, scan status могут меняться versioned/audited способом.

ALIAS / LATEST

Human convenience

Если нужен «latest report», хранить alias/pointer отдельно, а не перезаписывать bytes старого artifact.

Immutable artifacts упрощают provenance, caching, reproducibility, retries, audits и comparison. Content-addressed storage становится возможным, но не обязательным.
07. CONTENT HASH

CHECKSUM НУЖЕН ДЛЯ INTEGRITY, DEDUPE И REPRODUCIBILITY

INTEGRITY

Bytes unchanged

Проверить object after upload/download/migration.

DEDUPE

Optional optimization

Одинаковые bytes могут физически храниться once, но logical artifact identity/provenance остаются раздельными.

CACHE KEY

Derived processing

Parser/thumbnail/embedding may reuse result if source hash + pipeline version match.

AUDIT

Exact evidence

Можно доказать, какой exact file участвовал в run.

Hash не заменяет access control и provenance. Два tenants могут иметь одинаковые bytes, но это не означает общий доступ или общую logical identity.
08. STORAGE KEY VS ARTIFACT ID

НЕ ДЕЛАТЬ BUCKET PATH ЧАСТЬЮ PUBLIC CONTRACT

PUBLIC:
artifact://tenant_A/01JABC...

INTERNAL METADATA:
artifact_id = 01JABC...
storage_backend = object_store_1
object_key =
  tenants/tenant_A/2026/08/01JABC...

DON'T EXPOSE AS PRIMARY CONTRACT:
s3://bucket-prod-eu-1/
  tenants/tenant_A/.../report.pdf
WHY ABSTRACTION

Storage can move

Backend/path может измениться из-за:

  • migration;
  • storage tiering;
  • region/data residency;
  • encryption strategy;
  • filesystem → object storage;
  • backup restore.

Artifact resolver скрывает эти изменения от AI/core.

09. DERIVED ARTIFACTS

ОДИН SOURCE МОЖЕТ ПОРОДИТЬ МНОГО ВЕРСИОНИРОВАННЫХ OUTPUTS

RAW PDF artifact://raw/123 DOCUMENT IR parser=v3 / source_hash=... PAGE IMAGES derived from raw TABLE EXPORT derived region/page FINAL REPORT uses multiple artifacts
№60 хранит parent/source refs на минимальном уровне. Полную derivation graph, claim lineage и evidence chain системно раскрывает №61 Provenance / Lineage.
10. ARTIFACT VS STATE VS MEMORY

ТРИ РАЗНЫХ КЛАССА ДАННЫХ

LayerOwnsExample
STATECurrent operational reality.Job RUNNING, workflow step 4, current cursor.
MEMORYRetained facts/experience for future reasoning.User preference, verified lesson, prior case.
ARTIFACTDurable file/blob/output object.PDF report, image, raw source blob, export archive.
Artifact может быть referenced by State или Memory, но это не делает file itself operational state or cognitive memory.
11. LARGE OUTPUT PATTERN

МОДЕЛЬ / WORKER ВОЗВРАЩАЕТ REF, НЕ 50 MB PAYLOAD

WORKER / MODELProduces large result.
WRITE ARTIFACTUpload/finalize bytes.
RETURN REFartifact_ref + metadata.
STATE / JOBStores only reference.
DOWNSTREAMAuthorized consumer resolves reference.
Так queue, database rows, event messages и model context остаются маленькими. Это особенно важно для retries и long-running workflows.
12. SIGNED ACCESS / AUTHORIZED RESOLUTION

ARTIFACT REF НЕ ДОЛЖЕН БЫТЬ PUBLIC URL НАВСЕГДА

RESOLVE

Check principal

Service receives artifact_ref + current principal/tenant, verifies read permission.

TEMP ACCESS

Short-lived URL/token

После authorization можно выдать time-limited access to object.

SERVICE READ

Internal capability

Workers/tools read through trusted client using artifact_ref, not model-provided raw bucket key.

Artifact ID может быть stable, download capability — short-lived and scoped.
13. SECURITY & TENANCY

ФАЙЛОВОЕ ХРАНИЛИЩЕ — ОДНА ИЗ САМЫХ ОПАСНЫХ DATA BOUNDARIES

TENANT

Strict scope

artifact_ref resolution binds tenant/owner; raw object key alone is not authorization.

UPLOAD TYPE

Validate

Expected size/type/content policy; do not trust filename extension.

PATH

No traversal

Storage keys generated host-side; no arbitrary user filesystem paths.

ENCRYPTION

At rest / transit

Use storage/platform encryption appropriate to deployment and data class.

MALWARE / ACTIVE

Quarantine path

Executable/complex file types may require scan or restricted downstream handling.

PROMPT INJECTION

Trust preserved

Stored external document remains untrusted content even after upload/parse.

LOGS

No secrets

Do not log signed URLs, storage credentials or sensitive content unnecessarily.

DELETE

Governance

Deletion/retention behavior must align with №76 privacy/governance.

14. RETENTION CLASSES

НЕ ВСЕ ARTIFACTS НУЖНО ХРАНИТЬ ОДИНАКОВО ДОЛГО

CLASS
TTL
EXAMPLE
REPRODUCIBILITY
COST
POLICY
EPHEMERAL
hours/days
temp sandbox output
low need
LOW
auto-expire
WORKING
days/weeks
draft exports
medium
LOW-MED
task/project lifecycle
DURABLE
months+
final report/source evidence
high
MED
retention policy
REGULATED
policy-defined
compliance/audit artifacts
very high
HIGH
legal/governance controls
Retention is a control-plane property. Artifact Store executes lifecycle, but rules come from product/governance/data policy.
15. DELETE SEMANTICS

«DELETE» МОЖЕТ ИМЕТЬ НЕСКОЛЬКО УРОВНЕЙ

StageMeaning
ACCESS REVOKEDArtifact becomes inaccessible immediately to normal consumers.
LOGICAL DELETEMetadata state marks DELETING/DELETED; references no longer resolve.
PHYSICAL DELETEObject removed from primary storage.
DERIVED CLEANUPThumbnails/parsed outputs/caches/indexed derivatives removed or tombstoned.
BACKUP EXPIRYBackup copies age out according to backup/governance policy.
Для privacy-sensitive data важно различать user-visible deletion, primary object deletion и eventual backup retention.
16. ORPHAN CLEANUP

НЕЗАВЕРШЁННЫЕ UPLOADS И БЕЗХОЗНЫЕ OBJECTS НАКАПЛИВАЮТСЯ САМИ

ABANDONED UPLOAD

Allocated but never finalized

TTL cleanup removes temp objects after safe window.

ORPHAN OBJECT

Bytes without metadata

Periodic inventory compares storage objects with metadata DB.

ORPHAN METADATA

Metadata points to missing bytes

Integrity scan marks CORRUPT/MISSING and triggers repair/restore path.

Garbage collection должна быть conservative. «Не вижу reference» не всегда означает, что artifact можно удалить: retention/legal hold may override reachability.
17. STORAGE CLASSES & TIERING

ГОРЯЧИЕ И РЕДКО ИСПОЛЬЗУЕМЫЕ ARTIFACTS МОГУТ ЖИТЬ ПО-РАЗНОМУ

HOT

Fast access

Recent/source artifacts needed frequently by active tasks and RAG pipelines.

WARM

Lower cost

Historical outputs used occasionally.

ARCHIVE

Slow restore

Long-term audit/reproducibility artifacts where latency can be high.

Tiering should not change artifact_ref. Resolver/storage metadata handles backend class transparently.
18. BACKUP & DURABILITY

OBJECT STORE DURABILITY И APPLICATION RECOVERY — РАЗНЫЕ ВЕЩИ

OBJECT DURABILITY

Storage guarantee

Underlying filesystem/object store protects bytes against hardware failure.

METADATA BACKUP

Refs matter

Without artifact metadata DB, durable bytes may become unaddressable.

RESTORE

Test it

Recovery must restore metadata/object relation and integrity.

REGION

Disaster domain

Replication strategy depends on RTO/RPO, data residency and cost.

Не обещать «backup есть», пока restore path не тестировался на реальных metadata + object references.
19. ARTIFACT STORE & CACHING

IMMUTABLE ARTIFACT МОЖЕТ БЫТЬ CACHE INPUT, НО STORE ≠ CACHE

ARTIFACT STORE

Durable object identity

Artifact должен существовать согласно lifecycle/retention, даже если nobody requested it recently.

№62 CACHE

Disposable acceleration

Cache entry можно удалить в любой момент; correctness should survive miss.

Если удаление entry ломает business record или теряет единственную копию report/source, это не cache — это storage.
20. OBSERVABILITY

СМОТРЕТЬ НА STORAGE КАК НА LIFECYCLE, НЕ ТОЛЬКО GB

COUNT

Objects

Artifact count by state/type/tenant/storage class.

BYTES

Storage volume

Total/current growth by tenant/type/class.

UP

Upload success

Create/upload/finalize success and latency.

HASH

Integrity mismatch

Checksum failures and missing object rate.

DL

Read latency

Resolve/download latency and error rate.

TTL

Lifecycle

Expired/deleting/orphan backlog.

DENY

Access

Authorization denies and cross-tenant attempts.

COST

Storage + egress

Cost by bytes, requests, transfer, storage tier.

21. TESTING

ХРАНИЛИЩЕ НУЖНО ЛОМАТЬ В ТЕСТАХ

HASH

Corrupt upload

Checksum mismatch prevents READY state.

PARTIAL

Interrupted upload

Abandoned object not visible as finalized artifact.

TENANT

Isolation

Tenant A cannot resolve/read tenant B artifact by guessed ID.

DELETE

Lifecycle

Expired/deleted artifact stops resolving and derivatives follow policy.

MISSING

Object loss

Metadata exists, bytes missing → explicit integrity error, not empty file.

MIGRATE

Backend move

Artifact refs remain stable across storage backend migration.

RESTORE

Recovery

Backup restore reconstructs metadata-object relationship.

ORPHAN

Cleanup

GC removes only safe abandoned objects, respects holds/retention.

22. FAILURE MODES

КАК ARTIFACT STORE ЛОМАЕТСЯ

FILES IN DB ROWS
Large binary payloads inflate transactional DB, queues, backups and retries.
OBJECT STORAGE + REFS
PATH = IDENTITY
Migration/tiering/rename breaks contracts.
STABLE ARTIFACT REF
OVERWRITE READY FILE
Provenance/reproducibility silently changes.
NEW ARTIFACT VERSION
NO HASH
Corruption/duplicate/reproducibility problems are invisible.
CONTENT CHECKSUM
PUBLIC PERMANENT URL
Access becomes bearer-link based and hard to revoke.
AUTHORIZED RESOLVE
QUEUE CARRIES BLOBS
Retries and transport become huge/fragile.
ARTIFACT REFERENCES
STORE = MEMORY
Files are mistaken for durable learned knowledge.
SEPARATE SEMANTICS
DELETE PRIMARY ONLY
Derived artifacts/index/caches keep sensitive data alive.
LIFECYCLE GRAPH
NO ORPHAN GC
Abandoned uploads slowly consume storage forever.
RECONCILE + TTL
23. METRICS

ЧТО ИЗМЕРЯТЬ

GB

Stored Bytes

Total bytes and growth by tenant/type/class.

UP

Finalize Success

Artifact uploads reaching READY successfully.

P95

Read Latency

Resolve/download latency by storage class.

INT

Integrity Fail

Hash mismatch/missing-object rate. Target near zero.

ORP

Orphan Rate

Abandoned objects/metadata awaiting cleanup.

TTL

Lifecycle Lag

Expired items not yet transitioned/deleted.

DEN

Access Deny

Unauthorized resolution attempts and policy rejects.

COST

Cost per Artifact

Storage/request/egress cost by workload class.

24. MVP IMPLEMENTATION

ЛОКАЛЬНАЯ ДИРЕКТОРИЯ + POSTGRES УЖЕ МОЖЕТ БЫТЬ НОРМАЛЬНЫМ НАЧАЛОМ

artifact_store/
├── service.py
├── metadata.py
├── resolver.py
├── checksum.py
├── lifecycle.py
├── cleanup.py
└── tests/

artifacts(
  artifact_id       uuid primary key,
  tenant_id         text,
  owner_ref         text,
  kind              text,
  mime_type         text,
  filename          text,
  bytes             bigint,
  sha256            text,
  state             text,
  backend           text,
  object_key        text,
  storage_class     text,
  source_ref        text,
  expires_at        timestamptz,
  created_at        timestamptz,
  updated_at        timestamptz
)

filesystem MVP:
  /data/artifacts//

later:
  swap backend to S3-compatible
  without changing artifact_ref
80% VALUE MVP

Boring durable storage

  • PostgreSQL metadata table.
  • Local directory or S3-compatible object storage.
  • Generated artifact_id/ref.
  • Host-generated object key.
  • Size + SHA-256 integrity.
  • READY state only after finalization.
  • Tenant/owner authorization on resolve.
  • Parent/source refs.
  • TTL/retention fields.
  • Orphan cleanup/reconciliation.

Не нужен отдельный microservice initially — module + DB + storage backend вполне достаточно.

25. WHEN TO UPGRADE

РАСШИРЯТЬ ПО МЕРЕ РЕАЛЬНЫХ ТРЕБОВАНИЙ

SignalPotential upgrade
Large multi-node deploymentShared object storage instead of local filesystem.
High download volumeCDN/edge delivery with signed URLs and strict auth boundary.
Regulated dataKey management, legal hold, retention policies, regional placement.
Very large archivesMultipart upload, tiered storage, lifecycle rules.
Cross-region disaster recoveryReplication/backup strategy matched to RPO/RTO.
Complex derivation graphDedicated provenance/lineage layer — №61.
26. PRACTICAL DECISION

СТОИТ ЛИ ДЕЛАТЬ ОТДЕЛЬНЫЙ КОМПОНЕНТ?

ВопросОтвет
Стоит ли реализовывать?Да, как только система хранит/передаёт файлы и крупные outputs. Для purely textual prototype — можно отложить.
Separate Component?YES как storage responsibility. Физически initially может быть module + filesystem/object store + Postgres metadata.
Минимум 80% ценности?Stable artifact_ref, immutable bytes, metadata, checksum, tenant authorization, finalize lifecycle, retention/delete, parent refs, orphan cleanup.
Когда overkill?Строить multi-region object platform, CDN, archival tiers и legal-hold engine для десятка локальных файлов.
Trigger?System outputs or consumes files/blobs large enough that DB rows/messages/context should carry references instead.
Как измерить uplift?Storage failures, giant-payload incidents, reproducibility, upload/download reliability, integrity failures, orphan rate, storage cost, time to retrieve exact output.
Можно ли rule/tool/code вместо LLM-agent?Полностью. Artifact storage is deterministic infrastructure. AI may generate artifact contents, but never owns storage integrity/access semantics.
27. DESIGN RULES

ПРАВИЛА ДЛЯ РЕАЛЬНОЙ СИСТЕМЫ

RULE 01

Store bytes, pass refs

Queues, events, state and prompts carry artifact_ref.

RULE 02

Artifact ID ≠ path

Stable logical identity hides backend/storage layout.

RULE 03

Ready only after verify

Upload completed is not finalized until integrity checks pass.

RULE 04

Prefer immutable bytes

New content → new artifact; aliases/pointers represent latest.

RULE 05

Checksum everything important

Integrity and reproducibility need content hash.

RULE 06

Resolve with authorization

Stable ref does not equal permanent public access.

RULE 07

Retention is explicit

TTL, durable, regulated and legal-hold classes differ.

RULE 08

Delete derivatives too

Lifecycle propagates to parsed/cache/index outputs according to policy.

RULE 09

Start simple

Filesystem + Postgres metadata is valid until shared/object storage requirements appear.

28. FINAL MAP

DURABLE OUTPUTS NEED DURABLE IDENTITY

USER / CONNECTOR / WORKER / MODEL / SANDBOX
        ↓
PRODUCES FILE / BLOB / LARGE OUTPUT
        ↓
CREATE ARTIFACT INTENT
  artifact_id
  tenant
  owner
  expected kind/type/size
        ↓
UPLOAD / WRITE BYTES
        ↓
VERIFY
  exists
  size
  hash
  type/policy
        ↓
FINALIZE
        ↓
ARTIFACT = READY
        ↓
RETURN STABLE
  artifact://tenant/.../id
        ↓
OTHER COMPONENTS STORE ONLY REF
  queue
  workflow state
  event
  memory attachment
  provenance
  report metadata
        ↓
AUTHORIZED RESOLUTION
        ↓
DOWNLOAD / PROCESS / DERIVE

DERIVED ARTIFACTS:
  raw source
    ├─ parsed IR
    ├─ page images
    ├─ table exports
    └─ final report

LIFECYCLE:
  retention
  expire
  quarantine
  delete
  orphan cleanup
  restore

BOUNDARIES:

STATE
  = current operational reality

MEMORY
  = retained knowledge / experience

ARTIFACT STORE
  = durable files / blobs / outputs

PROVENANCE
  = how those artifacts and facts
    were derived from one another

CORE PRINCIPLE:

IF AN OBJECT IS LARGE,
FILE-LIKE,
REUSABLE,
DOWNLOADABLE,
OR NEEDED FOR REPRODUCIBILITY—

STORE IT AS AN ARTIFACT,
GIVE IT A STABLE ID,
VERIFY ITS BYTES,
CONTROL ITS ACCESS,
AND PASS REFERENCES
EVERYWHERE ELSE.

ECC RETROFIT / PRACTICAL HARNESS INTEGRATION

A. Related ECC ideas. Context-as-cache, scoped memory, lifecycle hooks, selective capabilities, feature flags, deterministic enforcement, provider-neutral adapters and eval-gated learning are applied only where relevant to №60 Artifact Store.

B–E. Existing boundary and placement. The existing conceptual boundary, class PRODUCTION, default ON and owner Working Memory + State + Production Fabric remain authoritative. Runtime/control/data/offline placement is unchanged; durable state stays outside model context.

F–H. Hooks and contracts. Use bounded PRE_MODEL/POST_MODEL, PRE_TOOL/POST_TOOL, CHECKPOINT and TASK_COMPLETED events as applicable. Illustrative fields and canonical contracts are defined in NEW_CONTRACTS_SPEC.md; no universal schema is implied.

I–J. Security and evaluation. Host-side schema, permission, secret, budget, idempotency and audit checks take precedence over LLM output. Optional mechanisms require a feature flag and WITH/WITHOUT ablation; measure quality, acceptance, correction, latency, cost, escalations and severe errors.

K–L. Task profiles and cross-references. A TaskProfile selects the relevant skill, tool/context slice, memory scope and enforcement profile independently from FAST/STANDARD/DEEP. See cross-reference map, hook spec and ablation plan. Provider adapters remain outside the core.