1.4 KiB
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.