C2PA for AI Models, Datasets, and Software Supply Chains

Most public discussion of C2PA begins with a generated image, video, audio clip, or document. That output is only the final visible node in a much larger AI supply chain. Before an inference result exists, an organization may have collected and transformed datasets, assembled training software, selected dependencies, built a container, trained and fine-tuned several model versions, evaluated checkpoints, deployed a runtime, and supplied prompts or other inputs.

C2PA can extend provenance upstream into that chain. A dataset, model package, checkpoint, adapter, software artifact, build record, prompt, or audit log can be treated as a C2PA asset, bound to its own Content Credential, and connected to related assets through signed ingredient relationships. The resulting graph can help a verifier establish which exact artifacts were claimed to participate in a training or inference workflow and whether those artifacts changed after their credentials were issued.[1]

That does not turn C2PA into a complete AI bill of materials, a build-attestation standard, a model registry, a vulnerability database, or a guarantee that training data was lawful, representative, or free of hidden poisoning. The strongest architecture uses C2PA as the portable, asset-bound provenance layer alongside specialized systems such as SPDX, CycloneDX, SLSA, in-toto, Sigstore, model registries, evaluation platforms, and policy engines.

For the output side of the lifecycle, see C2PA for AI-Generated Content. For the broader system architecture, see C2PA Implementation Guide.

Why AI supply chains need provenance

A conventional software release already depends on source code, build tools, dependencies, build infrastructure, package registries, and deployment controls. An AI system adds data and model lineages that can be at least as consequential as the software lineage. The same output API may behave differently because a dataset changed, a tokenizer drifted, an adapter was swapped, a checkpoint was promoted, or an inference image was rebuilt with a different framework version.

A useful provenance system therefore has to answer several different questions at once:

No single standard answers every one of those questions. C2PA is valuable because it gives the assets at each layer a common, signed provenance envelope and a common relationship model. It is most effective when it preserves references to richer evidence instead of attempting to replace it.

What C2PA contributes

A standard C2PA manifest combines assertions, a signed claim, and a cryptographic hard binding to an asset. In an AI supply chain, that asset does not have to be a photograph or finished piece of media. It can be a model file, a dataset collection, a JSON model card, a ZIP package, a software bill of materials, an audit log, or another artifact that can be bound through an appropriate C2PA format or external Manifest Store.

C2PA contributes five capabilities that are particularly useful upstream of generated content:

• Asset integrity. The Content Credential binds the provenance record to a specific file or collection, making post-signing changes detectable.
• Signed statements. Assertions can record type, actions, ingredients, identity, timestamps, and references to other evidence.
• Cross-asset relationships. Ingredients connect a model to datasets, software, earlier models, adapters, prompts, or other inputs.
• Portable trust evidence. A verifier can evaluate the signature, signing credential, time evidence, trust configuration, and validation results independently of the original platform.
• A common graph from source to output. Dataset, model, runtime, input, and output credentials can be traversed as related provenance rather than isolated records.

Those capabilities help detect substitution and tampering after a trusted component has signed an artifact. They do not show that the signer inspected every record in a dataset, that a model is safe, or that a build process satisfied a particular assurance level. Those conclusions require additional evidence and policy.

What C2PA should not replace

The AI/ML guidance published with C2PA describes the use of Content Credentials for datasets, software, and models. Some of its software-supply-chain examples predate today’s mature signing and attestation ecosystems. A modern design should not assume that an SPDX or CycloneDX document is inherently unsigned, or that C2PA should reproduce every field from a BOM or build attestation. Instead, it should preserve the association among those artifacts and the asset they describe.

Which AI supply-chain artifacts can receive Content Credentials?

C2PA 2.4 includes an asset-type assertion designed to describe formats that cannot be expressed fully by a media type alone. Its standard values include generic and framework-specific datasets, classifiers, regressors, generators, prompts, seeds, audit logs, version histories, serialized data formats, and many framework-specific model types. A manifest may contain at most one current asset-type assertion, although that assertion can list multiple compatible type descriptors and versions.

In practical systems, useful credential-bearing assets include:

