C2PA Asset Content Validation: How to Review Hard Binding Results

Define the check before opening the file

Save the exact asset and record its source, acquisition time, filename, validator and version. Preserve the complete output. This review asks whether the asset bytes match the hard binding recorded in the applicable standard manifest. It does not answer whether a caption is accurate or whether the depicted event happened.

Follow the parentOf chain

An update manifest can point to an earlier manifest through an ingredient relationship. Follow each parentOf reference until the standard manifest that carries the relevant hard binding is identified. Record every manifest identifier and the field that led to the next step. If the validator does not display a link, mark it as not shown rather than inferring a path.

The binding type and covered byte range matter. Use the algorithm and scope stated by the manifest and validator. Do not substitute a data-hash, box-hash, or BMFF-specific procedure unless that exact assertion is the one being checked.

Record the hash result as a narrow technical finding

Compute the applicable asset hash exactly as the profile specifies, then compare it with the recorded value. Keep distinct entries for binding found, algorithm applicable, hash match, mismatch, and validator error or missing detail. A mismatch means the observed bytes do not match that binding under that check. It does not identify an editor, a motive, or a date of change.

Check whether the file was re-saved or transferred before comparing results. Keep the original digest and output beside the later run. Ask for the publisher's retained copy when the difference affects a consequential claim.

Before comparing results, preserve the exact input bytes and note whether the validator read the embedded asset or a separately supplied file. Record the manifest label, the update-manifest version, each parentOf reference, the standard-manifest identifier, the binding assertion name, the hash algorithm, and the byte range. If a field is absent, write absent; do not fill it from a neighboring manifest or from a previous run.

Repeat the check on the same bytes after confirming that the file was not normalized by an editor, upload service, or archive tool. A repeated match is still a result for that byte sequence and that validator profile. If two copies differ, keep both digests, acquisition times, and complete outputs. Report which copy produced each status instead of combining them into one verdict. These records make the technical finding auditable without turning a mismatch into a claim about authorship or intent.

A review log should make the scope visible to someone who did not run the validator. State whether the asset was read from the original container, a copied member, or a detached file, and identify the profile that selected the covered bytes. Keep status labels verbatim, including unresolved or not-shown fields. Do not collapse several checks into a single pass or failure when the tool reports them separately. When a package is repaired, save the repaired file under a new digest and record the operation that produced it. The comparison can then answer which bytes were checked and which record belongs to which copy. It still cannot establish the truth of the document's claims.

Keep integrity, detection, and event verification separate

If you submit the file to the DeepFakeCheck media risk checker, store that probabilistic signal in a separate section. Automated detection can produce false positives on authentic media and false negatives on synthetic or altered media. It does not locate a standard manifest, calculate the C2PA hard binding, or issue the validator's status.

Verify the real-world claim through the original publication, the presenting account or organization, the stated date and place, and independent evidence. End with the file digest, manifest chain, binding type and scope, algorithm, exact status, unresolved fields, separate detector result, and action taken again for an auditable review record now.

Sources

• C2PA, “C2PA Technical Specification — Validate the Asset’s Content”: https://spec.c2pa.org/specifications/specifications/2.2/specs/C2PA_Specification.html#_validate_the_assets_content