MLOps / Observation, recovery, and lifecycle decisions / Lesson 16

Artifact provenance and access boundaries

Separate content integrity, origin claims, loading behavior, and permission to change the active prediction process.

About 5 min readContent reviewed 2026-10-28

On this page

Lesson goals

Link provenance to exact artifact content and declared production inputs.
Distinguish authenticated origin from a self-asserted metadata field.
Separate build, read, and selection permissions under a clear policy.

Provenance explains how an artifact was produced

A provenance record can identify the output content, producing process, code and configuration, input materials, execution context, and relevant timestamps. The useful question is whether this evidence supports the expectations for the package being consumed. A generic model-name tag or a copied description is not enough to establish that relationship. Standards such as SLSA define particular provenance concepts and formats; a teaching dictionary is not automatically a conforming attestation. State which specification or local contract is being used and which properties were actually verified, rather than presenting metadata presence as a certification.

Integrity and trusted origin are separate properties

The first fixture hashes exact synthetic bytes and checks them against a recorded digest. A changed byte fails the comparison. The builder name in the same record is merely self-asserted; no signature, trusted identity, or execution evidence authenticates it. A digest supplied by the same untrusted source as the content does not establish trusted origin. A real verification policy needs an appropriate trust root and supported attestation mechanism, alongside expectations about code, input materials, and builder behavior. The fixture implements only content comparison and deliberately reports the origin claim as unestablished.

python Deterministic offline standard-library fixture

import hashlib
content = b"synthetic constant model:4"
record = {"builder":"lab-builder", "recipe":"recipe-1", "inputs":["data-1"],
          "subject_sha256":hashlib.sha256(content).hexdigest()}
print("matching bytes", hashlib.sha256(content).hexdigest() == record["subject_sha256"])
print("changed bytes match", hashlib.sha256(content+b"!").hexdigest() == record["subject_sha256"])
print("trusted builder origin established", False)

Expected output

matching bytes True
changed bytes match False
trusted builder origin established False

A digest links the declared record to exact synthetic bytes; the self-asserted builder string has not been authenticated or verified.

Loading is an execution and compatibility boundary

Some model formats reconstruct executable objects and can run code during loading. Others have narrower representations but still require type, resource, compatibility, and schema validation. Review the framework and format’s documented behavior before loading an unfamiliar artifact into a process with valuable access. This course loads no unknown model and uses self-created JSON or literal synthetic bytes only. Also preserve runtime dependency assumptions: authentic content can still be incompatible with a consumer’s software, feature contract, or hardware requirements. Origin evidence does not replace known-input behavior checks or appropriate statistical evaluation.

Permission follows the operation and its scope

Reading an accepted package, creating a candidate, editing metadata, and selecting a version are different operations. The second fixture illustrates a narrow role-to-operation policy with no permissions for an unknown role. It does not authenticate a user or enforce access outside that function. A real system must apply the policy at the actual operation boundary, with scoped identities, audit records, and appropriate handling of automated actors. A training job that only needs to produce a candidate should not receive unrelated authority to change active selection merely for convenience.

python Deterministic offline standard-library fixture

permissions = {"reader":{"read_package"},
               "builder":{"read_package","create_candidate"},
               "release_operator":{"read_package","select_version"}}
def permitted(role, operation):
    return operation in permissions.get(role,set())
print("reader selects", permitted("reader","select_version"))
print("builder creates", permitted("builder","create_candidate"))
print("unknown role reads", permitted("unknown","read_package"))

Expected output

reader selects False
builder creates True
unknown role reads False

The local policy table defaults to no permission for unknown roles; it does not implement authentication, access enforcement, or a platform security boundary.

Keep evidence and data handling proportionate

Provenance and audit records should contain enough identities and context to investigate a package without exposing credentials or unnecessary private examples. Define retention and retrieval for the artifacts needed by evaluation and recovery. Test altered content, missing provenance, mismatched input identities, unsupported roles, and a package whose known-input behavior differs despite valid integrity. These programs execute only SHA-256 comparison and a local permission lookup. They do not sign or verify attestations, configure access, scan systems, load external objects, or certify a supply chain, model, organization, or operational environment.

Common errors and fixes

A matching hash is treated as proof of trusted training

Why it happens: Content comparison was confused with authenticated origin and process evidence.
How to fix it: Verify origin and declared production expectations through the supported trust policy.
Prevent it next time: Test self-asserted and mismatched provenance separately from byte integrity.

A builder can change active selection unnecessarily

Why it happens: Candidate production and release authority were combined by convenience.
How to fix it: Scope permissions to the operations and resources actually required.
Prevent it next time: Test denied selection operations for non-release identities.

An authenticated package is assumed compatible and useful

Why it happens: Origin was substituted for interface and model-quality evidence.
How to fix it: Check runtime, schema, known inputs, and evaluation independently.
Prevent it next time: Maintain separate provenance, compatibility, and acceptance results.

Check your understanding

1. What does the first fixture establish after matching bytes, and what remains unestablished?

Show worked solution

It establishes equality between the computed digest of the supplied bytes and the digest declared in the local record. It does not authenticate the builder, prove which code or data produced the artifact, establish permission, or show that the model is correct. Those require separate evidence under the supported verification policy.

2. Why should a training identity not automatically inherit selection permission?