A photograph arrives with Content Credentials. The viewer shows information about its origin or editing history and reports that validation succeeded. That can be useful evidence, but it does not independently establish that the pictured event happened as described. A signed record can be intact while a statement inside it is mistaken. The C2PA explainer explicitly separates provenance evidence from factual truth, and the open-source documentation makes the same distinction. [2][3]

To make that boundary concrete, we ran a small original cryptographic demonstration. We signed a record containing the deliberately false statement “2 + 2 = 5”. The signature verified successfully. Changing that statement to the true “2 + 2 = 4”, while retaining the old signature, made signature verification fail. The result is sensible: the check detects a change to signed bytes; it does not solve arithmetic on behalf of the signer. Our demonstration uses artificial text, an ordinary digital signature and a file hash. It is not a C2PA credential, certificate-chain test or photograph validation. We use it to explain why an actual Content Credentials reader must distinguish signed-record integrity, association with the asset, signer trust and the meaning of the recorded claims.

Content Credentials provide signed provenance structures, content bindings and validation information. They do not turn successful cryptographic validation into a proof that depicted content or every assertion is factual or complete [2][3]. The distinction is between validating a record and independently establishing the real-world statement that record contains. A trustworthy provenance interface should expose enough detail to preserve that boundary.

Our original demonstration signs an artificial UTF-8 JSON record containing an asset digest and the statement “2 + 2 = 5” with an ephemeral Ed25519 key. The unmodified record verifies; replacing the statement with “2 + 2 = 4” under the original signature does not. Both outcomes were computed locally and retained with the public key, signature and exact signed bytes. The private key was never exported. This is a primitive-level Ed25519/SHA-256 demonstration, not a C2PA manifest, COSE structure, X.509 chain or conformance test. We relate its separate checks to the documented C2PA architecture, using specification version 2.4 and explicitly scoped supporting documents. The example establishes signature and binding behavior while leaving credential policy, creator identity and factual interpretation as separate questions.

The asset is the photograph, video, audio or other content being described. Assertions contain structured information about it, such as recorded editing actions. A claim references assertions, and a signature protects the claim. Together, these form a manifest. A manifest store can hold multiple manifests associated with an asset, while the active manifest describes the current asset and supplies the bindings checked against it. These are distinct objects, even when a viewing tool presents them in one panel. [1][3]

That structure explains why merely finding a record is not the end of verification. The reader needs to check the signed claim, the assertions it references and its association with the asset. If a referenced assertion changes, a hash check can fail. If the asset's protected content changes, its content binding can fail. A displayed badge or a readable block of JSON does not tell you which of those checks actually happened. The SDK documentation also distinguishes JSON interfaces and reports from the signed binary representation. [3] Keep the visible summary connected to the validation result, rather than treating the ability to open a metadata panel as evidence that every part of the provenance chain has been accepted.

In the C2PA structure, assertions describe an asset, a claim references assertion data, and a claim signature signs the claim. A manifest combines those components, and a manifest store can contain multiple manifests [1]. The current asset is associated with an active manifest whose content bindings are validated against it. These relationships matter because an asset, its assertions, its claim and its signature have different validation roles.

The CAI introduction describes hash references to assertions and content bindings to protected asset data. It also distinguishes the SDK's JSON building/reporting interfaces from the binary manifest representation [3]. Parsing a report is therefore not equivalent to independently validating the signed artifact. Validation must examine the relevant structures and relationships, including assertion references and applicable asset bindings. C2PA's validation phases additionally address ingredients, time-stamps and credential revocation where relevant [1]. Our simplified demonstration collapses those structures into one ordinary signed JSON record only to isolate two cryptographic predicates. It does not reproduce the complete format or substitute for a conforming validator. Retaining the conceptual separation prevents a primitive signature result from being presented as a complete Content Credentials assessment.

Our artificial asset A contains the thirteen UTF-8 bytes represented by “demo asset A” followed by a line break. We calculate its SHA-256 digest and place that digest in a record alongside the statement “2 + 2 = 5”. We then sign the exact serialized record. Verification with the corresponding public key returns true. The asset's recalculated digest also matches the digest recorded in the signed data. Both technical checks succeed while the arithmetic statement remains false.

Next, we change only the statement to “2 + 2 = 4” and keep the original signature. Verification returns false because the signed record has changed. We also try the original record and signature with an unrelated public key; that verification fails too. These are actual outcomes of the small local demonstration, not results from an image-verification service. They show what the primitive contributes: evidence about the relationship between exact signed bytes, a signature and the relevant key. Content Credentials use signatures within a larger validation structure. [1][3] The factual meaning of a sentence still needs the kind of evidence appropriate to that sentence. Correcting its meaning and preserving its old signature are different operations.

