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

Before you start

Module prerequisites: SAI-110, SAI-120. Check the exercise-specific tools and environment before running commands.

Module outcomes: Design an approved import workflow; Use checksums, signing, SBOMs, registries, and wheelhouses; Plan repeatable disconnected builds and updates. This lesson contributes to that sequence.

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.

Module worked example

A model archive arrives without a source revision or approved digest.

Apply the control
Keep it in quarantine, obtain provenance, inspect the package and record approval before promotion.
Expected result
The promoted artifact has a traceable identity, review record and rollback location.
Troubleshooting
A familiar file name is insufficient. Compare the digest and manifest against the approved record.

Practice and completion check

Choose one control from this lesson. Identify its actor, target, enforcement point and expected result. Describe an allowed case and a denied or failed case. For a runnable exercise, retain observed output and separate it from expected output. Record unresolved limitations before marking the lesson complete.

Your lesson progress

Completion is self-reported learning progress; it does not certify practical competence.

Status: Not marked

My learning

Loading your learning record…