C2PA Ingredients Explained

A C2PA ingredient is an existing asset or data item that contributed to the current asset or to the process that created it. An ingredient can be the photograph opened for editing, the logo placed into a design, the audio clip mixed into a video, the prompt sent to a model, the model used during inference, or a dataset that helped produce another computational artifact. The current C2PA ingredient assertion uses the label c2pa.ingredient.v3.^[1]

Ingredients answer a different question from actions. An action says what happened; an ingredient says what participated. Used together, they can connect a crop to its parent photograph, a placement operation to its component asset, or an AI generation event to the inputs that shaped the output. The ingredient relationship becomes part of the signed claim, and any available ingredient manifests can be preserved alongside the current manifest.

An ingredient assertion is not a promise that every source, influence, prompt, or hidden system dependency has been disclosed. It is a signed description of the inputs the claim generator chose and was able to record. A responsible reader therefore treats the resulting provenance graph as structured evidence, not as a guaranteed complete reconstruction of the creative process.

Ingredients make provenance a graph

A simple edit history is often presented as a timeline: capture, edit, export, publish. Real production workflows are rarely that linear. A documentary video can contain dozens of clips, photographs, graphics, sound effects, music tracks, captions, and generated elements. A marketing image can descend from one parent photograph while also containing several components and one model-produced background. An AI output can depend on a prompt, reference media, a model, an adapter, retrieved data, and post-processing software.

C2PA represents those dependencies through ingredient assertions. Each assertion belongs to the current manifest and describes one relationship between the current asset and a contributing asset or data item. If an ingredient has Content Credentials, the current Manifest Store can also preserve the ingredient manifests that describe its earlier provenance. Following those links backward produces a graph of separately signed records rather than one mutable master history.

This article assumes familiarity with the larger manifest structure. For the relationship among the Manifest Store, active manifest, assertion store, claim, and claim signature, see C2PA Manifests Explained. For the general assertion model, see C2PA Assertions Explained.

What can count as an ingredient?

An ingredient does not have to be a conventional media file. The definition is intentionally broad enough to cover both creative source material and computational inputs. What matters is that the item contributed to the current asset or to the process that produced it.

Not every internal object deserves a public ingredient assertion. Temporary cache entries, low-level render buffers, security-sensitive system prompts, private customer data, and proprietary model details may be inappropriate to publish. The implementation must decide which inputs materially improve provenance, which belong only in private audit records, and which should be omitted or summarized for privacy, confidentiality, security, or size reasons.

The current assertion is c2pa.ingredient.v3

C2PA 2.4 recognizes three ingredient-assertion generations. Version 1 uses the label c2pa.ingredient, version 2 uses c2pa.ingredient.v2, and the current version uses c2pa.ingredient.v3. Versions 1 and 2 are deprecated for new writing, but validators and readers still need to understand them when processing older Content Credentials.

Version 3 was introduced to support more reliable validation of ingredient lineage, including cases where assertions in copied ingredient manifests have been redacted. It separates references to the ingredient's active manifest and claim signature, uses a richer validationResults structure, and adds fields for data types, soft-binding recovery, and direct digital-source classification when no ingredient manifest is available.^[1]

When a manifest contains more than one current ingredient assertion, ordinary C2PA instance labelling applies: c2pa.ingredient.v3, c2pa.ingredient.v3__1, c2pa.ingredient.v3__2, and so on. The safest compatibility rule is simple: write version 3, read all supported historical versions, and normalize them into a common internal model without erasing version-specific differences.

The three ingredient relationships

Every current ingredient assertion requires a relationship value. C2PA defines three possibilities, and choosing the correct one is central to the meaning of the provenance graph.^[2]

parentOf: derivation and renditions

The parentOf relationship identifies the ingredient as the parent from which the current asset was derived. A photograph opened, cropped, and exported to a new JPEG is the straightforward example. A high-resolution master transcoded into a delivery rendition can also be represented this way.

A standard manifest may contain zero or one parentOf ingredient; more than one causes manifest validation to fail. The restriction gives the current representation one principal derivation path while still allowing any number of component and computational inputs. An update manifest is stricter: it must contain exactly one ingredient and that ingredient must be parentOf, linking the update to the manifest whose protected content remains authoritative.

componentOf: composition and placement

The componentOf relationship identifies material included as part of a composed asset. A campaign graphic may have separate component ingredients for its product photograph, logo, type treatment, background texture, and generated illustration. A video may have component ingredients for clips, music, captions, graphics, and narration.

