Offline build, update, and recovery
Make disconnected builds repeatable and design controlled updates, rollback, rebuild, backup, and recovery.
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
Loading your learning record…