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