C2PA Assertions Explained

Assertions are the parts of a C2PA manifest that carry its actual provenance meaning. They can say that an image was captured, a video was transcoded, a document was edited, an AI model contributed to an output, another asset was used as an ingredient, or selected metadata was intentionally included in the signed record.

An assertion is not signed in isolation. It is stored in the manifest's assertion store and referenced by cryptographic hash from the claim. The claim signature protects that claim, which makes the exact referenced assertion data tamper-evident. C2PA also distinguishes assertions created by the claim generator from assertions gathered from other parts of a workflow, so readers can understand who is being credited with each statement.^[1]

Assertions are the vocabulary of provenance

A manifest provides the container, claim, signature, and asset binding needed to make provenance verifiable. Assertions provide the vocabulary used inside that structure. Without them, a manifest could establish that something was signed but would say very little about what happened to the asset.

This is why C2PA assertions cover several different kinds of information. Some describe processes, such as capture, editing, publication, or watermarking. Some identify contributing assets and computational inputs. Others carry selected metadata, thumbnails, content bindings, model disclosures, repository receipts, or references to evidence stored elsewhere.

The word assertion is deliberate. It describes a statement being made, not an automatically proven fact. A signed assertion can show that a particular signer issued or preserved a particular statement and that the statement has not changed. It cannot, by cryptography alone, establish that the statement corresponds perfectly to events in the physical world.

How an assertion becomes part of a signed manifest

At a high level, the claim generator performs the following sequence:

1. Create or gather the assertion data required for the workflow.

2. Assign each assertion a unique, versioned label and store it in the manifest's assertion store.

3. Add a hashed URI reference to the assertion in either the claim's created_assertions list or its gathered_assertions list.

4. Finalize and digitally sign the claim.

5. Validate the completed manifest by resolving the references, recomputing the hashes, and applying assertion-specific rules.

The hashed reference is important. It contains both a location for the assertion and a cryptographic hash of the assertion structure. A validator resolves the location, calculates the hash again, and compares the result with the value recorded in the claim. If the assertion was changed, replaced, or removed, the comparison fails.

The claim also commits to the set of assertions it contains. An assertion referenced by the claim must be present in the same manifest's assertion store, while an assertion present in the store but omitted from both the created and gathered lists is treated as undeclared. This prevents someone from silently adding unclaimed material to a signed manifest and presenting it as though it were covered by the signature.^[1]

The signature therefore protects assertions indirectly but precisely: it protects the claim; the claim records the assertion references and hashes; and those hashes protect the referenced assertion data. The hard-binding assertion extends this chain to the protected asset content.

Created assertions and gathered assertions

Created and gathered assertions receive the same hash-based integrity checks, but they communicate different attribution. That distinction is one of the most important parts of interpreting a current C2PA claim.

Suppose an editing service receives a hardware-generated capture statement from a device component. The service may create its own actions assertion describing the export, while including the device statement as gathered information. Both records become tamper-evident, but the manifest does not falsely present the editing service as the originator of the device statement.

A gathered assertion is not a weaker form of cryptographic protection. It is a more careful form of attribution. Its hash is still validated, and it still belongs to the signed claim. The difference is what the claim says about where the statement came from.

Labels, versions, and multiple instances

Every assertion has a label. Standard C2PA assertion labels begin with the c2pa namespace, while extensions use an entity-specific namespace, normally based on a domain name. Examples include c2pa.actions.v2, c2pa.ingredient.v3, and a hypothetical custom label such as ai.unfurled.pipeline-evidence.

The version is part of the label. C2PA can add optional fields to a backwards-compatible schema without changing the label, but a revised or incompatible structure needs an appropriate new version or a new label. Consumers should therefore treat the label as both a semantic identifier and a contract for how the data is encoded.

A manifest may contain several assertions of the same type. Because the claim references assertions by label, each instance must remain unique. C2PA appends a double underscore and an increasing number, producing labels such as c2pa.metadata, c2pa.metadata__1, and c2pa.metadata__2. The version remains before the instance suffix, as in c2pa.ingredient.v3__1.^[2]