The format chosen for the asset still matters. A type value describes what an asset is; it does not define how its bytes are packaged or hashed. See C2PA Supported File Formats for the distinction between specification support, SDK support, and workflow preservation.

Model the supply chain as a provenance graph

C2PA ingredient assertions connect one asset to another. The relationship is declared from the perspective of the ingredient inside the current asset’s manifest. Three current relationships are especially important for AI systems:

The same dependency may be represented differently depending on the asset being described. A base model can be a parentOf ingredient of a derived model release, while that model is an inputTo ingredient of an inference output. The relationship should describe the specific creation event, not a generic idea that two assets are somehow related.

Avoid turning the manifest into a complete transitive dependency dump. A model’s C2PA credential should normally identify the assets needed to understand that model’s provenance at the relevant boundary. A detailed dependency inventory can remain in an SPDX or CycloneDX document that is itself bound or referenced. This keeps the C2PA graph navigable while preserving the richer evidence.

Dataset Content Credentials

Datasets create a different binding problem from conventional media because they are often collections rather than single files. They may include millions of records, directory partitions, indexes, label files, documentation, and intermediate products. The first implementation decision is therefore to define the dataset asset boundary precisely.

Single-file datasets

A CSV, Parquet file, database export, archive, or other monolithic dataset can be treated as one asset. The final serialized representation is hashed through the appropriate hard-binding method and receives a manifest describing its type, version, origin, actions, and ingredients. Any repackaging, row-order change, metadata rewrite, or compression change that alters protected bytes ordinarily creates a new asset version and requires a new standard manifest.

Multi-file datasets and collections

When the asset is a defined collection, C2PA uses the collection data hash assertion. The manifest records a URI and cryptographic hash for each member of the collection. C2PA 2.4 specifically gives AI training folders as an example. Multi-file ingredient guidance also recommends identifying the collection with a Manifest and using an asset reference where the constituent files can be found.

A production profile must define stable collection rules before hashing:

• Which files and directories are in scope, including hidden files, indexes, schemas, and documentation.
• How relative paths are normalized and whether case sensitivity matters.
• How symbolic links, generated caches, empty directories, or platform-specific metadata are handled.
• Whether the credential describes one immutable snapshot, a partition, or a versioned logical dataset.
• How very large collections are chunked so verification remains bounded and operationally realistic.

Without those rules, two systems can claim to sign the same “dataset” while hashing different sets of files.

Represent dataset lineage, not only a final hash

A final hash proves that the credential describes a particular dataset snapshot. It does not explain how that snapshot came to exist. Useful dataset credentials can connect raw sources, labeling exports, curation stages, deduplication runs, filtering rules, train/test/evaluation splits, and later corrections.

For example, a curated training set may record the raw corpus as a parentOf ingredient, the labeling instructions and software as inputTo ingredients, and a separately versioned schema as a component. The actions assertion can describe filtering, annotation, conversion, aggregation, or other significant operations. If the dataset is divided into released partitions, each partition can receive its own credential and be included in the credential for the complete release.

What dataset provenance does not prove

A correctly validated dataset credential can show that the signed snapshot has not changed, who or what signed the provenance record, and which sources or transformations were asserted. It does not independently prove that every record was collected lawfully, that consent was adequate, that labels are accurate, that the sample is representative, or that no poisoned records were present before the trusted signer created the credential. C2PA makes the declared artifact and history tamper-evident; it does not perform data governance or statistical validation.

The binding mechanics are covered more deeply in C2PA Hard Bindings and Soft Bindings.[2]

Model Content Credentials

A model release is also an asset boundary. The exact boundary may be a single weights file, a SavedModel directory, an ONNX package, a set of sharded checkpoints, a tokenizer and vocabulary, a container image, or a deployment bundle. The credential must bind the object that consumers are expected to retrieve and verify.

A useful model manifest commonly includes:

• An asset-type assertion identifying the model family, framework, serialization, and version where appropriate.
• A hard binding to the released file or defined collection.
• Actions describing training, conversion, pruning, quantization, distillation, packaging, or release events when those actions are meaningful and supported by the profile.
• Ingredients for datasets, earlier models, adapters, code, configuration, or other direct inputs.
• References to a model card, AI/ML-BOM, SBOM, build provenance, evaluation report, and other specialized evidence.
• The claim generator and signing credential, with trusted time or status evidence where the assurance profile requires it.

