How to read a Content Credentials record: claim generator, actions, ingredients, signature
A Content Credentials record holds a signed claim about a file. Read four parts: the claim generator (the software that made the claim), the actions (what was done to the file), the ingredients (earlier files it came from) and the signature (who signed, and whether the record is unchanged since signing). None of them proves the statements are true.
What is inside a Content Credentials record?
The C2PA Specification 2.2 calls the whole record a C2PA Manifest. It holds assertions, one claim and a claim signature. An assertion is a statement about the file. The claim is a signed structure that points to those assertions. The C2PA explainer calls "Content Credential" the preferred non-technical term for a manifest.
| Part | What it is | What it does not tell you |
|---|---|---|
| Claim generator | The software or hardware that generated the claim. | Who the person was. |
| Actions | Operations performed on the file, such as created or opened. | Every operation, unless the record says the list is complete. |
| Ingredients | Earlier or component files the file was made from. | That the earlier file's own data can be re-checked later. |
| Signature | The proof that the record is unchanged since signing, made with a certificate. | That the statements inside are true. |
What is the claim generator?
The specification says the claim generator is the non-human actor, hardware or software, that made the claim. Its details sit in a field called claim_generator_info. That field must hold a name. It may also hold a version, an icon or both (section 10.2.3.2). When a manifest is valid, its claim can be attributed to that generator (section 14.3.5).
Vendors describe this part in their own words. Adobe's overview of Firefly Content Credentials, last updated August 25, 2026, says the Content Credentials it applies automatically to assets generated with Firefly always include the issuer, the date, the app or device used, the AI tool used and the actions. Google Cloud's Content Credentials page, last updated October 30, 2026, says "Google Media Processing Services" is the app or device named for its listed models.
What do the actions say?
An actions assertion lists what was done. Under section 18.14.2, a file made from scratch, including one made by a generative model, starts with a c2pa.created action. That action carries a digitalSourceType, a term that says how the file began. A file made by opening an existing file as a parent ingredient for editing starts with c2pa.opened, and no source type is required with it.
Each action may also carry a description, a software agent and a when time. The specification calls that time a simple non-trusted time-stamp. If allActionsIncluded is true, the claim generator states that only the listed actions happened. If it is absent or false, a reader may assume others were left out (section 18.14.3).
What are ingredients?
An ingredient is an earlier or component file recorded inside the new file's record. Section 18.15.3 gives three relationships:
- parentOf: the current file is a derived file or rendition of the ingredient.
- componentOf: the current file is built from several parts, and this is one of them.
- inputTo: the ingredient was an input to a process, such as an AI/ML model, that led to the file.
The explainer describes ingredients as building a tree of provenance. It says an ingredient's own binding usually cannot be re-checked later, because its data is not usually included. Its validation is checked when it is added, and a record of that check is kept with the new record.
What does the signature tell you?
Section 14.3 describes three states. A manifest is well-formed, then valid, then trusted. Valid means it is well-formed, it is unchanged since signing, the claim signature validates inside its validity period, and the signer's credential is not rejected as revoked or as having an unknown revocation status. Trusted adds that the signing credential is trusted by the validator's trust list.
Section 15.3 says consumers should not display data from a record that is not valid. A viewer that does show it must warn about the lack of validity and warn that the data must not be attributed to the signer. The explainer adds that only assertions listed in the claim's created_assertions field are attributed to the signer, and that Content Credentials give no value judgment on whether provenance data is true. Google Cloud's page also says C2PA does not guarantee the truthfulness of the assertions.
What did we see in real ChatGPT and Adobe files?
We measured this on October 30, 2026 in Chrome. Of the 32 real files in our test set, 9 carry a record. Counts for the whole set are on our accuracy page. The first file below is a ChatGPT sample from our research set; the other two were uploaded to Wikimedia Commons by third parties and filed under "Images generated by ChatGPT", so we cannot know how they were handled before upload. They show what the checker reads in files we hold, not what a product does.
| File | Name in the certificate | Active record | Ingredient record |
|---|---|---|---|
| ChatGPT sample from our research set | OpenAI | One "opened" action, no source type | Declares trainedAlgorithmicMedia |
| Commons file filed under ChatGPT (older) | OpenAI | One "opened" action, no source type | Declares trainedAlgorithmicMedia |
| Commons file filed under ChatGPT (newer) | OpenAI OpCo, LLC | Declares trainedAlgorithmicMedia | None recorded as a source type |
In the two older files the signed declaration sits in the ingredient record, signed by the same certificate. A reader who looks only at the active record's actions sees "opened" and no source type. Our checker keeps the source types of earlier records separate from the active record's own.
The address of a source type also varies. Eight of the 32 real files declare a source type, in the active record or in an ingredient record. One of them, an Adobe Firefly file filed under "Images generated by Adobe Firefly AI", writes it as "https://cv.iptc.org/...". The other seven write "http://cv.iptc.org/...", the form written in the specification's own example in section 18.14.2. Our checker keeps the signed string as written and matches both.
What this means when you check an image
Open the checker, choose the file, and look for the headline "Content Credentials found; signer trust not established". It means a signed record is present and the checker read it, but the certificate is on neither trust list we load. The two older ChatGPT files above read this way, and their certificates have expired. The newer file, signed by "OpenAI OpCo, LLC", reads "Trusted Content Credentials declare AI use".
Under "Technical details" we show the claim generator and the actions we read, and we label the certificate's name as what the certificate says. The headline does not tell you who really signed, or whether any claim in the record is true.
Guides on this topic
- What are Content Credentials? (the main page)
- How to check Content Credentials
- C2PA signer not trusted (the headline above)
- Can Content Credentials be faked?
- IPTC Digital Source Type values explained
Frequently asked questions
- Is the claim generator the person who made the image?
- No. The specification defines it as the non-human actor, software or hardware, that made the claim.
- Why does a record show "opened" and no source type?
- The specification says a file made by opening an existing file starts with an opened action, and no source type is required with it. In our two older ChatGPT files the source type is in the ingredient record.
- Does a valid signature mean the record is true?
- No. Valid means the record is unchanged since signing. The C2PA explainer says Content Credentials give no verdict on whether the data is true.
- Does finding no record mean anything?
- It says little. The C2PA explainer says a record can be removed from a file, so finding none does not mean the image is real or human-made.