C2PA Actions Explained

C2PA actions describe what a claim generator says happened to an asset at a particular stage of its provenance. An action can record that content was created, opened, cropped, edited, placed into a composition, transcoded, translated, watermarked, published, or affected in another defined way. Actions are collected inside an actions assertion, which becomes part of the signed C2PA manifest.^[1]

Actions are not a perfect event log. Their order is not generally guaranteed to be chronological, their optional time values are not trusted timestamps, and a signed action does not prove that the described operation really occurred exactly as stated. What C2PA does provide is a tamper-evident record of the actions that the claim generator chose to assert, together with context such as software, ingredients, regions, and digital source types.

This guide focuses on the current c2pa.actions.v2 assertion in C2PA 2.4. For the broader structure around actions, see C2PA Assertions Explained and C2PA Manifests Explained.

Actions are the verbs of provenance

An assertion is a structured statement. An action is one kind of statement inside the actions assertion: it names an operation and may add context about when it occurred, which software or hardware performed it, which part of the asset changed, which ingredients were involved, and why the operation was performed.

The distinction matters because an action does not stand alone. A c2pa.placed action should point to the ingredient assertions for the components that were placed. A c2pa.watermarked.bound action should be associated with the soft-binding assertion describing the watermark. A c2pa.redacted action points to the assertion removed from earlier provenance. The action names what happened; other assertions carry the structured evidence or related objects.

Each C2PA manifest represents one signed provenance statement from one claim generator at one stage of an asset workflow. Traversing actions across ingredient manifests can reveal a broader history, but it does not turn the collection into a guaranteed, complete, or centrally ordered ledger.

A standard manifest must contain an actions assertion

C2PA 2.4 requires at least one actions assertion in the created_assertions array of every standard manifest. This is a current-manifest requirement: the claim generator is responsible for stating how the new asset representation began.

The first action depends on the origin of that representation:

• Created from a blank or newly generated state. The first action must be c2pa.created. It must include an appropriate digitalSourceType describing the nature of the asset at inception, such as digital capture, trained algorithmic media, or an empty canvas.
• Derived by opening an existing parent asset. The first action must be c2pa.opened. It must reference exactly one current-manifest ingredient whose relationship is parentOf.

Across the full set of actions assertions in the manifest, there may be no more than one action whose type is either c2pa.created or c2pa.opened. The rule keeps the manifest from presenting two incompatible starting points for the same asset representation. Update manifests are governed by a different, restricted rule set discussed later.^[1]

The current assertion is c2pa.actions.v2

C2PA defines two actions-assertion labels. The original c2pa.actions form is deprecated for new writing, while c2pa.actions.v2 is the current model. Validators and readers still need to understand the legacy form because older Content Credentials remain in circulation.^[2]

Version 2 is not merely a different serialization. It makes repeated context more compact, supports multiple software agents, allows action-specific regions, provides clearer completeness semantics, and gives actions a general way to point to related non-ingredient assertions.

Anatomy of a v2 action

A v2 actions assertion contains an actions array and may also contain templates, a shared software-agent list, assertion metadata, and the allActionsIncluded flag. Each action item begins with an action name and may add the fields below.^[2]

Standard action vocabulary

C2PA supplies standard action names so different tools can express common operations consistently. The vocabulary is intentionally broad: it supports images, video, audio, documents, structured text, and fonts. A claim generator should prefer a specific standard action when one accurately describes the event, use c2pa.edited only when a more precise term is unavailable, and use a custom namespaced action when the operation is genuinely product- or domain-specific.^[3]

Creation, composition, and ingredient actions

Editorial and content-changing actions

Non-editorial, delivery, and governance actions

The older c2pa.color_adjustments, c2pa.watermarked, c2pa.copied, c2pa.formatted, c2pa.version_updated, c2pa.printed, c2pa.managed, c2pa.produced, and c2pa.saved values are deprecated. New claim generators should not write them, although validators may encounter them in older manifests.

Font-specific actions

C2PA also defines a separate font. namespace for font assets. These actions describe subsetting, variable-font instantiation, hinting, character changes, feature changes, merging, and generalized font editing.

Custom actions

The standard vocabulary cannot anticipate every specialized process. A product may define a custom action using an entity-specific name such as com.example.superResolution or ai.unfurled.pipeline-normalization. A custom action should have stable semantics, a clear description, documented parameters, and a namespace controlled by the organization defining it. It should not reuse the c2pa. namespace or invent a near-duplicate of an existing standard action.

Actions and ingredients must agree

Actions describe operations; ingredient assertions identify the assets or inputs involved. C2PA validates several important relationships between the two. A claim generator cannot simply write "opened" or "placed" without linking that statement to the appropriate ingredient assertion.^[4]