Most standardized assertions are encoded as deterministic CBOR, although some use JSON or embedded-file structures. Custom assertions can use supported JUMBF content types appropriate to their workflow. A consumer that does not understand a custom assertion may still be able to verify its hashed association with the claim, but it cannot safely infer the custom assertion's meaning without its schema and semantics.

The assertion families that carry most provenance

The C2PA specification defines many assertion types, but a relatively small group carries most of the provenance that ordinary readers and implementers encounter.

Actions: what happened to the asset?

The actions assertion records edits and other operations affecting the asset or its handling. A current actions assertion uses the label c2pa.actions.v2 and contains an array of action records. Each record identifies the action and may add information such as a description, time, software agent, digital source type, affected region, parameters, or references to related assertions.

Every standard manifest must contain at least one actions assertion in its created assertions. When an asset begins as a new creation, the first action in the first actions assertion is c2pa.created, accompanied by a digitalSourceType describing the nature of the asset at inception. When a workflow opens an existing parent asset for editing, the first action is c2pa.opened and it refers to the corresponding parent ingredient. These requirements do not apply in the same way to update manifests.^[3]

Outside those required starting conditions, the order of entries in an actions array is not guaranteed to be chronological. A consumer should not reconstruct an exact timeline merely from array position. A when field can record when an action occurred, but C2PA describes it as a simple, non-trusted time value rather than a trusted timestamp.

The digitalSourceType field deserves special attention. It classifies the nature of the digital content associated with an action - for example, digital capture, trained algorithmic media, or a composite containing algorithmic media. It is a provenance signal about how content came into being, not a full description of the model, prompt, intent, quality, or truthfulness of the result.

Actions can also connect to other assertions. An action that places an ingredient can reference the relevant ingredient assertion. A watermarking action can reference a soft-binding assertion. Domain-specific actions can use namespaced custom action names and parameters, provided consumers are given enough information to interpret them.

Ingredients: what contributed to the asset?

An ingredient assertion describes an existing asset or data item that contributed to the current asset or to the process that produced it. The current assertion version is c2pa.ingredient.v3. Its central field is the relationship between the ingredient and the current asset:

• parentOf means the current asset is derived from, or is a rendition of, the ingredient.
• componentOf means the ingredient is one component of a composed asset.
• inputTo means the ingredient was used as input to a computational process that created or modified the asset.

An ingredient can identify its format and title, reference a thumbnail, and point to its active manifest and claim signature when provenance is available. The claim generator validates manifest-bearing ingredients as they enter the workflow and records the validation results so later consumers can understand what was known at ingestion time.

If an ingredient has no associated manifest, an ingredient assertion can still identify it and may include a digitalSourceType. A current ingredient assertion cannot use both an active-manifest reference and a direct digital-source-type field, because the ingredient's own manifest is the preferred source for that information when one exists.^[4]

Actions and ingredients work together but answer different questions. An action says what operation took place. An ingredient says what asset or input participated. A c2pa.placed action may point to a logo ingredient; a c2pa.opened action may point to a parent photograph; and a computational action may be accompanied by an inputTo ingredient representing a prompt, model, dataset, or other input.

Metadata: which fields is the signer explicitly asserting?

A metadata assertion promotes selected descriptive information into the signed provenance record. The standard c2pa.metadata assertion uses JSON-LD and permits a defined subset of commonly used metadata properties. Entity-specific metadata assertions can use their own namespaced labels ending in .metadata and represent additional schemas or workflow-specific fields.

This is different from metadata merely existing elsewhere in the asset. A camera model, GPS coordinate, author name, or document title may appear in EXIF, XMP, or another file structure. If that location is covered by the hard binding, a validator can detect later byte changes, but that does not necessarily mean the signer explicitly asserted the semantic accuracy of every field. Putting selected values into a created metadata assertion makes the attribution clearer.

