Provenance Data Model

The model is fundamentally built on the three core classes defined by the W3C PROV standard:

• Entity: The digital asset itself, representing a specific state at a point in time (e.g., a raw photo, an edited JPEG).
• Activity: An action or process that generates or modifies an Entity (e.g., crop, resize, color correction).
• Agent: The actor—human or software—bearing responsibility for an Activity (e.g., a photographer, an editing application).

These are connected by relations like wasGeneratedBy, wasAttributedTo, and wasDerivedFrom to form a directed acyclic graph of the asset's complete lineage.

Each state of an Entity is uniquely identified by a cryptographic hash of its binary content. This creates an immutable, tamper-evident chain:

• A new Activity produces a new Entity with a new hash.
• The new Entity's provenance record points back to the hash of the input Entity via a wasDerivedFrom relation.
• Any retroactive modification to a prior asset state invalidates all subsequent hashes in the chain, making unauthorized edits immediately detectable during verification.

The model moves beyond simple string names to cryptographically verifiable identities. An Agent is not just a label but is linked to a digital identity:

• An Identity Assertion binds the Agent to a verified real-world identity, often via an X.509 certificate issued by a trusted Certificate Authority.
• The wasAttributedTo relation connects an Entity to this strong identity, providing non-repudiable attribution.
• This allows a validator to answer not just what happened, but who was responsible, based on a trusted public key infrastructure.

Complex digital assets are rarely created from a single source. The provenance model supports composition through Ingredient Assertions:

• An Ingredient is an Entity that was used as input to an Activity that generated a new, composite Entity.
• For example, a final marketing graphic's provenance graph would show separate ingredient nodes for the background stock photo, the overlaid logo, and the text font file.
• This creates a precise, machine-readable edit history graph that traces every component back to its origin, enabling granular rights and authenticity verification.

To ensure machine-readability and interoperability across different tools and platforms, all provenance claims are structured as formal Assertions with defined schemas:

• A Content Credential Schema defines the required fields, data types, and validation rules for a specific type of assertion (e.g., c2pa.actions, stds.schema-org.ClaimReview).
• This allows a Validator Engine to programmatically parse and verify claims without ambiguity.
• Standard schemas prevent proprietary lock-in and ensure that a provenance graph generated by one software vendor can be fully understood and validated by another.

A critical feature is the ability to prove that a specific state of an asset existed before a certain moment in time. This is achieved through Trusted Timestamping:

• A hash of the Entity and its assertions is sent to a Timestamp Authority (TSA).
• The TSA cryptographically binds this hash to a precise, verifiable UTC timestamp and signs the token.
• This counters backdating attacks and provides irrefutable proof of existence, which is essential for copyright priority and journalistic integrity claims.

A sequential chain of hashes linking each version of an asset to its predecessor. When a new edit occurs, the system hashes the previous manifest and the new content state together. This creates a verifiable edit history where altering any past version immediately invalidates all subsequent hashes in the chain. It is the core mechanism for ensuring tamper-evident metadata in a provenance data model.

A structured, digitally signed statement within a provenance manifest that makes a specific claim about the content. Assertions are the atomic units of the data model:

• Creative Assertions: Claim authorship or creation date.
• Action Assertions: Describe specific operations like resizing or color correction.
• Ingredient Assertions: Document source media used in a composite asset. Each assertion is cryptographically signed to ensure non-repudiation of the claim.

Two distinct strategies for attaching the provenance data model to an asset:

• Hard Binding: The cryptographically signed manifest is embedded directly into the binary structure of the file (e.g., using JUMBF in a JPEG header). This ensures the provenance travels inseparably with the asset.
• Soft Binding: The manifest is stored externally as a sidecar file or cloud URL, referenced by a content hash. While more flexible for legacy systems, it is vulnerable to separation during transmission.

A curated, cryptographically signed list of trusted issuers, Certificate Authorities (CAs), and validators. When a Validator Engine processes a content credential, it cross-references the signer's identity against this list to determine trustworthiness. This prevents a scenario where anyone with a self-signed certificate can generate a 'valid' signature, anchoring the provenance data model to a known, auditable trust framework.

A visual or programmatic representation of the provenance chain, typically structured as a Directed Acyclic Graph (DAG). Unlike a simple linear chain, a graph can represent complex derivations where multiple Ingredient Assertions (source images, audio clips) are composited into a single final asset. This graph structure allows verifiers to trace the lineage of every pixel or sample back to its origin.