The ingredients field in an action contains hashed references to ingredient assertions. It does not point directly to arbitrary filenames or URLs, and it does not replace the ingredient assertion itself. The ingredient carries the relationship, identifiers, available prior manifests, validation results, and other provenance about the contributing asset.

When an ingredient arrives without an embedded manifest, the claim generator may perform a soft-binding lookup. If a candidate manifest is recovered, the ingredient records that soft binding was used and preserves the resulting validation status. Recovery does not convert a perceptual match into an exact hard-binding match.

Digital source types add origin semantics

An action name and a digital source type answer different questions. The action says what operation occurred. The digitalSourceType says what kind of source or resulting content the operation represents. The value comes from the IPTC Digital Source Type vocabulary or from a small number of C2PA-specific terms.

For AI workflows, source type is only one layer. Actions can describe creation or editing, ingredients can identify inputs, and the C2PA 2.4 AI Disclosure assertion can carry structured model and human-oversight information. See C2PA for AI-Generated Content for the full model.

Completeness, order, and time

Three details prevent actions from being misread as a definitive timeline.

The array is not generally chronological

Except for the required starting position of c2pa.created or c2pa.opened, C2PA does not define the order of actions in the array as execution order. A consumer should not infer that the second listed action happened after the first merely because of its array position.

The when field is not trusted time

The optional when field can help a workflow present or sort actions, but it is a simple asserted date and time. It is not equivalent to a trusted time-stamp issued by a Time Stamping Authority. It may be missing, inaccurate, copied from a device clock, or supplied by an untrusted caller.

allActionsIncluded is a signed completeness claim

When allActionsIncluded is true, the claim generator states that all actions performed on the asset are described in the actions assertion or assertions. When it is false, additional unrecorded actions may have occurred. An omitted value is interpreted like false.^[2]

The field should be interpreted within the scope of that manifest and claim generator. It does not prove that earlier provenance was complete, that another application did not modify a source before ingestion, or that the signer is honest. It is useful because it makes the generator take an explicit position on completeness, not because completeness can be independently reconstructed from the flag alone.

Repeated and related actions

The multipleInstances parameter can indicate that the same action occurred multiple times with the same settings. If it is absent, the number of occurrences may be unknown. The related field can group actions that belong together, usually because they happened as part of one operation. A related action inherits the primary action context and supplies only the fields that differ.

Templates and multiple software agents

Action templates reduce repetition in a v2 assertion. A template can provide shared description, digital source type, software-agent information, or custom template parameters for every action with the same name. A special * template can apply shared values to all actions. Values written directly on an action override the corresponding template values.

Templates are a storage and presentation mechanism, not a separate provenance event. A consumer must merge the applicable template values with the action before presenting or evaluating it. If several templates apply, their values are combined in the order defined by the assertion, with action-level values taking final precedence.

When several tools or components perform actions, the assertion can define a shared softwareAgents array and let each action use a zero-based softwareAgentIndex. This avoids repeating the same structured agent record. It also makes an important distinction visible: a plug-in, model runtime, editing application, camera subsystem, and claim generator can all be different pieces of the workflow.

Regions, related assertions, and supporting evidence

A v2 action can use the changes field to identify one or more regions of interest affected by the operation. This can describe a rectangle in an image, a time range in audio or video, a frame range, or another format-appropriate region. Region data helps a consumer understand scope, but it should not be presented as pixel-perfect proof unless the generating tool can support that precision.

The relatedAssertions parameter gives an action a general-purpose way to point to other assertions in the same manifest. It is designed for supporting information that is neither another action nor an ingredient. For example:

• A c2pa.watermarked.bound action can reference the soft-binding assertion describing the inserted watermark.
• An editing action can reference an external-reference assertion containing a cryptographically hashed process report.
• An action can point to a domain-specific assertion carrying measurements or evidence related to that operation.

Entries in relatedAssertions cannot point to another actions assertion or an ingredient assertion. Ingredient relationships belong in the action parameters designed for ingredients.^[6]

Actions in update manifests are deliberately restricted

An update manifest adds restricted provenance information without changing the content covered by the earlier standard manifest. Because no new hard binding is created, an update manifest cannot claim ordinary content-changing actions. C2PA 2.4 permits only four action types in an update manifest:^[5]

• c2pa.edited.metadata - metadata changed without changing the protected digital content.
• c2pa.opened - the asset was opened, including the special open-and-resave case defined by the specification.
• c2pa.published - the asset was released to a wider audience.
• c2pa.redacted - an assertion from an earlier manifest was redacted.

An update manifest containing any other action is malformed because actions such as cropping, filtering, transcoding, resizing, watermark insertion, or content editing imply that the protected representation changed. Those operations require a new standard manifest and new hard binding.

