The Provenance Came Off Inside My Own Pipeline
One generated image, two derivative operations, and the embedded provenance that did not survive them.
I generated an image with an embedded provenance manifest, made two routine derivatives from it, and both came out with the manifest gone. That made the exported file the place I needed to check.
What I observed
On September 14, 2026 I audited the image sources in my workspace. One native generated image carried an embedded C2PA manifest. From it I produced two derivatives of the kind I make without thinking: a plain re-save, and a resize to fit a layout. Neither derivative carried the manifest.
| Asset in the tested workflow | Embedded provenance manifest |
|---|---|
| Native generated output | Present |
| Plain re-save | Absent |
| Resized copy | Absent |
The source record lists thirty provenance entries in the native file and none in either derivative. The table reports only whether an embedded manifest was found. The entry count does not represent thirty independently validated credentials, and I ran no cryptographic trust validation. What I have is a mismatch between the point where provenance was created and the point where the file left the pipeline.
What a missing manifest does and does not mean
Content credentials record tamper-evident, signed assertions about how an asset was created and edited. The C2PA 2.2 Explainer describes the scope of that record. That is a record of process. It does not establish that a scene is real or that any claim made in the image is true.
Absence means less than people assume. A file with no manifest is not thereby human-made, and a stripped manifest is not evidence of bad intent or falsity. In my tested workflow, an ordinary derivative step did not carry the record forward.
The C2PA FAQ notes that manifests can become separated from their media, and that soft bindings such as watermarks or fingerprints can help rediscover the associated credentials. That is a capability the ecosystem supports. It is not a guarantee that my particular stripped file could be reunited with its record.
What I changed
Keep the native output as the asset of record. A copy saved for inspection is a copy. It should not quietly become the thing you publish.
Ask for the aspect ratio when exact pixels are not the requirement. When the destination accepts the native dimensions, asking for its intended shape lets me use the render as delivered.
Check the derivative you are shipping, not the one upstream of it. Inspect the exported file with whatever your own tools provide for reading embedded credentials. This is a local check on your own copy; nothing needs to be uploaded anywhere.
When exact dimensions are the requirement, meet them with a tool or workflow that preserves or re-signs appropriate provenance, then verify the output. The exported file still needs its own check.
Method and limits
One audit, one file, one day, one workflow, two derivative operations. The scratch specimens and the tool invocation details were not preserved in the versioned public record, so this is not reproducible from anything I have published. It is a bounded workflow observation that prompted a habit change, with no comparison of editing tools.
I tested no other editors, resizers, platforms or upload paths, and this result says nothing about how any of them behave. Nothing here is a claim about detecting AI-generated images, about legal compliance, or about how C2PA is implemented internally.
Practice notes from my own workflow. Claude helped draft this article; Codex checked the source record and prepared the page. The method and limits above travel with the findings.