Artifact supply-chain workshop

Workshop objective

Design and evidence the promotion of a model-serving workload — base image, runtime packages, model, tokenizer, serving configuration, and policy — through a simulated import path into a restricted environment. Use synthetic artifacts or harmless placeholders only; do not import real production dependencies as part of this exercise.

Download SAI-200 artifact-promotion-log templateA CSV register for artifact identity, origin, license, quarantine, approval, promotion, and revocation state.

Scenario

An organization needs to import a model-serving workload into a restricted environment: a base container image, runtime packages, a model and tokenizer, serving configuration, and a policy bundle. Reuse the trust-boundary map and control-objective register from SAI-100 and SAI-110; do not redefine the system from scratch.

Step 1: Inventory every artifact

List every direct and transitive artifact required by the workload and assign each one an immutable identity at the point of acquisition.

Exit check: no artifact in the deployed workload is missing from the inventory.

Step 2: Draw the zones

Draw acquisition, quarantine, analysis, approval, transfer, staging, and production zones onto the trust-boundary diagram from SAI-110.

Exit check: every zone has a named owner and an explicit list of who may move an artifact across its boundary.

Step 3: Define state transitions

For each promotion state, define entry criteria, exit evidence, role permissions, failure behavior, and required evidence, using the control-objective pattern.

Exit check: no single role can both approve and promote the same artifact.

Step 4: Build the provenance record

Create a provenance manifest connecting inputs, build, evaluation, approval, and output for each artifact class.

Exit check: every deployed object can be traced back to an approval decision.

Step 5: Design authoritative repositories

Describe internal container, package, and model repositories, including how a missing dependency fails and how revoked content is prevented from being selected.

Exit check: a build cannot silently resolve a dependency from outside the internal repositories.

Step 6: Rehearse a clean-room build

Describe a clean-room build that fails on any external dependency, and identify what evidence that failure produces.

Exit check: the build's failure behavior is deliberate, not accidental.

Step 7: Walk through change and recovery

Walk through a critical dependency update, a failed promotion, a rollback, and a revocation. Restore the repository metadata and rebuild from the declared recovery point.

Exit check: rollback and rebuild are demonstrated, not assumed to work.

Workshop package

Deliver:

1. Artifact inventory with immutable identities.
2. Zone and boundary diagram with named owners.
3. State-transition and responsibility matrix.
4. Provenance manifest.
5. Repository design.
6. Clean-room build recipe and failure evidence.
7. Update, rollback, revocation, and recovery runbook with test evidence.

Review questions

Can every deployed object be traced to an approval? Can an unapproved path bypass promotion? Does revocation reach consumers who already deployed the artifact? Are the build and restore possible with external services unavailable? Are tool and version assumptions clearly separated from the stable design?

This workshop is an educational supply-chain design exercise, not an authorization to import artifacts into a production environment.