C2PA 2.4 provides standard model-type values for many frameworks. These values help a consumer interpret the artifact, but they do not validate that the bytes actually form a safe or executable model. An implementation should still parse untrusted model packages in an isolated environment and apply format-specific security controls.

Multi-file and private models

For a multi-file model, an implementation can package the release into a stable archive, bind the defined collection, or issue credentials for important components and connect them as ingredients. The choice should match how the artifact is distributed and loaded. If a registry digest identifies the release, that digest should be retained as an external identifier rather than replaced by an unrelated C2PA-only identifier.

A private or internal model does not have to be published at a public URL merely to appear in provenance. C2PA ingredient examples allow a model to be described through its media type, data-type information, version, and description even when its bytes cannot be embedded or linked. This preserves some provenance context while making the limitation visible: the consumer may be unable to retrieve and independently validate the private model.

Fine-tuning, adapters, checkpoints, and derived releases

Model development rarely ends with one training run. Fine-tuning, parameter-efficient adapters, checkpoint promotion, quantization, distillation, pruning, merges, and other transformations create additional assets whose dependencies should remain visible.

The C2PA AI/ML guidance recommends representing a fine-tuned model with the base model and fine-tuning dataset as ingredients. For LoRA, it describes either treating the adapter as a fine-tuned model with those dependencies or representing the base model and adapter as separate models participating in inference. It also recommends treating meaningful incremental checkpoints as standalone model assets whose provenance can be followed backward.

That guidance is informative rather than a complete normative ontology for every modern training technique. Organizations should publish a versioned modeling profile that defines how their adapters, merged weights, checkpoints, and ensembles are represented. Without a profile, two valid C2PA implementations may produce graphs that are technically well formed but semantically difficult to compare.[3]

Software and build provenance

A model’s behavior depends on more than weights and data. Training and inference software, compilers, frameworks, container images, drivers, kernels, build tools, and deployment configuration can all change the resulting artifact or runtime behavior. C2PA can bind and relate software evidence, but dedicated software-supply-chain standards should remain authoritative for their own domains.

BOMs describe inventory and characteristics

SPDX 3.0.1 provides separate AI, Dataset, and Build profiles. The AI profile describes AI systems, models, and related artifacts; the Dataset profile describes dataset preparation, characteristics, and access; and the Build profile describes build inputs, outputs, tools, environments, and actors. CycloneDX provides an AI/ML-BOM capability for models, datasets, configurations, model cards, dependencies, risks, and other transparency information.

These formats are better places for rich component inventory, licenses, supplier information, dependencies, vulnerabilities, model-card fields, and detailed dataset metadata. A C2PA manifest can bind the BOM document itself and associate it with the exact model release. That protects the document against undetected modification and keeps the model-to-BOM relationship portable, without copying every BOM field into C2PA assertions.

SLSA and in-toto describe how artifacts were produced

SLSA provenance is designed to describe where, when, and how software artifacts were produced. It is expressed through the in-toto attestation framework and can identify build inputs, parameters, builder identity, outputs, and other process evidence. In-toto provides a broader framework for recording which supply-chain steps occurred, who performed them, and in what order.

For a model release, SLSA or in-toto evidence may describe the packaging or build pipeline that converted source, dependencies, and training outputs into the distributed artifact. C2PA can connect that evidence to the model and then connect the model to datasets and outputs. The systems overlap at integrity and provenance, but their schemas and trust policies answer different questions.

Sigstore signs and records software artifacts and attestations

Sigstore and Cosign are designed for signing and verifying software artifacts, container images, blobs, SBOMs, and in-toto attestations, with identity and transparency-log options. When a model is distributed through an OCI registry, a Sigstore signature and C2PA Content Credential can coexist. The Sigstore evidence can serve the software distribution and transparency workflow; the C2PA credential can participate in the broader cross-media and AI provenance graph.

The rule is simple: do not create competing, unverifiable copies of evidence. Bind or reference the canonical BOM, attestation, signature bundle, and registry digest. Record enough identifiers and hashes that a consumer can prove which evidence belongs to which model release.[4]