The relationship records contribution, not ownership, licensing status, or visual prominence. A tiny logo and a full-frame photograph are both components. Regions and action details can add context about where or how a component was placed, but the ingredient assertion itself does not quantify creative importance.

inputTo: computational inputs

The inputTo relationship is designed for data used by a computational process. It is especially important for AI and machine-learning workflows, where the relevant input may be a prompt, reference image, model artifact, adapter, source recording, retrieval result, or dataset rather than a visible component of the final media.

An input does not need to appear in the final asset. A text prompt can shape an image without being rendered into it; a model can determine output without being distributed to the viewer; a retrieval source can inform generated text without being copied verbatim. The ingredient records that the item was represented as an input, not that its causal contribution has been independently measured.

Actions and ingredients must agree

Ingredients identify participating assets or data. Actions identify the operations performed with them. C2PA connects the two through hashed references from an action to the relevant ingredient assertions. A filename or arbitrary URL in an action is not a substitute for an ingredient assertion.

When a standard manifest adds a parentOf ingredient, the actions assertion must include a c2pa.opened action. When it adds a componentOf ingredient, it must include a c2pa.placed action. The action should reference the corresponding ingredient assertion through its parameters.ingredients list. C2PA does not prescribe one generic required action for every inputTo ingredient, because computational workflows vary; the actions should nevertheless describe the operation that used the input accurately.^[2]

This division of labor prevents one overloaded field from carrying the entire story. The ingredient says which source or input was involved. The action says what the workflow did. A digital source type can classify the origin or process, and other assertions can add model, identity, rights, region, or policy context. The companion article C2PA Actions Explained covers the full operation model.

Anatomy of a v3 ingredient assertion

The current ingredient structure combines one required relationship with optional identity, provenance, validation, data, presentation, and recovery fields. A claim generator should include only fields it can populate accurately and should avoid copying information that is already available in the ingredient's own active manifest.

Identifiers, names, and formats

An ingredient needs enough identity to remain distinguishable from other inputs, but C2PA does not reduce identity to a filename. When an ingredient has a C2PA manifest, its manifest label supplies the unique identifier. A separate instanceID may still be included, but it is optional. For an ingredient without C2PA provenance, an instance identifier can be derived through the specification's non-C2PA asset-identification rules.

The optional dc:title is a display name, not a security property. A local filename can change, collide, reveal sensitive information, or have no meaning after distribution. The optional dc:format should contain a valid IANA media type and helps consumers decide how to present or process the ingredient. Multi-file ingredients, such as datasets, use multipart/mixed and normally require a higher-level manifest or collection model rather than pretending that one filename represents the entire set.

Ingredients with and without their own Content Credentials

C2PA supports both provenance-bearing ingredients and manifestless ingredients. The distinction changes what a consumer can validate and how confidently the ingredient's origin can be described.

A manifestless parent or component normally produces an informational ingredient.unknownProvenance result during recursive validation. The specification does not require the same informational result for inputTo ingredients, because prompts, models, datasets, and other computational inputs often do not have standalone Content Credentials. That exception should not be misread as proof that an input is trustworthy; it only recognizes a common workflow reality.

Preserving ingredient manifests

When an ingredient has its own Manifest Store, the claim generator normally copies its manifests into the current asset's Manifest Store. This is what allows provenance to travel with a composite or derived asset after the authoring application no longer has access to the source files. The copied records sit beside the current active manifest as ingredient manifests; they do not become part of the current claim or get re-signed as though the current signer created them.^[3]

The claim generator compares manifest identifiers and hashes to avoid storing duplicate copies. If a manifest with the same identifier is already present and is identical, it is not copied again. If the identifiers match but the content differs, the implementation must determine whether redaction explains the difference; otherwise the incoming manifest is relabelled with a new identifier before insertion. These rules prevent silent collision while allowing privacy-preserving redacted lineage to remain usable.

The source asset bytes are generally not copied merely because the source manifests are copied. A final graphic can carry a source photograph's signed manifest history without embedding the full original photograph. This distinction matters for later validation: the copied manifest and signature can be checked, but the original ingredient's exact hard binding usually cannot be recomputed unless the original ingredient asset is still available.

Ingredient validation happens at ingestion

When an ingredient assertion references a C2PA manifest, the claim generator must also act as a validator. It validates the ingredient as it enters the workflow and records the results in the ingredient assertion. In version 3, validationResults contains the full results for the ingredient's active manifest and delta results for ingredient manifests deeper in its lineage.^[3]

