Files
ModelForge/docs/architecture/adr/0043-artifact-rehydration-and-dr-boundaries.md

38 lines
1.9 KiB
Markdown

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