A layered evidence architecture

A production AI assurance system is strongest when each layer answers a well-defined question:

A verifier or deployment controller can evaluate these layers together. It might require a trusted C2PA signature, a matching model digest, an approved base-model lineage, a valid SLSA attestation from an authorized builder, a current BOM, and passing evaluation evidence. C2PA supplies important facts to that decision, but the decision belongs to policy.

Training and data-mining preferences

Provenance about a dataset is different from permission to use it. The Creator Assertions Working Group defines the cawg.training-mining assertion so a human actor can communicate whether an asset may be used for data mining, AI inference, generative training, or other AI training. Each entry can be marked allowed, notAllowed, or constrained.

This assertion is a signed communication of preference or constraint. It is not a technical access-control mechanism, a license grant, a judicial determination, or proof that the signer owns every relevant right. A training pipeline should combine the assertion with contracts, licenses, consent records, jurisdiction-specific rules, and internal policy. If the value is constrained, the CAWG specification says consumers should treat it as not allowed unless the constraint is resolved.

An organization that ingests credentialed training assets should record both the original assertion and the policy decision made at ingestion. That creates evidence of what the asset stated and how the organization interpreted it at the time, while preserving the distinction between provenance and legal authorization.[5]

Inference and output provenance

The same graph can continue into inference. A model, adapter, prompt, retrieval result, reference media, sensor input, or configuration can be recorded as an inputTo ingredient of an output. The output’s actions and digital source type can describe whether it was generated, edited, enhanced, translated, classified, or otherwise processed. C2PA 2.4 uses the current trained-algorithmic-data URI rather than the older deprecated c2pa.trainedAlgorithmicData value.

Not every inference input should be exposed. Prompts can contain trade secrets, personal data, legal instructions, or sensitive customer material. Retrieved context may be licensed or confidential. A private model may reveal security-sensitive deployment information. Implementations can use hashed or remote references, omit unnecessary detail, apply redaction, separate public and private evidence views, or record a type and version without publishing the underlying asset. The disclosure policy should be explicit and versioned.

For a generated result, the credential may reference the model release that participated in inference. If that model has its own Content Credential, a consumer can traverse from output to model, from model to datasets and build evidence, and from those nodes to their own upstream sources. The graph may be incomplete because some assets are private or unavailable, but its limitations should be visible rather than silently replaced with unsupported certainty.

The output-specific disclosure model is covered in C2PA for AI-Generated Content.[6]

Validation and policy evaluation

A supply-chain graph is useful only if its nodes and edges are validated. A production verifier should not accept a model because it contains a plausible-looking manifest or because a registry UI displays a green badge. It should verify the manifest structure, assertion hashes, hard binding, claim signature, certificate path, trust configuration, time evidence, revocation status, ingredient references, and any external resources that policy requires.

Each linked evidence system also needs its own verification. A valid C2PA signature does not validate an SPDX schema, a SLSA predicate, a Sigstore transparency-log inclusion, an evaluation methodology, or a registry access policy. The control plane should preserve the independent result from each verifier and then evaluate a higher-level policy.

A deployment policy might require all of the following:

• The model file or collection matches its C2PA hard binding.
• The model credential chains to an approved signer or private trust anchor.
• The release is derived from an approved base model and no prohibited adapter is present.
• The BOM and build-provenance documents match the model digest and validate under their own systems.
• The build ran on an approved builder with the expected source and configuration.
• Required datasets have credentials, rights records, or approved exceptions.
• Safety and quality evaluations apply to the exact model version and deployment configuration.
• The production runtime has not substituted another model after admission.

Store the exact trust-list snapshot, policy version, verifier version, evidence digests, and decision trace. Re-evaluating the same artifact later under a new policy should create a new result rather than rewriting the historical one.

Threats and failure modes

C2PA reduces some substitution and tampering risks, but it does not make an AI supply chain secure by itself. Several failure modes deserve explicit design treatment:

For a broader treatment of hostile files, signing abuse, unsafe retrieval, and misleading interfaces, see What C2PA Proves—and What It Does Not Prove.[7]

A practical reference architecture

The following sequence keeps each evidence system authoritative while producing one connected release record:

