# 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.