# ADR-0043: Artifact rehydration and disaster-recovery boundaries

## Status

Accepted in M15 on 2026-08-27.

## Decision

Recover rehydratable artifacts by redownloading their exact upstream revision through the existing
acquisition plane — download plan, quarantine, hash verification against provenance, atomic
promotion — rather than by copying weights into every backup. A floating revision is never used, and
an artifact set without both an upstream repository and a resolved commit is classified
`NON_REHYDRATABLE` and requires a payload backup.

Treat a rehydrated artifact as new material: it re-enters quarantine, is re-checked against the
security policy, keeps `trust_remote_code=false` and carries
`static_checks_passed_unapproved` rather than inheriting its predecessor's approval.

Draw the disaster-recovery boundary explicitly. ModelForge restores only into a database that is not
its own, never writes to ExampleRAG, ExampleVision, Ollama, Plex, Tdarr or Gitea, and does not claim to
protect its own Git host. Restore execution against a production target requires an explicit mode
and an explicit deployment flag; the destructive half of recovery lives in the operator CLI and
runbooks rather than in a remote API call.

## Consequences

Backups stay small and fast while a 247 MB artifact set was recovered in 24.2 seconds with all seven
digests matching provenance, into a disposable location, leaving the 75 production artifact
locations untouched.

Recovery cannot be used to launder an unapproved artifact into an approved one, and an unreachable
upstream produces `ARTIFACT_REHYDRATION_BLOCKED` instead of a false claim that the platform is
recovered.

The boundary is a real constraint: a genuine loss of a non-rehydratable or derived artifact needs a
payload backup that must be configured deliberately, and full protection of the Git host remains
platform operations rather than a ModelForge feature.