The demonstration asset A is the thirteen-byte UTF-8 sequence for “demo asset A” plus a newline. Its SHA-256 digest is stored in a JSON record with a fixed teaching-example label and statement “2 + 2 = 5”. Node's local Ed25519 implementation signs the exact serialized bytes, producing a 64-byte signature. Verification with the retained public key succeeds, and independently hashing asset A reproduces the record's digest. The arithmetic assertion is nevertheless false.

Two controlled changes separate relevant predicates. First, replacing the statement with “2 + 2 = 4” while reusing the original signature makes verification return false. Second, verifying the unchanged record and signature with an unrelated generated public key also returns false. No image, C2PA parser or certificate authority participates in this experiment. Its purpose is an explicit counterexample to inferring semantic truth from primitive signature validity. In a real C2PA workflow, signatures are accompanied by the format, credential and binding checks described in the specification and SDK documentation [1][3]. Those additional checks establish their own defined properties; none turns the deliberately false arithmetic sentence into a true one. The experiment record preserves exact bytes and public verification material so another reviewer can reproduce these results without access to the discarded signing key.

Now keep our original record and signature unchanged, but replace asset A with asset B: “demo asset B” followed by a line break. The signature check still returns true because the signed record has not changed. However, hashing asset B gives a different digest from the digest of A recorded in that signed data. The separate asset-binding check returns false. Looking only at the signature would miss this mismatch.

Real C2PA hard bindings connect a manifest to specified protected content through cryptographic hashes. The specification permits defined byte ranges and exclusions rather than requiring one simple hash over every byte of every file format. [1] That is why a careful report should say which binding was checked and whether it succeeded. Our demonstration hashes the whole artificial asset, but it should not be used to infer the coverage rules of an actual JPEG, video or document manifest. Protected-data integrity, exact coverage and a valid relationship to the current file belong together. A signed record copied beside an unrelated photograph is not automatically that photograph's valid provenance. The reader must evaluate the association, not merely discover that some signed data exists nearby.

For the third controlled case, replace the asset bytes with the thirteen-byte sequence “demo asset B” plus newline while retaining the original claim bytes, public key and signature. Primitive signature verification remains true. Recomputing SHA-256 over B and comparing it with the signed digest of A returns false. This separates signature verification over claim bytes from a content-binding predicate involving the current asset. It is not a result saying that the combined credential is valid.

C2PA hard bindings use cryptographic hashes with format-specific coverage, including defined portions or byte ranges and exclusions [1]. Some metadata can therefore fall outside a particular hard binding. A validator must apply the actual binding rules; treating our whole-file teaching digest as a universal C2PA serialization rule would be incorrect. The validation documentation distinguishes assertion-reference mismatches from asset data-hash or other format-specific binding mismatches [4]. Those categories locate different broken relationships. Our calculated example establishes one concrete digest mismatch without claiming that hashes are mathematically unique. For a real asset, retain the binding type, covered-content context and validation result alongside the claim-signature result. Their conjunction supports a stronger conclusion than either isolated check, while still leaving the factual meaning of recorded assertions unresolved.

Our experiment creates its own key pair. Anyone who has the recorded public key can check the corresponding signature, but that fact does not identify a real photographer or establish that a recognized authority trusts the signer. Production Content Credentials use signing credentials and trust rules that our demonstration deliberately does not implement. A reader considers the signing credential, its chain and the configured trust anchors, together with relevant validity checks. [1][3]

The identity shown by a signing credential may belong to a camera, an application or an organization. It is not automatically the person who pressed the shutter, wrote a caption or appears in the picture. The CAI documentation also distinguishes additional creator-identity assertions and their verification requirements. [3] Read the label at the level it actually supports. A software vendor's accepted signing identity can help establish which tool produced a provenance record without proving who owns the depicted object. Likewise, a mathematically correct signature under an unfamiliar key does not by itself satisfy a reader's trust policy. A useful viewer keeps these questions visible instead of collapsing every successful or unsuccessful check into a general judgment about whether the scene is real.

The retained public key in our experiment supplies verification material, not a certified subject identity or an established trust anchor. In C2PA validation, credential processing and chain validation are additional operations, with trust determined relative to the validator's configured anchors and applicable rules [1]. A primitive signature-valid result must not be promoted to an unqualified C2PA-valid or trusted result. The SDK distinguishes its reported validation states and identifies signingCredential.untrusted separately from other credential failures [3][4].

Signer identity is also distinct from creator identity. The CAI introduction notes that a signing credential can identify an application, device or organization rather than a human author; CAWG identity assertions involve their own verification and issuer-trust questions [3]. These distinctions prevent several unsupported inferences. An accepted software signing chain does not establish the identity of everyone in an image, and a supplied public key does not certify its own owner's real-world credentials. Record the signer designation, credential result and trust context separately from any creator-identity information. The relevant conclusion should be tied to the actual evaluated relationship. This article makes no assessment of a particular issuer or public trust-list entry, and its ephemeral demonstration keys are not evidence of membership in a production trust ecosystem.