The update manifest still contains exactly one parentOf ingredient pointing to the manifest it extends. For more on the structural distinction, see C2PA Manifests Explained.

Actions can describe asset renditions

Distribution systems routinely create renditions: a high-resolution master becomes a WebP thumbnail, a video master becomes several bitrate variants, or a document becomes a preview. C2PA uses action combinations to let a signer express the intended nature of that transformation.

When an actions assertion contains only c2pa.published, c2pa.transcoded, and c2pa.repackaged, it signals that the signer is asserting no editorial changes occurred between the ingredient asset or assets and the current rendition. A single parentOf ingredient strengthens the interpretation that the current asset was derived directly from that parent.^[5]

This remains a signer assertion, not an independent forensic guarantee. A validator can check the action structure, references, signatures, and current hard binding, but it cannot reconstruct every transformation performed outside the recorded pipeline.

Watermarking actions must distinguish bound and unbound uses

The deprecated c2pa.watermarked action was too ambiguous. C2PA 2.4 distinguishes two uses:

• c2pa.watermarked.bound means the invisible watermark creates a C2PA soft binding used to help recover provenance. A corresponding soft-binding assertion is required and should be linked through relatedAssertions.
• c2pa.watermarked.unbound means a watermark was inserted for another purpose and does not create a C2PA soft binding.

The distinction prevents a consumer from assuming that every watermark can resolve a Content Credential. It also helps operators separate C2PA recovery identifiers from rights-management, audience-measurement, or platform-specific watermark systems. See C2PA vs. Watermarking and C2PA Hard Bindings and Soft Bindings.^[6]

How validators evaluate actions

A validator does not decide whether an action was sensible or factually accurate. It checks whether the assertion is structurally allowed, cryptographically protected, and internally consistent with the references it contains. Important checks include:^[4]

• The assertion has a non-empty actions array and uses a supported or syntactically valid entity-specific action name.
• c2pa.created or c2pa.opened appears only in the required first position and no more than once across the manifest.
• c2pa.opened, c2pa.placed, and c2pa.removed resolve to ingredient assertions with the required relationships.
• A redaction action resolves to the assertion it claims was redacted and includes the required reason.
• Software-agent icons and related-assertion references resolve and validate correctly.
• A bound-watermark action has the required soft-binding assertion.
• The action set is permitted for the manifest type, especially for update manifests.
• The actions assertion hash matches the value recorded in the signed claim.

The actions assertion itself cannot be redacted from an earlier manifest. This is a strong reason to keep sensitive details out of free-text descriptions and custom parameters. If a workflow needs removable supporting data, it can place that data in a separate assertion and link it through relatedAssertions when appropriate.

A consumer should preserve structured validation outcomes rather than collapsing all failures into a generic "invalid action" result. Ingredient mismatch, malformed references, disallowed update actions, unresolved related assertions, and claim-hash failures have different operational and security implications. For the complete validation model, see How C2PA Verification Works.

A practical workflow: a published newsroom graphic

Consider a newsroom design tool that creates a social graphic from a blank canvas, a camera photograph, an AI-generated illustration, a publisher logo, and text. The workflow can represent the asset in several stages.

1. Create the composition. The tool starts from an empty canvas, so the first action is c2pa.created with the C2PA empty digital source type.
2. Place the source components. The photograph, illustration, and logo become componentOf ingredients. Separate c2pa.placed actions reference the corresponding ingredient assertions.
3. Describe editorial operations. The tool records c2pa.cropped for the photograph, c2pa.adjustedColor for tone changes, and c2pa.addedText for the headline and caption. Region data can identify which area each action affected.
4. Identify AI involvement. The illustration ingredient carries its own provenance. Its generating manifest may contain c2pa.created with a trained-algorithmic source type and an AI Disclosure assertion.
5. Insert a durable marker. If the publisher inserts an invisible watermark for C2PA recovery, the standard manifest records c2pa.watermarked.bound and links the corresponding soft-binding assertion.
6. Sign the final representation. The resulting standard manifest contains the actions assertion, ingredients, hard binding, claim, and claim signature. The pipeline validates the exact published file before release.
7. Create a delivery rendition. A downstream service that produces a lower-resolution WebP issues a new standard manifest beginning with c2pa.opened for the parent asset and records the relevant resizing and transcoding actions.
8. Record publication without changing content. A publisher can issue an update manifest containing c2pa.published if the protected content remains unchanged.

The resulting provenance does not need one monolithic action log. Each participating claim generator signs the actions it is responsible for, while ingredient relationships connect the separately signed stages into a graph.

Implementation recommendations