The results are divided into success, informational, and failure codes. They can also record the specification version used for validation and, when a non-C2PA trust configuration was used, an identifier for that trust list. The purpose is historical accountability: a later consumer can see what the importing system found and compare that record with the results of current recursive validation.

If the recorded results contain failures, the claim generator is explicitly acknowledging that the ingredient had provenance errors and that the workflow chose to continue. This can be legitimate - for example, an editor may decide to use historically important material whose credential is untrusted or partially invalid - but the interface should raise the warning before the asset is incorporated and should preserve the decision in audit records.

For a deeper explanation of the recursive algorithm and the difference between stored and current results, see How C2PA Verification Works.

Redaction and version 3 validation

A later claim generator may need to remove a sensitive assertion from copied ingredient provenance. C2PA records that redaction in the later claim rather than silently rewriting the earlier signer's history. Redaction complicates ingredient validation because hashing the entire copied manifest would naturally differ after an assertion has been removed or replaced with zeros.

Ingredient version 3 addresses this by separately referencing the ingredient's active manifest and claim signature. A validator can use the claim-signature hash path to validate the signed claim, credential, non-redacted assertions, and declared redactions without requiring the copied manifest to remain byte-for-byte identical to an unredacted version. This is one reason claimSignature is a first-class field rather than an incidental implementation detail.

Redaction is not erasure from every copy. The original assertion may already exist in other files, repositories, backups, or public distributions. The safest approach remains data minimization at creation time, especially for location, identity, prompts, private model information, confidential documents, and sensitive thumbnails.

Ingredient data, models, prompts, and datasets

Some ingredients are useful only if the underlying data is available or precisely referenced. C2PA version 3 can use the data field to point by hash to an embedded-data assertion or to a hashed external resource. This is particularly relevant for prompts, model artifacts, configuration files, structured inputs, and other non-media data.^[4]

Embedding data keeps it with the manifest and causes it to travel into future manifests that preserve this asset as an ingredient, unless the data is later redacted. That can improve reproducibility but also create large credentials and irreversible disclosure. An external hashed reference can reduce size while preserving an expected content hash, but it introduces availability, authorization, and remote-fetch risks.

The dataTypes array adds structured information about what the data represents. A private model that cannot be embedded or exposed through a stable URL can still be described as a generator and a model of a particular framework or version. These type declarations improve machine readability, but they remain signed statements from the claim generator; they do not prove that the described model actually executed unless stronger system evidence or attestation supports that conclusion.

Multi-file ingredients require an explicit collection strategy. C2PA recommends a manifest for the full dataset or collection and an asset-reference assertion describing where its members can be found. The ingredient then points to the higher-level provenance object instead of pretending that one arbitrary file is the entire dataset.

AI-specific ingredient patterns are covered further in C2PA for AI-Generated Content. The exact association between content and provenance, including soft-binding recovery, is covered in C2PA Hard Bindings and Soft Bindings.

Thumbnails, descriptions, and informational pages

An ingredient thumbnail can help a creator recognize the source being imported and help a later viewer understand the provenance graph. The ingredient assertion references a separate thumbnail assertion by hash. The thumbnail is an approximate presentation aid; it is not the original ingredient, and it is not the hard binding that proves association with the source asset.

The optional description should be produced by the claim generator and should not contain unfiltered user-provided text. That restriction reduces the risk of injection, impersonation, abusive content, secrets, and misleading free-form statements entering a signed system field. User-authored descriptions belong in a deliberately designed custom assertion with appropriate validation and presentation rules.

The optional informationalURI can point readers to a model card, licensing page, dataset documentation, or other human-facing context. It is not an authenticated link to the ingredient content itself. The page may change, disappear, redirect, or present information controlled by another party. A verifier should display it as supplementary context and apply ordinary safe-link handling.

Soft-binding recovery of ingredient provenance

An authoring tool may open or place an asset whose embedded Content Credential has been stripped. It can attempt a soft-binding lookup using a fingerprint or invisible watermark. If the lookup recovers a candidate manifest, the claim generator can copy that manifest into the current Manifest Store and set softBindingsMatched to true, together with the algorithm names in softBindingAlgorithmsMatched.^[5]

The resulting ingredient will often record validation failures because the recovered manifest's original hard binding does not match the transformed or recompressed asset now being imported. That is expected. The fields disclose how the provenance was recovered; they do not upgrade the soft match into an exact validation of the current ingredient representation.