Suppose a file contains a location field. There are at least two different questions: was that field protected against later changes, and who is actually making a statement about the location? A hard binding that covers metadata can help detect changes to the covered bytes. It does not independently establish that the camera clock, coordinates or caption were correct when they were recorded. A wrong value can be preserved just as faithfully as a right one.

C2PA specification 2.4 makes a more specific attribution distinction. Only assertions identified as created by the signer are attributed to that signer; merely protecting existing metadata through the file's content binding does not mean the signer asserts its accuracy. [1] If an application deliberately creates an appropriate signed assertion containing that information, the attribution question changes, but independent factual verification may still be needed. When reading a location or date, look for the actual assertion and its source instead of assuming every nearby field carries the same endorsement. Our false-equation demonstration provides the smaller underlying lesson: successful protection preserves the submitted statement. It does not correct the statement or supply missing evidence about the event it describes.

Hash coverage and assertion attribution are distinct. A hard binding can cover metadata bytes, subject to the binding's documented exclusions. Coverage can provide tamper evidence for those bytes without establishing their real-world accuracy. Specification 2.4 further explains that only assertions listed in created_assertions are attributed to the signer; including existing EXIF or GPS metadata within protected asset content does not itself make that metadata a signer-created assertion [1].

Moving information into a signer-created metadata assertion changes the declared attribution, not the logical relationship between a signature and factual truth. An application can accurately preserve an inaccurate input. For an analyst, the useful record includes where the value lives, whether it is covered by an applicable binding, whether it is in a signer-created assertion and what independent evidence supports its interpretation. These are separate predicates even if a viewer presents them together. This discussion follows the pinned 2.4 specification's attribution model rather than assuming every historical manifest or SDK exposes identical terminology. The original false-equation experiment supplies a general cryptographic counterexample; the specification supplies the actual C2PA attribution rule. Neither justifies treating all signed or hash-covered metadata as a verified observation of the depicted event.

An editing application can create a new manifest for its output and refer to earlier assets as ingredients. The new record can describe actions and link to earlier provenance without rewriting the old signed claim. [1][3] That allows a reader to examine a chain of recorded transformations. It also explains why the current asset and its ingredients may have separate validation information: checking the output is not identical to checking every earlier input.

The available history may be incomplete. An image can enter a supporting application after earlier work occurred elsewhere, and the provenance visible to a viewer is limited to what was recorded, preserved and made available. The CAI documentation explicitly says that Content Credentials do not establish factual truth or completeness. [3] Absence of a recorded AI action therefore does not by itself prove that no AI tool was ever involved. Conversely, a recorded edit is not automatically evidence of deception; its meaning depends on the actual action and context. Read the named actions, ingredient relationships and validation results. Treat the record as evidence about the represented workflow, and seek additional evidence when a conclusion depends on an unrecorded part of the asset's history.

A supported editing workflow can produce a new manifest for an output asset, recording actions and referencing inputs as ingredients rather than mutating an already signed claim [1][3]. The active manifest relates to the current asset, while ingredient provenance can add earlier context. Validation results may distinguish the active manifest from ingredients [4]. This creates a structured provenance graph, not a single signature that automatically certifies every ancestor and every event.

Completeness remains a separate question. The CAI introduction explicitly limits what provenance establishes: it does not prove factual truth or that the recorded history is exhaustive [3]. Consequently, an absent AI-action assertion cannot alone establish a universal negative about all earlier processing. The valid inference is bounded by the represented claims and their evaluated relationships. Equally, the presence of an editing action does not assign a moral or factual judgment to that action. Inspect what was declared, which ingredient links are available and which validation statuses attach to them. Do not infer that an inaccessible ingredient has been independently validated from its visible name alone. Our proposed reading method preserves the difference between a supported provenance link, a declared action, a verified relationship and an unobserved portion of a workflow.

A file can arrive without discoverable Content Credentials. That observation does not prove the content is false. The file may never have carried a record, or a record or reference may have been lost along the way. The documentation describes embedded, sidecar and remotely hosted manifests, each of which changes how the provenance reaches a reader. [3] Finding no record is different from finding a particular record and detecting a broken signature or asset binding.

C2PA also defines soft bindings based on methods such as perceptual fingerprints or watermarks. These can help rediscover associated provenance when the asset has changed representation or its embedded record has been removed, provided the necessary discovery system and stored record exist. [1][3] A successful lookup is not a replacement for checking the recovered record and applicable content bindings. Nor does a remote manifest automatically survive the loss of every reference to it. Think of discovery as locating evidence and validation as evaluating that evidence. Keep those stages separate when interpreting a viewer: “no credentials found”, “a record was recovered” and “this recovered record passed the relevant checks” convey different amounts of information about the file in front of you.

