Assertions and claims

The C2PA specification defines a vocabulary of assertions: structured statements that can appear inside a manifest and be cryptographically sealed by the surrounding claim. Some are mandatory in any valid manifest (the binding assertion linking to the asset bytes). Most are optional but used by convention. A few are custom — defined by vendors or industries to fit specific workflows. This page surveys the standard vocabulary, names the most commonly used assertion types, and explains where the schema is rigid and where it deliberately allows flexibility.

The distinction between assertion and claim is functional. An assertion is the unit of content: an actions list, an ingredient pointer, a binding hash, an EXIF block. A claim is the signed envelope around all assertions in a single manifest: a CBOR-encoded object that references each assertion by URI and hash, signed by the claim generator's certificate. A manifest contains exactly one claim and one or more assertions. The manifest structure page covers the encoding details.

The standard assertion catalog

The C2PA Technical Specification defines a core set of assertion labels under the c2pa.* namespace, plus assertions defined by the Creator Assertions Working Group (CAWG) under cawg.*. Older 1.x manifests also used standards-passthrough labels under stds.*, which the 2.x line consolidated into c2pa.metadata. The most commonly used types as of 2026 are:

Actions

The c2pa.actions assertion records edits performed in the current claim generator. Each action has an identifier and optional parameters; the identifier is drawn from a controlled vocabulary that the spec defines. The most common action identifiers are:

• c2pa.created — initial creation of the asset
• c2pa.opened — asset opened from a previous version
• c2pa.color_adjustments — color, curves, levels modified
• c2pa.cropped — image cropped
• c2pa.resized — image resampled to a new resolution
• c2pa.filtered — non-destructive filter applied
• c2pa.drawing — drawing or painting added
• c2pa.placed — content from another file placed into the asset
• c2pa.removed — content removed (object removal, healing)
• c2pa.repackaged — re-encoded without semantic change
• c2pa.published — exported for publication

The granularity is deliberately coarse. A "color_adjustments" action does not specify which curves were moved. The spec assumes a viewer wants to know the kind of change, not the exact parameters; finer detail can be embedded in a custom assertion if a vendor cares. This is a design trade-off in favor of privacy and against detailed editorial replayability.

Ingredients

An c2pa.ingredient assertion references an earlier asset that contributed to the current one. The reference includes the ingredient's hash, format, optional thumbnail, and a pointer to its manifest if one was preserved. Ingredients are how chains form: each new manifest names its parent and binds to it cryptographically.

An ingredient can be present without its full manifest being available. In that case, the validator records a partial chain and reports that earlier provenance could not be verified. This is the normal state for files that have passed through tools that did not preserve C2PA. The ingredient assertion still records that something was there; it just can't be walked back.

Composite images carry multiple ingredients. A photo collage that uses three source photographs and a generative fill produces a manifest with four ingredient assertions, each independently validatable. Validators report per-ingredient status, allowing a consuming application to surface that one ingredient was AI-generated, another was credentialed by Reuters, and a third was an uncredentialed user upload.

AI-generation assertions

The spec's response to generative AI is not a separate assertion but a field on actions: digitalSourceType, which takes values from the IPTC digital source type vocabulary. A c2pa.created action with a source type of trainedAlgorithmicMedia says the asset was produced by an AI model; compositeWithTrainedAlgorithmicMedia says AI-generated content was combined with other material. The action can also name the software agent (the model or product) that performed it. Adobe Firefly and OpenAI's image generators both record AI generation this way in the manifests they emit.

This signalling has gained granularity over the 2.x spec line. Actions can now carry regions of interest, so a manifest can indicate that the entire asset is AI-generated, that specific regions were changed, or that AI was used in an assistive capacity (upscaling, inpainting). This last distinction matters editorially: an image upscaled by AI is not the same as one generated by AI, and the spec lets the producer make the distinction in a structured way.

The training-mining assertion is separate and carries permissions for AI training use. It was c2pa.training-mining in the 1.x spec; C2PA 2.0 removed it, and it now lives on as cawg.training-mining in the CAWG specifications. A producer can mark their asset as allowed, not allowed, or constrained for data mining, AI training, and generative training separately. The assertion does not bind training operators legally — that depends on jurisdiction — but it does provide a machine-readable signal that compliant operators can honor. The EU AI Act's training-data transparency obligations, which intersect with this assertion, are covered on the EU AI Act page.

Identity and the identity assertion

The core C2PA spec identifies the signer (through its X.509 certificate) and the claim generator, not the person behind the content. Individual identity is handled by the CAWG identity assertion (cawg.identity), which binds a named actor to the manifest with its own signature — either a credential the actor holds or an attestation from an identity claims aggregator. Adobe's implementation lets creators attach verified names and linked social media accounts this way.

Identity assertions are optional and contentious. They enable a "who took this" check in addition to "what was done to it," which is useful for editorial accountability but raises surveillance concerns. The privacy page covers the trade-off in detail. As of 2026, most consumer-facing C2PA pipelines default to including only organizational identity (the camera maker, the editing software), with personal identity off by default and opt-in.

Custom assertions

The spec allows custom assertions under namespaces other than c2pa.* and stds.*. A wire service can define com.reuters.editorial_approval with its own schema; a forensic tool can define com.forensics.ela_result. Validators handle unknown assertions by reporting their presence without interpreting them. This extensibility has been used sparingly so far — most production deployments use only the standard vocabulary — but the room is there.

The redaction protocol

Editorial workflows sometimes require removing content from a manifest — a PII field captured at the camera, a location the publisher does not want public, an internal tool name. C2PA defines a redaction mechanism: when a new manifest is created, assertions in an ingredient's manifest can be removed, the new claim lists them in its redacted_assertions field, and a c2pa.redacted action records that the redaction occurred, preserving the chain's validity. A validator reading a redacted manifest sees that something was removed but cannot recover what.

The protocol is precise enough that auditors can distinguish authorized redaction from tampering. An assertion deleted via the redaction protocol leaves a structured trace; an assertion deleted by editing the file without the protocol breaks the claim signature. This is one of the cleaner features in the 2.x line and a model for how the spec handles tension between transparency and legitimate privacy needs.

Schema flexibility and the long tail

The standard vocabulary covers the high-volume cases. The schema-org passthrough handles editorial metadata. The EXIF and IPTC passthroughs handle camera and wire-service metadata. The custom-assertion mechanism handles the long tail. For a working implementation, the choice of which assertions to emit is more important than the choice of which fields to populate inside them: validators report whatever is there, and end users interpret a manifest by what it does and does not say.

Where the field is moving

The 2.x spec series has been adding assertion types steadily, particularly around AI generation and training data. The next set of additions, likely landing in 2026 and 2027, includes more structured assertions for live-broadcast workflows, for evidentiary chain-of-custody pipelines in legal contexts, and for human-rights-documentation use cases where C2PA might attest to capture by a trained witness. Whether these specialized assertions stabilize as standard vocabulary or remain in the custom-namespace long tail will depend on how broadly the relevant workflows adopt them.