32 lines
1.4 KiB
Markdown
32 lines
1.4 KiB
Markdown
# ADR-0008: Separate content identity from node-scoped storage location
|
|
|
|
## Status
|
|
|
|
Accepted — 2026-08-25
|
|
|
|
## Context
|
|
|
|
The M0 schema stored one `storage_uri` directly on an artifact and one source directly on a derived
|
|
artifact. Operational registry use requires replicas, missing locations, remote-only metadata and
|
|
transformations with multiple inputs. Treating a path as identity would make moves look like new
|
|
artifacts and would weaken provenance.
|
|
|
|
## Decision
|
|
|
|
Artifact content identity is the exact revision plus SHA-256. `ArtifactLocation` associates content
|
|
with a node-scoped `StorageRoot` and relative path. A derived output has ordered N-source lineage with
|
|
captured source hashes. Storage capacity is observed and placement fails closed when unknown or when
|
|
reserve policy would be crossed.
|
|
|
|
Legacy `storage_uri` and primary-source columns remain nullable migration compatibility fields in M2;
|
|
new services never use them as identity.
|
|
|
|
## Consequences
|
|
|
|
- replicas and moves do not change content identity;
|
|
- missing/corrupt state is location-aware and auditable;
|
|
- delete checks can name exact provenance/location dependencies;
|
|
- remote compute storage can be configured without exposing workers publicly;
|
|
- later download/runtime milestones can consume this boundary without redesigning the registry;
|
|
- the additional joins are deliberate and preferable to provenance ambiguity.
|