A responsible interface therefore distinguishes three states: exact ingredient provenance validated against the original asset, candidate provenance recovered through a soft binding, and an ingredient with no located provenance. For details on the recovery architecture, see Durable Content Credentials.

How validators traverse the ingredient graph

A validator starts from the current active manifest, resolves each ingredient assertion, and recursively follows any activeManifest references into copied ingredient manifests. The result is equivalent to a depth-first traversal of the provenance graph. The validator also tracks redacted assertion identifiers and repeated manifest references so that shared ancestors and redacted branches can be processed consistently.^[5]

For each manifest-bearing ingredient, the validator checks the ingredient assertion hash, the active-manifest or claim-signature reference, the ingredient claim signature, the signing credential, non-redacted assertions, and the recorded validation results. It does not blindly validate every extra manifest present in the Manifest Store; only manifests connected through recognized ingredient assertions form the ordinary ingredient lineage.

The graph can contain shared ancestry. Two components may descend from the same original source, and several branches may reference the same model or dataset manifest. A consumer should avoid displaying duplicate branches as though they were independent evidence, while still preserving the fact that the shared ingredient participated in more than one path.

Ingredients in update manifests

An update manifest adds restricted signed provenance without changing the protected asset content. It contains no new hard binding. Instead, it contains exactly one parentOf ingredient pointing to the manifest being updated. If several updates are chained, a validator follows the parent ingredients until it reaches the standard manifest whose hard binding applies to the asset.^[5]

This use of parentOf is structurally different from an ordinary edit. An update can record publication, repository receipt, time or certificate-status evidence, redaction, or other permitted non-content-changing information. It cannot be used to hide a crop, retouch, generative fill, rewrite, or transcode that changed protected content. Those operations require a new standard manifest and a new hard binding.

Three practical workflows

1. Edited news photograph

1. A camera captures a photograph and issues a standard manifest.

2. An editor imports the photograph. The editing system validates the ingredient, copies its manifests, and creates a parentOf ingredient with activeManifest, claimSignature, and validationResults.

3. The actions assertion begins with c2pa.opened and references the parent ingredient, followed by crop and tonal-adjustment actions.

4. The editor exports a new file. A new standard manifest hard-binds to that edited representation while preserving the camera provenance as ingredient history.

2. Composite campaign image

1. A designer starts with a blank canvas and creates the current composition.

2. The designer places a product photograph, logo, texture, and AI-generated illustration. Each becomes a componentOf ingredient; each placement action references the correct assertion.

3. Components with existing Content Credentials bring their manifests and validation results. Manifestless components receive appropriate identifiers, formats, thumbnails, and cautious source descriptions.

4. The final manifest signs the relationships and actions but does not claim that every component has equal prominence, shared ownership, or the same level of trust.

3. Generative media service

1. A user submits a prompt, reference image, and model-selection request. The service decides which inputs can be safely represented in public provenance.

2. The prompt and model are recorded as inputTo ingredients. The reference image may be inputTo if it guides computation or componentOf if it is directly composited into the output.

3. Sensitive prompt text remains in a private evidence record, while the public ingredient uses a data type, hashed reference, or summarized description consistent with policy.

4. The output manifest records creation, source type, optional AI disclosure, ingredients, hard binding, and signature. The provenance explains the declared workflow without pretending to expose every hidden model dependency.

Security and privacy considerations

Ingredients expand the attack and privacy surface of a Content Credential. They can bring external manifests, thumbnails, free text, URLs, data files, models, prompts, datasets, and deep recursive graphs into the validation and presentation path. Treat every ingredient and referenced resource as untrusted input.^[8]

The practical objective is not maximum disclosure. It is enough structured provenance to answer the intended question without exposing data that creates greater harm than benefit. The companion article C2PA Security: Threats, Attacks, and Failure Modes covers the broader threat model, while C2PA Implementation Guide covers production controls.

Implementation recommendations

