SovAIHub
ModulesSAI-200
SAI-200 table of contents
Concept2 min readContent reviewed

Offline build, update, and recovery

Make disconnected builds repeatable and design controlled updates, rollback, rebuild, backup, and recovery.

Last content review 2026-08-11Included in SAI-200

Make dependency closure testable

An offline build is repeatable only when every required input is available internally and network denial cannot cause a hidden fallback. Pin base images, packages, build tools, models, configuration, and build recipes by immutable identity, not by a name that could resolve differently at a later date.

Run a clean-room test with external name resolution and routes unavailable — do not accept "we believe this would work offline" as evidence. Record build inputs, environment, output identity, logs, and attestation. Repeating the same recipe should either produce a verifiably equivalent output or explain the controlled, recorded source of variation.

Updates

Plan update waves from acquisition through evaluation, approval, transfer, staging, canary or limited release, production, and retirement. Define urgency paths for critical findings — a faster path for a severe vulnerability — without removing identity, review, or post-event evidence; urgency is not a reason to skip the audit trail.

Use the controlled-change model to decide which changes require a full re-evaluation and which can proceed through a lighter, still-evidenced path.

Rollback and recovery

Preserve compatible prior artifacts, configuration, schemas, indexes, and deployment records so a promotion can be reversed without reconstructing them from memory. Test both rollback to a prior approved version and rebuild from internal sources — a system that has only ever been tested going forward has an unverified recovery path.

Back up authoritative repositories, metadata, signing and approval evidence, build definitions, and essential keys according to their individual recovery requirements; not every artifact class needs the same retention or restore priority.

Recovery is more than restored files

Record recovery time, data loss, integrity checks, incompatibilities, and decisions made during the exercise. Successful file restoration is incomplete until the environment can build and run an authorized workload with verifiable inputs — a restored repository that cannot actually produce a working, approved deployment has not demonstrated recovery.