SovAIHub
ModulesSAI-270
SAI-270 table of contents
Concept2 min readDraft

Artifact identity and provenance

Identify software, models, data, prompts, policy, and configuration with verifiable origin and lineage.

Last content review 2026-08-03Included in SAI-200, SAI-210, SAI-220, SAI-250, SAI-270

Before you start

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

Module outcomes: Deploy AI workloads with restricted security controls; Operate storage, networking, and GPU dependencies; Plan controlled updates, backup, and recovery. This lesson contributes to that sequence.

Why identity must come before trust

An artifact name such as model-latest, base-image, or policy.json is convenient but not sufficient for a controlled decision. A sovereign AI lifecycle needs an immutable identity for every material software package, container, model, dataset, prompt, policy, configuration, and generated build output.

Identity answers what exact object is this? Provenance answers where did it come from, what happened to it, and who approved those events? Neither proves that an artifact is safe. Together they make verification, comparison, rollback, and investigation possible.

Minimum provenance record

For each material artifact, record:

  • Immutable digest or equivalent content identity.
  • Human-readable name, version, format, and size.
  • Origin, supplier or publisher, acquisition time, and acquisition method.
  • Declared license, usage conditions, and redistribution constraints.
  • Parent inputs, build recipe, transformations, and produced outputs.
  • Verification results, exceptions, reviewers, approvals, and timestamps.
  • Current lifecycle state: quarantined, evaluated, approved, promoted, revoked, superseded, or retired.
  • Links to evaluation, vulnerability, configuration, release, and deployment evidence.

Use signed attestations where the organization can protect signer identity and verify signatures. A signature without an understood identity and authorized purpose is only a cryptographic event.

Provenance graph

Treat provenance as a graph, not a single document. A served model may depend on model weights, tokenizer, runtime image, libraries, prompt templates, policy, hardware profile, and serving configuration. The release record should identify that complete set.

When an input changes, the graph makes the affected builds, evaluations, approvals, and deployments discoverable.

Verification questions

Before promotion, verify that the artifact identity matches the reviewed object, all required parents and transformations are known, approval applies to this version and purpose, evidence is integrity-protected, and revocation can prevent further use.

Implementation-specific manifest formats and signing commands belong in versioned adapters. The stable requirement is that identity and provenance remain independently verifiable.

Module worked example

Inference works in a disconnected cluster, but the internal registry becomes unavailable.

Apply the control
Exercise registry and dependency recovery with the declared backup media and operator identities.
Expected result
The recovery record shows which services can be rebuilt and how long restoration takes.
Troubleshooting
Check artifact, identity, key and storage dependencies; restarting the model pod alone may not restore the platform.

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…