• Write v2, read both versions. Generate c2pa.actions.v2 for new credentials and preserve compatibility with legacy c2pa.actions when reading.
• Map product events through a versioned policy. Do not let individual teams invent action names independently. Maintain a tested mapping from internal operations to standard or approved custom actions.
• Capture facts at operation time, normalize before signing. Recording the event near its source improves accuracy, while a final policy step removes unsupported, redundant, or sensitive fields before the claim is signed.
• Treat ingredient references as required data relationships. The action and ingredient assertion should be constructed together, not patched independently after the fact.
• Use allActionsIncluded conservatively. Set it to true only when the claim generator can account for the complete operation set in its scope.
• Keep when values informational. Use UTC where possible, preserve the source of the clock value, and do not present it as trusted time.
• Separate software, signer, and human identity. A softwareAgent record should identify the performing software or hardware, not stand in for a person or organization.
• Keep custom actions stable and documented. Use a controlled namespace, version semantics carefully, and publish a machine- and human-readable definition for consumers.
• Minimize irreversible details. Because actions assertions cannot be redacted, avoid secrets, unnecessary personal data, raw prompts, and internal identifiers in descriptions or parameters.
• Validate the finished output. The signing pipeline should reopen the released asset and check action structure, references, signature integrity, hard binding, and policy requirements.

A production implementation should treat actions as policy-controlled claims, not as a free-form analytics stream. The surrounding architecture is covered in the C2PA Implementation Guide.^[7]

Common misunderstandings

What actions can establish - and what they cannot

When the manifest validates, an actions assertion can provide cryptographic evidence that a signer issued a claim containing a particular set of action statements, software-agent details, ingredient references, source-type declarations, regions, reasons, and parameters. The claim protects the exact encoded assertion against undetected modification.

Actions do not independently prove that every operation occurred, that the action list is complete, that the described software was secure, that the signer was honest, that a person shown in the workflow approved the action, or that the content is factually true. Those conclusions depend on trust in the signer and claim generator, the security of the workflow, identity and attestation evidence, and the purpose for which the provenance is being interpreted.

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

The simplest mental model

• Actions are verbs. They describe operations performed on an asset.
• Ingredients are the related nouns. They identify parents, components, and computational inputs involved in those operations.
• The first action explains how the representation began. A standard manifest starts with either created or opened.
• Context makes an action useful. Software agents, digital source types, regions, parameters, and related assertions explain the operation more precisely.
• Completeness and time remain claims. allActionsIncluded and when values should not be presented as independently verified facts.
• Manifest type constrains the vocabulary. Update manifests can record only restricted non-content-changing actions.
• Validation checks consistency, not truth. A validator verifies structure, references, hashes, signatures, and permitted combinations.

Used carefully, C2PA actions give digital content a portable and machine-readable account of how each signed representation was created or handled. Their value comes from precise vocabulary, accurate relationships, restrained claims, and interfaces that show both what was recorded and what remains unknown.

Sources and notes

[1] C2PA Technical Specification 2.4, “Actions” and “Mandatory presence of at least one actions assertion.” These sections define the purpose of actions, the current and legacy assertion labels, and the required created-or-opened starting rules for standard manifests.

[2] C2PA Technical Specification 2.4, “All actions included,” “Fields in the actions assertion,” and “Action Templates.” These sections define allActionsIncluded, time, software-agent, source-type, region, parameter, template, related-action, and shared-agent behavior.

[3] C2PA Technical Specification 2.4, “List of pre-defined actions,” “List of font actions,” and “Deprecated Actions.” See also the IPTC Digital Source Type vocabulary.

[4] C2PA Technical Specification 2.4, “c2pa.actions validation” and the ingredient-assertion requirements. These rules connect opened, placed, removed, transcoded, repackaged, and redacted actions to the correct assertions and validation status codes.

[5] C2PA Technical Specification 2.4, “Types of Manifests” and “Asset Renditions.” These sections restrict update-manifest actions and describe how published, transcoded, repackaged, and parent relationships can signal a non-editorial rendition.

[6] C2PA Technical Specification 2.4, “Related Assertions,” “Watermarking,” and “Soft Binding Lookup.” These sections distinguish bound and unbound watermarking, define action-to-assertion references, and describe provenance recovered through soft bindings.

[7] Content Authenticity Initiative open-source documentation, “Writing assertions and actions” and “Reading legacy manifest data.” These guides show how current SDKs expose action authoring while preserving read compatibility with v1 and v2 manifests.

[8] C2PA Implementation Guidance 2.4, “Assertions,” and C2PA Security Considerations 2.4, “Protection of personal information.” These documents provide non-normative guidance on assertion design, privacy, redaction, and secure workflow interpretation.