1. Define the release boundary. Specify exactly which dataset, model, package, checkpoint, adapter, container, or report is being issued as an immutable asset.
2. Finalize bytes before signing. Complete serialization, sharding, compression, quantization, packaging, and other content-changing operations.
3. Generate specialized evidence. Produce the SPDX or CycloneDX BOM, model card, evaluation report, SLSA/in-toto provenance, Sigstore signature, and other required records.
4. Assign canonical identifiers. Preserve registry digests, artifact URIs, dataset versions, model versions, and organizational identifiers without inventing competing IDs.
5. Construct the C2PA manifest. Add the asset type, significant actions, direct ingredients, references to specialized evidence, identity information, and the appropriate hard binding.
6. Sign through an authorized service. Keep production keys non-exportable, enforce tenant and environment boundaries, and record the authorization decision.
7. Validate the completed artifact independently. Reopen the final file or collection, verify the binding and signature, and ensure every required evidence reference resolves to the expected bytes.
8. Publish atomically. Store the artifact, Content Credential, BOMs, attestations, evaluations, and evidence index so no version can be mixed with another.
9. Evaluate release policy. Decide whether the artifact may enter the registry, staging environment, or production based on all evidence layers.
10. Verify again at deployment. Admission controls should validate the exact digest that the runtime will load, not merely the human-readable version label.
11. Record inference provenance where appropriate. Connect the deployed model and selected inputs to generated outputs without exposing unnecessary secrets.
12. Monitor and re-evaluate. Recheck revocation, trust, vulnerability, policy, evaluation, and lifecycle state as the environment changes.

The transactional rule is important: a model artifact, its credential, and its external evidence must be promoted as one coherent release. A race in which the model is updated but the BOM or credential still describes the previous version creates a formally signed yet operationally misleading system.

Three practical examples

1. Public foundation-model release

A provider publishes sharded weights, a tokenizer, configuration files, a model card, an AI/ML-BOM, and a container used for a reference inference service. The provider defines the release as a collection, binds each file or stable package, identifies the model framework and version, records the tokenizer and configuration as components, and links the build provenance and BOM by immutable digest. Training datasets may be represented through credentialed dataset releases, public summaries, or constrained references depending on disclosure and licensing obligations.

A consumer can verify that the downloaded package matches the signed release and inspect the claimed lineage. The consumer still needs to evaluate license terms, model behavior, safety testing, dataset sufficiency, and whether the signer is trusted for the intended use.

2. Private LoRA adaptation service

An enterprise creates an adapter from an approved base model and a confidential fine-tuning dataset. The adapter receives its own credential. Its ingredients identify the exact base-model digest and the fine-tuning dataset’s internal credential ID; the dataset bytes and prompt-like examples remain private. The training container’s BOM and SLSA provenance are retained in the evidence system and bound to the adapter release.

At inference, the runtime verifies both the approved base model and the adapter before loading them. Output credentials can identify the model family and adapter version without publishing the private dataset or customer prompt. Internal investigators retain a richer evidence view than external consumers.

3. Regulated prediction pipeline

A regulated service uses a signed model package, a signed inference container, a versioned feature-transformation pipeline, and sensor input. Deployment policy requires a trusted model credential, approved builder provenance, a current BOM, a passing evaluation report, and a measured runtime. The inference result receives an internal credential that references the model and input batch by immutable IDs and records the policy version used for the decision.

The credential supports audit and incident reconstruction. It does not replace domain validation, human review, or the organization’s legal obligations. A technically valid chain may still represent an inappropriate model or a flawed decision process.

Common misunderstandings

Production checklist

Asset and graph design

• Define immutable asset boundaries for datasets, partitions, models, adapters, checkpoints, packages, and evidence documents.
• Use stable registry digests and versions, and publish the direction and meaning of every ingredient relationship.
• Keep C2PA ingredients focused on direct provenance; retain transitive dependency detail in the appropriate BOM or build system.
• Create new credentials after content-changing conversion, packaging, quantization, merging, or fine-tuning.

Evidence generation

