C2PA Ingredient Manifests: Reviewing Explicit and Recursive Validation

Preserve the file and define the review question

Save the exact asset before opening it in a C2PA-compatible validator. Record the file name or source URL, retrieval time, validator name and version, active-manifest label, and complete validation output. Keep these records with the file. This record sheet is an operational method proposed here, not a format required by C2PA.

Limit the question before reading the result: did the validator process every relevant ingredient assertion, follow the referenced ingredient manifests, and return the recorded validation results? An ingredient manifest describes provenance relationships inside a C2PA lineage. Its validation does not establish that a caption, speaker, place, capture time, or depicted event is true.

Check explicit validation before following the lineage

C2PA 2.2 requires a relationship field in an ingredient assertion. Record the value exactly. The allowed values are parentOf, inputTo, and componentOf; a missing or different value produces assertion.ingredient.malformed. Do not repair the field in a review copy or infer a relationship from the file name.

For a standard manifest, the validator validates each ingredient regardless of its relationship value. For an update manifest, it validates the update manifest's parentOf ingredient. Time-stamp manifests found in an ingredient are ignored because that feature is deprecated in favor of the time-stamp assertion. Keep those cases in separate rows so a standard-manifest review is not confused with an update chain or the deprecated manifest type.

Use one row per ingredient assertion. Capture its manifest label, assertion URI, relationship, activeManifest reference, claimSignature reference, validationResults presence, and the exact success, informational, or failure codes returned. A color badge or one overall pass/fail hides which field or lineage step produced the result.

Follow every referenced ingredient manifest recursively

The specification requires recursive validation of all ingredient manifests in the asset. It gives depth-first search as an example; another implementation is allowed only when it produces equivalent results. The validator builds a list of ingredient-manifest hashed_uri values across the lineage and a second list of redacted-assertion JUMBF URIs.

At each manifest, the validator locates the claim. It then inspects redacted assertions and resolves each ingredient assertion's hashed URI. If that URI cannot be resolved, its hash does not match, or its JUMBF Content boxes contain only zeros, the algorithm moves to the next ingredient assertion. Preserve the complete output at that step instead of inventing a missing status that the tool did not show.

When an ingredient assertion has activeManifest—or c2pa_manifest in a version 1 or 2 assertion—the validator records the active-manifest and claim-signature references and continues into that manifest. If no such field is present, it returns ingredient.unknownProvenance unless the relationship is inputTo, then continues with the remaining assertions. A blank branch therefore needs its relationship and field presence beside it; “no provenance” alone is too broad.

Reconcile fresh results with the recorded results

After collecting the lineage, the validator chooses an ingredient-validation method. When matching redacted assertions exist, it uses the claim-signature hash validation method. Without a matching redaction, it may use either the manifest hash method or the claim-signature hash method. Record which method the validator reports; do not treat the two methods as interchangeable evidence in the worksheet.

The claim-signature method checks the referenced claim-signature box and its hash, then validates the claim signature, time-stamp, credential-revocation information, and non-redacted assertions. It does not evaluate ingredient hard bindings. The manifest-hash method resolves and hashes the referenced ingredient manifest and can issue ingredient.manifest.validated when the hashes match. The specification describes that route as faster when the validator trusts the previous claim generator's validation results.

If validationResults is present, the validator returns recorded entries that were absent from the fresh run and fresh entries absent from the recorded field. A version 3 ingredient assertion with activeManifest but no validationResults returns assertion.ingredient.malformed. Keep recorded and newly returned entries in separate columns before reconciling them. Also ignore extra C2PA manifests in the Manifest Store when they are not in the compiled ingredient-manifest list; the specification preserves this behavior for compatibility with constructs the validator may not recognize.

Keep provenance results separate from media detection

The useful final record contains the exact asset, validator and version, each ingredient relationship, the recursion path, validation method, recorded results, newly returned results, redactions, unresolved references, and the action taken. Another reviewer should be able to repeat the path without guessing which branch or file was examined.

If you also analyze the saved asset with DeepFakeCheck, store its probabilistic risk signal separately. Automated detection can produce false positives on authentic media and false negatives on synthetic or altered media. DeepFakeCheck does not replace a C2PA validator or issue the ingredient-validation codes described above.

A successful ingredient result supports a limited statement about the provenance records and references checked in that run. A failure identifies a technical problem to investigate. Neither result proves that the depicted event is real or false. Verify event claims against the original publication and independent evidence.

Sources

• C2PA, “C2PA Technical Specification, Validate the Ingredients”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_validate_the_ingredients