• Write v3, read legacy versions. Generate c2pa.ingredient.v3 for new credentials and preserve explicit compatibility for v1 and v2.
• Model relationships before fields. Decide whether an item is a parent, component, or computational input before choosing actions, labels, or UI wording.
• Construct actions and ingredients together. Generate and validate their hashed references in one transaction rather than patching them independently.
• Validate at import time. Record complete success, informational, and failure results before allowing the ingredient into a signed workflow.
• Require an explicit decision on failed provenance. Warn the actor and preserve the decision when an invalid or untrusted ingredient is accepted.
• Copy lineage carefully. Deduplicate manifests, handle redaction-aware conflicts, retain unknown compatible structures, and preserve authoritative source files separately.
• Separate public and private evidence. Do not publish raw prompts, confidential documents, personal data, or proprietary model details by default.
• Treat external data as hostile. Enforce safe-fetch policies, hashes, size limits, media-type checks, isolation, and retention controls.
• Present recovery honestly. Keep soft-binding discovery distinct from exact hard-binding validation and show the algorithm used.
• Version the ingredient policy. Record which fields, input classes, disclosure rules, and validation thresholds applied to every signing operation.
• Test graph-scale behavior. Include shared ancestors, redactions, inaccessible manifests, duplicate identifiers, deep lineage, large datasets, and malicious inputs in conformance and security testing.
• Verify the final output. Reopen the signed asset, traverse its ingredients, compare recorded validation results, and confirm that policy and trust outcomes match expectations.

The open-source CAI SDKs expose ingredients as first-class objects even though the technical specification defines them as assertions. That abstraction can simplify application code, but the production system still needs to preserve the underlying labels, relationships, references, versions, and validation semantics.^[7]

Common misunderstandings

What ingredients can establish - and what they cannot

When the current manifest validates, an ingredient assertion can provide cryptographic evidence that the signer issued a claim containing a particular relationship, identifier, manifest reference, validation record, data reference, thumbnail reference, source-type declaration, or recovery signal. If copied ingredient manifests also validate, a consumer can traverse the separately signed provenance that those earlier systems issued.

Ingredients do not independently prove that every input was disclosed, that a relationship was honestly classified, that a prompt caused a specific output, that a model actually executed, that source material was lawfully used, that a component is authentic, that the history is complete, or that the final content is factually true. Those conclusions depend on trust in the signers and systems, identity and attestation evidence, source availability, legal analysis, and the decision context.

For a fuller treatment of interpretation limits, see What C2PA Proves - and What It Does Not Prove.

The simplest mental model

• Actions are the verbs: they describe operations.
• Ingredients are the related nouns: they identify the assets and data involved.
• parentOf means the current asset derives from the ingredient.
• componentOf means the ingredient is included in the current composition.
• inputTo means the ingredient participated in a computational process.
• Ingredient manifests preserve earlier signed provenance; they do not automatically preserve the original source bytes.
• validationResults preserve what the importing claim generator found and acknowledged at ingestion time.
• Soft-binding fields disclose recovered candidate provenance, not exact validation of a transformed ingredient.
• A provenance graph is valuable because it makes relationships inspectable; it remains only as complete and honest as the participating workflow.

Used carefully, ingredient assertions let Content Credentials describe where a current asset came from, what it contains, and which data helped produce it. Their strength is not that they collapse a complex workflow into one origin label. It is that they preserve distinct, signed relationships and give validators enough structure to follow the lineage while keeping uncertainty visible.

Sources and notes

Notes are limited to precise structural, version-specific, implementation, and security claims.

[1] C2PA Technical Specification 2.4, section 18.16, “Ingredient.” Current c2pa.ingredient.v3 structure, fields, labels, deprecated versions, and validation records.

[2] C2PA Technical Specification 2.4, ingredient relationships and action requirements. parentOf, componentOf, inputTo, the one-parent rule, c2pa.opened, and c2pa.placed.

[3] C2PA Technical Specification 2.4, existing-manifest copying and ingredient validation. Deduplication, redaction-aware references, validationResults, ingredientDeltas, and acknowledged failures.

[4] C2PA Technical Specification 2.4, ingredient data and presentation fields. Descriptions, data, multi-file ingredients, informationalURI, thumbnails, and source classifications.

[5] C2PA Technical Specification 2.4, recursive ingredient validation, soft-binding lookup, and update manifests. Traversal, recovery fields, unknown provenance, and parentOf update chains.

[6] C2PA Implementation Guidance 2.4, ingredient and AI/ML workflow examples. Parent assets, placed components, prompts, models, recovered provenance, and disclosure choices.

[7] Content Authenticity Initiative documentation, “Reading ingredients.” SDK treatment of ingredients, copied manifests, and authoring workflows.

[8] C2PA Security Considerations 2.4, secure parsing, privacy, and remote-resource handling. Defensive treatment of ingredient manifests, data, links, and recursive graphs.