Metadata assertions should be designed with privacy in mind. Location, device, identity, and workflow details can be sensitive. Implementers should include only information that serves the intended provenance purpose and provide controls over disclosure. If a later workflow needs to remove part of a metadata set, it cannot silently edit the original signed assertion; it can use a new manifest and a reduced replacement assertion while declaring the earlier redaction.

Thumbnails, embedded data, and external references

A thumbnail assertion provides an approximate visual representation of an asset at claim creation or of an ingredient at import. It improves recognition and user experience, but it is not the authoritative content binding. A thumbnail can help a person recognize what an assertion refers to while the hard-binding assertion determines whether the manifest matches the protected asset content.

Supporting information can also be placed in embedded-data assertions or referenced externally. An external-reference assertion may use a hash when the remote data must be cryptographically fixed at signing time, or an unhashed location when the information is advisory and may change. The external content is not automatically retrieved as part of ordinary manifest validation; an application fetches it only when its use case requires it.

That separation helps keep manifests manageable, but it creates an important interpretive boundary. The assertion can prove what location was referenced and, for a hashed reference, what data was expected. It cannot guarantee that an external service remains available forever. Unhashed external material should be treated as context rather than as fixed signed evidence.^[5]

Content-binding assertions

Hard and soft bindings are also assertions, even though they play a structural role rather than describing an edit or a creator. A standard manifest contains exactly one supported hard-binding assertion that commits the provenance record to the protected asset representation. Optional soft-binding assertions contain fingerprint or watermark-related information that can help rediscover provenance after embedded metadata is removed.

Because bindings deserve their own detailed treatment, the essential point here is simply that an assertion can be both a statement and a cryptographic mechanism. The claim references and protects the binding assertion in the same general way that it protects actions, ingredients, and metadata.

AI disclosure, digital source type, and identity

C2PA represents AI involvement through several complementary signals rather than one universal AI flag. Actions describe what process occurred. A digitalSourceType can classify the nature of media created or modified by an action. Ingredients can identify prompts, models, datasets, reference assets, or other computational inputs where the workflow chooses to represent them.

C2PA 2.4 adds the c2pa.ai-disclosure assertion for more structured machine-readable transparency. Its model record requires a model type and can include additional model provenance, scientific-domain information, and a structured description of human oversight. The specification explicitly treats this assertion as complementary to actions and digital source type, not as their replacement.

Identity is also separate from ordinary provenance fields. The signing certificate identifies the signer in the C2PA trust model, while human or organizational identity assertions can provide additional identity claims. C2PA recommends the Creator Assertions Working Group specifications for expressing those identities. A consumer should not assume that a creator name inside metadata, a certificate subject, and a separately verified human identity all mean the same thing.^[6]

Assertions can refer to other assertions

Assertions are not isolated records. Many use hashed references to connect related pieces of provenance inside the same manifest. These links allow a consumer to move from a high-level event to the specific evidence or asset relationship that gives the event context.

• An action can reference the ingredient involved in an opening or placement operation.
• An ingredient assertion can reference an ingredient thumbnail and the ingredient's active manifest and claim signature.
• A watermarking action can reference the soft-binding assertion that describes the inserted watermark.
• An environmental or process-evidence assertion can be related to the action it describes.
• A claim-generator icon can be stored as embedded data and referenced by hash.
• An external-reference assertion can point to supporting information kept outside the manifest.

These references should be read as typed relationships, not as a general pile of links. Their meaning depends on the field containing the reference, the label of the target assertion, and the validation rules for the particular assertion type.

Redaction, privacy, and incomplete visibility

Once an assertion is included in a signed claim, it cannot be altered without invalidating its hash. C2PA nevertheless needs a way for later workflows to avoid republishing sensitive information from earlier provenance. Its redaction mechanism allows a later claim generator to remove an assertion from copied ingredient provenance while recording the assertion's URI in the new claim's redacted_assertions list.

Redaction is therefore declared absence, not invisible rewriting. Because the URI includes the assertion label, a consumer can often tell what category of information was removed even when the data itself is unavailable. Actions assertions cannot be redacted because they are considered essential to understanding the history of the asset.