• Generate BOM, build, evaluation, rights, and model-card evidence from the same immutable release inputs.
• Hash or bind every external evidence object and avoid mutable “latest” URLs.
• Record private evidence through access-controlled references or internal views rather than exposing secrets in public credentials.
• Preserve the original assertion and the policy decision made from it, especially for training and data-mining preferences.

Signing and verification

• Protect signing authorization and keys separately from ordinary artifact-write permissions.
• Independently verify the final bytes or collection after signing and before release.
• Validate each evidence format with its own verifier; do not infer SLSA, BOM, Sigstore, or evaluation validity from C2PA alone.
• Store policy, trust, verifier, and evidence snapshots so historical decisions are reproducible.

Deployment and operations

• Pin runtime loading to the digest that was verified and approved.
• Revalidate at promotion and deployment boundaries, not only when the artifact first enters the registry.
• Bound remote retrieval, recursion, graph depth, decompression, and parser resources.
• Monitor revocation, vulnerabilities, model lifecycle, evidence availability, and policy changes.
• Test incomplete, conflicting, malicious, stale, and inaccessible provenance—not only ideal happy paths.

What this architecture can establish

When correctly implemented, a layered C2PA supply-chain design can provide evidence that a particular model, dataset, software package, report, or output matches the asset representation bound by its credential; that its signed assertions have not changed; that it was signed using a particular credential; and that it claims particular relationships to upstream artifacts. It can also preserve connections to independently verifiable BOMs, build attestations, software signatures, evaluations, and registry records.

What it cannot establish by itself

It cannot prove that a dataset was collected lawfully, that a model is unbiased or safe, that training was free of poisoning before signing, that a model card is honest, that the provenance graph is complete, that a runtime loaded the verified artifact without additional controls, or that an organization satisfies a particular legal or regulatory regime. C2PA strengthens evidence integrity and portability. Assurance still depends on the quality of the underlying process, the honesty and security of the issuers, independent verification, specialized evidence, and policy.

The simplest mental model

• The dataset credential identifies and protects the data snapshot that was claimed to participate.
• The model credential identifies and protects the released model artifact and its direct lineage.
• The BOM describes what components and dependencies are inventoried.
• The build attestation describes how the artifact was produced.
• The software signature or transparency system records distribution-oriented signing evidence.
• The evaluation and policy layers decide whether the evidence is sufficient for a specific use.
• The output credential can connect the deployed model and selected inputs to the resulting content or decision.

C2PA is the thread that can connect those assets across organizations and tools. It is most valuable when it preserves the distinctions among them.

Sources and notes

Notes are limited to version-specific C2PA structures, current AI/ML guidance, and the external supply-chain standards needed to distinguish their roles accurately.

[1] C2PA, “Guidance for Artificial Intelligence and Machine Learning,” C2PA 2.4. Informative guidance for dataset, software, and model provenance; poisoning risks; fine-tuning; adapters; checkpoints; and model release lineage.

[2] C2PA Technical Specification 2.4, asset type, collection data hash, ingredient, and multi-file ingredient sections. Normative structures for model and dataset asset types, hard binding of collections, parentOf/componentOf/inputTo, prompts and private models, and multi-file datasets.

[3] C2PA, “Guidance for Artificial Intelligence and Machine Learning,” model fine-tuning and versioning sections. Representation of base models, fine-tuning datasets, LoRA/PEFT adapters, and independently credentialed checkpoints.

[4] SPDX 3.0.1; SLSA 1.2; in-toto; Sigstore; CycloneDX AI/ML-BOM. Current inventory, build-provenance, attestation, signing, transparency, and AI/ML-BOM structures.

[5] Creator Assertions Working Group, “Training and Data Mining Assertion 1.1.” Signed allowed, notAllowed, and constrained signals for data mining, AI inference, generative training, and other AI training.

[6] C2PA Technical Specification 2.4, actions, ingredients, asset type, AI Disclosure, and digital source type provisions. Current structures for connecting models, prompts, other inputs, and generated outputs; includes the replacement of deprecated c2pa.trainedAlgorithmicData.

[7] C2PA, “Security Considerations,” C2PA 2.4. Threat-model guidance, trust boundaries, collection hashing, AI/ML ingredients, hostile inputs, and the distinction between provenance integrity and truth.