C2PA Manifest Assertion Rules: Reviewing Standard and Update Manifests

Preserve the file and identify the manifest type

Save the exact asset before opening it in a C2PA-compatible validator. Record the source URL or local path, acquisition time, file identifier, validator name and version, manifest label, and complete output. This worksheet is an operational review method proposed here, not a reporting format required by C2PA.

Start with one narrow question: does the manifest contain the assertions required for its type and omit assertions that type does not permit? C2PA 2.2 gives different structural rules for a standard manifest and an update manifest. Copy the type reported by the validator instead of inferring it from the filename or the visible media. If the tool does not expose the type, mark it as not reported and preserve the output for another documented validator run.

Keep the structure check separate from the contents of each assertion. A structurally permitted assertion can still require its own validation. A structural failure also does not identify who created or changed the asset, why it changed, or whether the depicted event happened.

Count the assertions in a standard manifest

For a standard manifest, C2PA requires exactly one hard binding to content. The permitted choices listed in this section are c2pa.hash.data, c2pa.hash.boxes, c2pa.hash.collection.data, deprecated c2pa.hash.bmff.v2, or c2pa.hash.bmff.v3. Record the label and count before interpreting any hash result. No hard binding produces claim.hardBindings.missing; more than one produces assertion.multipleHardBindings.

Next count c2pa.ingredient assertions whose relationship is parentOf. A standard manifest may contain zero or one. More than one is rejected with manifest.multipleParents. Do not count every ingredient as a parent: copy each relationship value into its own row and count only parentOf.

The standard-manifest check also requires either a c2pa.created or c2pa.opened action in exactly one actions assertion. Record the actions assertion that contains the qualifying action. If a validator only shows an overall badge, keep that display as evidence but do not invent the missing assertion-level result.

A useful table has columns for manifest label, reported type, assertion label, relationship or action, observed count, required count, validator code, and unresolved question. Complete it from the full output rather than from a screenshot of the final badge.

Apply the separate rules for an update manifest

An update manifest must contain exactly one ingredient assertion with relationship equal to parentOf. A missing parent, multiple parents, or a different relationship causes manifest.update.wrongParents. Preserve the actual relationship and count so the record shows which condition was observed.

The update manifest must not contain c2pa.hash.data, c2pa.hash.boxes, c2pa.hash.collection.data, deprecated c2pa.hash.bmff.v2, c2pa.hash.bmff.v3, or thumbnail assertions. It must also omit c2pa.hash.multi-asset. If one of these forbidden assertions is present, the specification uses manifest.update.invalid. Record the exact offending label; the shared code alone does not show which rule failed.

If the update manifest includes one or more c2pa.actions or c2pa.actions.v2 assertions, each action value must be among the values supported by the Update Manifests section. Preserve the value shown by the validator and the returned code. Do not replace an unknown value with a familiar action or report an allow-list result the tool did not display.

These rules answer a conformance question about the relationship between a manifest type and its assertions. They do not replace signature, credential, assertion-hash, asset-binding, or ingredient validation. Keep those later results in separate rows.

Report the technical result without turning it into a truth verdict

Close the review with the exact file, manifest type, assertion inventory, counts, relationships, actions, codes, validator version, full output, and the next verification step. Another reviewer should be able to repeat the inventory without guessing which manifest or copy was examined.

If you also analyze the saved asset with DeepFakeCheck, store that probabilistic risk signal outside the C2PA conformance table. Automated detection can produce false positives on authentic media and false negatives on synthetic or altered media. DeepFakeCheck does not determine the manifest type or issue the C2PA structural codes listed above.

A conforming assertion set supports only the limited observation that the checked manifest met these type-specific structural rules in that validator run. A failure points to a specific structure that needs investigation. Verify captions, identities, dates, locations, and event claims through the original publisher and independent evidence.

Sources

• C2PA, "C2PA Technical Specification, Validate the correct assertions for the type of manifest": https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_validate_the_correct_assertions_for_the_type_of_manifest