Discovery and validation are different stages. The CAI documentation describes embedded manifest stores, sidecars and remote manifests; it also states that missing provenance is not proof that an asset is false [3]. A discovery failure does not supply the same evidence as an assertion hash mismatch, asset-binding mismatch or invalid signing credential. Even an embedded store can require network access for some trust or revocation operations, depending on the workflow and configuration [3].

Specification 2.4 distinguishes hard bindings from soft bindings such as fingerprints or watermarks. Soft binding can support matching across changed renditions and rediscovery of externally retained manifests, but it cannot replace a hard binding in the required validation role [1]. The CAI introduction likewise notes that remote storage alone does not recover a stripped reference; durable discovery needs an appropriate matching mechanism and lookup service [3]. Preserve whether the record was embedded or recovered, and evaluate its signature, credentials and applicable bindings after discovery. This article does not measure any watermark's survival rate or a lookup service's coverage. The relevant conclusion is architectural: locating a candidate provenance record is useful, but its availability and its successful validation are separate claims that deserve separate evidence.

A date in an image's metadata can describe when a device says the picture was captured. A trusted timestamp associated with signing serves a different purpose. The CAI documentation explains that it can establish that a signature existed while the signing certificate was valid. [3] It does not independently prove that a scene was photographed at the date written in its caption. A carefully signed old photograph can still be attached to a misleading story about a new event.

When reading a validation result, inspect the specific status and the tool's explanation. The SDK distinguishes Invalid, Valid and Trusted states, and reports categories for untrusted, invalid, revoked or expired signing credentials as well as content-related failures. [3][4] Those categories should not be silently translated into “the picture is a lie” or “the whole story is true”. The specification's full validation process considers more than a primitive signature calculation. [1] Record which reader produced the result and what trust context it used. If the question is when or where an event occurred, provenance can contribute evidence, but the event claim still needs corroboration appropriate to that question.

Distinguish an asserted capture date from a trusted timestamp used in signature validation. The CAI introduction describes trusted timestamps as evidence that a signature existed while its signing certificate was valid [3]. That is not independent verification of an asset's asserted capture time, a caption's event date or the truth of the depicted scene. C2PA's validation phases and credential processing treat timestamps within the broader validation procedure [1].

The SDK's Invalid, Valid and Trusted reporting model must be read in its documented context, alongside detailed validation statuses. The reference lists signingCredential.untrusted, invalid, revoked and expired, as well as assertion and asset-binding mismatches [4]. A primitive-valid signature under our generated key implements none of that state machine. Avoid equating the demonstration's Boolean with a complete production status or assuming that all reader versions and trust configurations produce identical decisions. Retain the reader identity, relevant settings, observed statuses and the time context of the check. This separates reproducible technical observations from a broader interpretation of an image. The specific event-date claim requires its own supporting evidence; a signature timestamp supplies a narrower property concerning the signed record and its validation context.

Start with the asset you actually received. Note whether a provenance record was found, where it came from and which reader examined it. Inspect the current manifest and its validation details, then distinguish the signed claim, the asset binding and the signing credential. Read the available actions and ingredients, and identify whether a displayed name describes the signer, a creator or another asserted identity. These steps follow the separate roles documented in the specification and open-source guides. [1][3][4]

Finally, state the real-world claim you want to assess. Is the question whether the protected file changed, which application signed a record, whether an edit was declared or whether a caption accurately describes an event? Those questions need different evidence. Our original experiment provides a compact reminder: the false statement and original asset pass both primitive checks; changing the asset breaks binding while preserving the record's signature; correcting the statement breaks the old signature. None of those results is contradictory. Each check answers its own question. Content Credentials become more useful when a reader preserves those distinctions and treats the provenance as inspectable evidence, with its scope and gaps visible, rather than asking a single badge to settle everything about an image.

An inspectable assessment identifies the exact asset, discovery path, reader, relevant validation context, active manifest and detailed results. Keep the claim-signature result, applicable content bindings, credential/trust evaluation and available ingredient results distinct. Then record the asserted actions and identities at the level supported by their actual structure and attribution. This proposed inspection record follows the separate validation relationships in the specification and CAI documentation [1][3][4].

Our retained primitive experiment has four informative cases. The original false statement with asset A has signature=true and binding=true. Asset B with unchanged signed bytes has signature=true and binding=false. Correcting the statement under the old signature gives signature=false, despite making the arithmetic sentence true. An unrelated key also rejects the original signature. These outcomes are reproducible from public material and make no claim about a production trust chain. Use the same discipline of scoped conclusions when examining real credentials: state which technical relationship was checked and which external factual proposition remains to be assessed. Provenance can support an evidence-based judgment without becoming a universal truth detector. The strongest conclusion is the one that accurately reflects the available record, the performed checks and the remaining limits of what those checks establish.