This mechanism does not solve every privacy problem. Provenance data may already have been distributed, copied, indexed, or retained elsewhere. The safer design is to minimize sensitive assertions at creation time, use gathered-versus-created attribution carefully, and treat external evidence and identity data as controlled disclosures rather than default fields.

How a validator interprets assertions

Assertion validation combines general checks with type-specific checks. At a high level, a validator:

1. Reads the claim's created and gathered assertion references.

2. Resolves each referenced assertion within the same manifest, unless the assertion type deliberately points to optional external data.

3. Recomputes the hash and compares it with the value stored in the claim.

4. Checks that the assertion is encoded correctly and that no undeclared assertion has been inserted into the assertion store.

5. Applies the validation rules defined for that assertion type.

6. Returns separate success, informational, and failure results rather than treating every assertion as a single yes-or-no field.

A consumer may be able to validate the integrity of a custom assertion without understanding its business meaning. Conversely, it may understand the fields in an assertion whose hash or structure fails validation, but it should not present those fields as trustworthy provenance. Integrity, interpretation, attribution, and trust are related but distinct questions.

A practical assertion set

Consider an editor who opens a camera photograph, uses generative fill to extend part of the scene, places a separately designed logo, and exports a final promotional image. A well-designed manifest might contain:

• An actions assertion beginning with c2pa.opened, followed by records for the crop or canvas extension, the AI-assisted operation, the logo placement, and the export.
• A parent ingredient for the original photograph, including its earlier manifest and recorded validation results.
• A component ingredient for the logo and, where appropriate, an input ingredient for the model, prompt, or reference material used by the generative process.
• A metadata assertion containing only the title, rights, campaign identifier, and other fields the signer intentionally chooses to state.
• An AI disclosure assertion describing the relevant model type and human oversight.
• A claim thumbnail for recognition in a provenance interface.
• A hard-binding assertion connecting the completed manifest to the exact exported asset.

No single assertion tells the entire story. Together, they separate the process, inputs, selected descriptive information, AI transparency, presentation aid, and cryptographic asset association into records that can be interpreted and validated according to their own purposes.

Common misunderstandings

The simplest mental model

Assertions are the statements that give a Content Credential meaning.

Labels identify the assertion type, version, and instance.

Created assertions are attributed to the signer.

Gathered assertions are protected by the claim but recorded as originating elsewhere.

Actions describe what happened.

Ingredients describe what contributed.

Metadata and disclosures describe selected facts the workflow chooses to state.

Bindings connect the signed provenance to content.

The claim hashes and references the assertions, and the claim signature protects that claim.

Read together, assertions provide a structured account of an asset's creation and handling. Their strongest contribution is not that they eliminate uncertainty, but that they make it possible to distinguish exactly what was stated, who was associated with the statement, whether it was altered, and which questions still require additional trust or evidence.

Sources and notes

Technical source notes are limited to exact structural, normative, or version-specific claims. All linked material is published by C2PA.

[1] C2PA Technical Specification 2.4, sections 6, “Assertions,” 10, “Claims,” and 15.10.3, “Assertion Validation.”

[2] C2PA Technical Specification 2.4, sections 6.2-6.4 on labels, versioning, and multiple instances, and section 18.4, “Standard C2PA Assertion Summary.”

[3] C2PA Technical Specification 2.4, section 18.15, “Actions,” including the required initial actions and digitalSourceType rules for standard manifests.

[4] C2PA Technical Specification 2.4, section 18.16, “Ingredient,” including current v3 relationships and ingredient-validation requirements.

[5] C2PA Technical Specification 2.4, sections 6.7-6.8, 18.13, 18.17, and 18.24 on externally stored data, redaction, thumbnails, metadata, and external references.

[6] C2PA Technical Specification 2.4, section 18.28, “AI Disclosure.” See also the C2PA Human and Organizational Identity Recommendation for identity assertions and profiles.