Introduction to internal artifact supply chains
Treat every imported package, container, model, dataset, and configuration as a controlled lifecycle object.
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.