Action Assertion

An Action Assertion uses a formal, machine-readable schema to describe an edit. It does not just say 'edited'; it specifies the exact action type (e.g., c2pa.cropped, c2pa.color_adjustment) and the parameters used. This structured data allows validators to understand precisely what happened, not just that something happened.

• Action: A unique identifier from a defined vocabulary.
• Parameters: A key-value map of the specific settings (e.g., x: 100, y: 50, width: 800).
• When: A trusted timestamp marking the exact moment of the action.

Every Action Assertion cryptographically identifies the software agent that performed the operation. This is not just a user-friendly name but a verifiable digital identity, often backed by an X.509 certificate. This allows a validator to answer 'What tool made this edit?' with cryptographic certainty.

• Agent Name: The human-readable name (e.g., 'Adobe Photoshop 25.1').
• Agent Identity: A cryptographic claim binding the action to a specific software release.
• Accountability: Links the edit to a specific, auditable tool in the provenance chain.

The Action Assertion is not merely a log entry; it is a digitally signed claim. The software agent's private key signs the assertion, providing non-repudiation. A validator can cryptographically prove that a specific, identified software agent claimed responsibility for the action, and that the assertion has not been tampered with since it was signed.

• Integrity: Any modification to the action's parameters invalidates the signature.
• Non-Repudiation: The identified agent cannot plausibly deny performing the action.
• Trust Chain: The signature is validated against a trust list of known and approved software agents.

Action Assertions are the verbs that operate on the nouns defined by Ingredient Assertions. An Ingredient Assertion documents a source file, and an Action Assertion describes the transformation that turned that ingredient into the next asset in the provenance chain. Together, they form a complete, verifiable edit graph.

• Input: References one or more Ingredient Assertions as the source of the action.
• Output: The action produces a new asset hash, which becomes an ingredient for the next step.
• Lineage: This pairing creates a cryptographically linked, step-by-step edit history.

For an Action Assertion to be universally understood, it must conform to a published Content Credential Schema. This schema defines the required fields, data types, and allowed values for a specific action. This ensures that a validator built by one company can correctly parse and display an action recorded by a completely different software tool.

• Standardized Vocabularies: Prevents a 'Tower of Babel' where 'crop' means different things.
• Machine-Readable: Enables automated validation and policy enforcement.
• Extensibility: Allows for new, custom actions while maintaining a core interoperable standard.

A critical nuance is the distinction between a standard Action Assertion and one that documents generative AI use. While both use the same structural framework, an action like c2pa.generative_fill carries immense semantic weight. It signals a fundamental shift in content creation, not just an edit, and is often a primary target for transparency and labeling requirements.

• Standard Actions: Cropping, resizing, color correction.
• Generative Actions: Insertion, expansion, or inpainting via AI models.
• Policy Trigger: Generative actions are key signals for automated content labeling systems.

A structured, digitally signed statement within a C2PA manifest that makes a specific claim about the content. An Action Assertion is a subtype of Manifest Assertion, distinguished by its focus on describing a transformative operation (e.g., cropping, resizing) rather than a static property. Each manifest assertion is hashed and signed, creating a tamper-evident record that can be cryptographically verified.

Documents a piece of source media used in creating a final composite asset. When an Action Assertion describes a composition operation (e.g., overlaying one image onto another), the Ingredient Assertion identifies the specific source files consumed. Together, they form a verifiable lineage chain showing not just what was done, but to what inputs. This pairing is essential for establishing data provenance in multi-source workflows.

A cryptographic digital signature generated over a set of assertions, including Action Assertions, binding them to a specific identity. The signature ensures:

• Integrity: Any modification to the action description invalidates the signature
• Non-repudiation: The identified software agent or creator cannot deny performing the action
• Trust chain: The signature can be validated against an X.509 certificate and trust list

The abstract graph-based structure (often using W3C PROV) that represents entities, agents, and activities in content creation. An Action Assertion maps to the Activity node in this model, describing a specific operation performed by an agent on an entity. This formal modeling enables machine-readable audit trails and interoperability across different provenance systems, allowing validators to reconstruct the complete edit history graph.

A sequential chain of hashes linking each version of an asset to its predecessor. Each Action Assertion records the hash of the input state and the hash of the output state after the operation. This creates a verifiable edit history where altering any past version or action description immediately invalidates all subsequent hashes in the chain, making unauthorized retroactive edits cryptographically detectable.

A formal, machine-readable definition of the data structure and required fields for an Action Assertion. The schema specifies:

• The action type vocabulary (e.g., c2pa.cropped, c2pa.resized)
• Required parameters (e.g., coordinates, dimensions)
• The software agent identifier format This ensures interoperable validation across different C2PA-compliant tools and platforms.