Backup existence is not restore evidence
A recent file can be incomplete or unreadable. Observability separates successful job completion, archive freshness, size, and restore-verification results. An untested backup should not be labeled recoverable solely because its timestamp is recent.
Destructive boundaries
Adoption never formats a disk or replaces existing data. Restoration is explicit and scoped. Copying an entire baseline over a running machine risks reverting unrelated updates and credentials, so missing-file recovery and targeted rollback are distinct mechanisms.
Failure ordering
If the tunnel fails, GitHub cannot perform normal SSH repair. If the host fails, the portal cannot serve diagnostics. Cloud history and the independently hosted wiki remain useful, but neither substitutes for a LAN or console recovery path.
Stale evidence
A collector may continue exporting an old success or failure. Compare the collection timestamp with the job timestamp and cloud-object evidence. Keep failed outcomes distinct from absent metrics, and never infer restore success from a nonzero archive size.
Evidence and failure semantics
A backup upload never establishes full restoration. A passing restore requires archive integrity, isolated-network verification, real restored data and representative application behavior. Invalid or missing evidence, expired timestamps, or a changed deployment yield unverified status; a failed attempted recovery is a failure. A current deployment observation must be younger than twenty minutes. Scoring weights, category thresholds, system membership and availability-history requirements are unchanged. Missing application log streams stay unverified, even if an error query is empty.
Rollback and acceptance
Stop the recovery timer to pause new drills; existing encrypted backups and production applications remain intact. Revert the scoped collector/recovery release through the validated deployment workflow. A successful rollout requires actual fleet health of at least 70 percent twice, fifteen minutes apart, healthy endpoints and no unexpected production process changes. Qwen request logging uses the existing idle-gated update and rollback procedure; only the wrapper is restarted after a verified idle interval, while Ollama remains running.
The 76-percent improvement acceptance uses two fresh actual fleet readings at least fifteen minutes apart, with no dip below the target during observation. Independent production ingestion freshness can reduce the fleet score even when every new recovery drill passes. Never relax that freshness contract to meet the target.
Raspberry backup boundary
The dedicated key can invoke only revision or archive on /usr/local/sbin/observe-raspberry-export. Its known host key is pinned. A narrow sudoers entry permits these fixed operations; arbitrary commands, tunnels and PTYs are not permitted. Required members include boot config/cmdline, fstab, os-release, readsb runtime/service and dpkg status. Corrupt, missing or changed snapshots cannot pass readiness. No Raspberry restore method is registered, so archive verification never awards isolated-restore credit. The required Raspberry repositories were not resolvable during implementation; this operations runbook records the cross-host mechanism without substituting it for those repositories.
Recovery proof boundaries
The Cloudflare test uses actual deployed code and nonempty restored state, with a duplicate replay chosen to avoid initiating new AI review or production side effects. Its scope is therefore public-feed serving and restored duplicate handling for the three active shards. Inactive shards, new-article AI review, complete website restoration, workload performance and production freshness remain separate obligations. Readiness is recorded only after encrypted off-host round-trip verification; restore success additionally requires application assertions. A changed revision, corrupt archive, unsupported dependency or failed assertion remains a failed or unverified result.
Long-running evidence collection
Deployment identity is an observation, not restoration proof. Refreshing it every five minutes during a long transfer prevents unrelated valid drills from appearing stale while preserving the original verification time, eight-day expiry, current-revision comparison and score weights. The timer permits one probe at a time and evidence writes are serialized.