Introduction to internal artifact supply chains
Treat every imported package, container, model, dataset, and configuration as a controlled lifecycle object.
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.
Purpose of internal artifact supply chains
Restricted AI environments still depend on software packages, base images, models, tokenizers, datasets, policies, and configuration created elsewhere. Disconnection reduces live external dependency; it does not establish that everything already inside the boundary can be trusted. SAI-200 treats every imported artifact as a controlled lifecycle object with an owner, an identity, and evidence — not a file that arrived correctly because the network path looked secure.
Start from earlier-module artifacts
The minimum inputs are:
- The trust-boundary map and attack-surface inventory from SAI-110 and AI assets and attack surfaces.
- The deployment pattern and boundary decisions from SAI-120.
- Any existing import, build, or release process the organization already runs, however informal.
If artifacts currently enter production through an undocumented or ad hoc path, treat that as the first finding, not something to quietly formalize later.
What makes an AI artifact supply chain different
Conventional software supply-chain practice already covers packages and containers. AI workloads add:
- Large binary model and tokenizer artifacts that are harder to diff, scan, and review than source code.
- Frequent, high-value updates — new model versions, fine-tunes, indexes — that create pressure to skip review.
- Artifacts whose behavior can only be partially verified by static inspection; evaluation results matter alongside provenance.
- A wider range of formats and sources, including model hubs and community packages, with inconsistent licensing and signing practices.
The SAI-200 method
SAI-200 uses a controlled lifecycle: discover, acquire, quarantine, identify, inspect, evaluate, approve, transfer, promote, consume, monitor, revoke, and retire. Each state has an owner, entry criteria, exit evidence, and permitted destinations. Use the artifact identity and provenance pattern to identify content immutably and preserve its origin, and record every state transition as evidence.
Module outputs
- An artifact and dependency inventory.
- An import-zone and promotion design.
- A provenance and approval record.
- An internal repository architecture.
- An offline build, update, rollback, and recovery runbook.
Product commands remain in versioned adapters so the control model stays useful as tooling changes.
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…