C2PA Compressed Manifests: How to Review Decompression Failures

Preserve the exact file and define the review question

Save the media file you actually received before opening it in a validator. Record the source page, download time, filename, size, and a file hash if your workflow already produces one. If a platform offers an original and several converted copies, label each copy and identify the one used for the review. This evidence log is an operational method proposed here, not a record format required by C2PA.

Write the review question beside the file record. You may need to determine whether the file contains a compressed C2PA Manifest, whether the validator could open that container, or whether a claim about the depicted event is accurate. Those questions use different evidence. Keeping them separate prevents a container error from becoming a verdict about the media.

Use a C2PA-compatible validator and note its name and version. Preserve the complete output rather than a badge or shortened message. A screenshot can support the record, but copied status text and the saved file make another review easier to repeat.

Identify the compressed wrapper before interpreting it

C2PA 2.2 says that a Standard Manifest or an Update Manifest may be compressed in its entirety with Brotli. For either manifest type, the wrapper TYPE is c2cm. Its label is identical to the label of the compressed manifest superbox, and the brob content box contains the compressed bytes of the entire manifest superbox.

Record only the fields the validator exposes. A compact table can include the inspected file, wrapper TYPE, label, reported content box, manifest type if displayed, and the exact status message. If a field is absent from the output, mark it as not displayed. Do not reconstruct it from the filename, file extension, or a different copy.

The specification also says that wherever a Standard or Update Manifest is referenced, a compressed Standard or Update Manifest is valid. Compression therefore describes how the manifest is carried. It does not remove the need to inspect the manifest that the container holds.

When comparing two copies, validate them separately first. One copy may retain the compressed container while another may expose different C2PA data or no data visible to the tool. Record the observed difference without assigning a cause that the files and validator output do not establish.

Keep a decompression failure narrow

If the validator cannot open the compressed container, copy the complete error, the stage named by the tool, and any displayed wrapper fields. Repeat the check on the same saved file with the same documented tool before changing the file. If you later use another compatible validator, keep both outputs and versions instead of replacing the first result.

Describe the finding as “this validator did not decompress this container for this file.” The error does not reveal, on its own, whether the manifest inside would pass its later checks. It also does not establish who created or changed the file, why decompression failed, or whether the event shown in the media occurred.

Do not repair the evidence copy. Conversion, metadata rewriting, or re-export may create a different file and a different review target. Work on a duplicate if troubleshooting is necessary, give that duplicate a new identifier, and preserve the original error with the original file.

A failed attempt is still useful when the record is precise. The file identifier, tool version, exact message, and observed fields let another reviewer distinguish a repeatable container problem from a one-off local failure. Explanations about the cause require evidence beyond the error string.

Review the contained manifest as a separate stage

When the tool does open the wrapper, continue with the Standard or Update Manifest that it presents. Keep the wrapper result and the manifest results in separate sections. Record the manifest type and every validation result exactly as displayed, including unresolved or failed checks.

A successful decompression means the tool reached the contained bytes. It does not make every assertion accurate, establish that the signing party is trusted, or confirm a caption about a real event. Each later result keeps its own scope. If the validator does not show a later result, leave it unresolved.

The same rule applies to a failed later check. Name that check and preserve its message. Do not roll several technical stages into “C2PA valid” or “C2PA invalid,” because those labels hide which observation another reviewer can reproduce.

Keep detection and event verification independent

A saved image, video, audio file, or text can be submitted to DeepFakeCheck for a probabilistic risk signal. Use a C2PA-compatible validator for decompression and wrapper checks. Store the DeepFakeCheck output outside the C2PA container record and link it to the exact copy analyzed.

Automated analysis can produce false positives that flag authentic material and false negatives that miss synthetic or altered material. A high-risk result supports further investigation. A low-risk result does not authenticate the file and should not replace wrapper or manifest checks.

Check the real-world claim with the original publication, the account or organization presenting the media, the stated date and place, and independent evidence about the event. Finish the record with the inspected file, validator and version, wrapper fields, decompression output, contained-manifest results if available, detector output if used, external-source findings, and the decision taken.

Sources

• C2PA, “C2PA Technical Specification — Compressed Manifests”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_compressed_manifests