What an approval fingerprint can say about changed inputs

Compare the material, not just two hashes#

The checker derives the release, creative, destination, resource limits, schedule and recorded cost context from the campaign. It sorts object keys recursively, preserves array order and hashes compact UTF-8 JSON with SHA-256.

The approval file must contain that same material. Its calculated hash must match the file and the campaign confirmation, together with the algorithm, canonicalization description, campaign ID and fingerprint type. A correct hash of different input is still a failed comparison.

A reconstruction has a different meaning#

A fingerprint recorded before publication and one reconstructed afterwards answer different questions. The later record must say that it doesn't prove an earlier fingerprint existed and doesn't authorize another publication or creative reuse.

Event checks compare the required reconstructed sequence and selected details with the campaign. They can establish consistency within the supplied later account. They can't move the creation of that account back in time or turn it into an earlier human decision.

Matching records still need independent confirmation#

The fingerprints are local integrity values, not signatures. They don't identify an approver or prove the original decision time, and sufficient file access could change every record to match. Contiguous event numbers describe the supplied order rather than an immutable history.

Confirmation of an actual action therefore remains separate. This note is based on the schema and validator code; campaign rows, private identifiers, media and live accounts were excluded. No validator or test execution was performed.