1. A verification result needs a sentence after it
A provenance result can answer an important question without answering the question a reader thinks it answered. A tool might report success for checks on a file and its associated record. The person sharing the file might then describe a scene, a date, an accusation or a cause. Those are different claims. The gap between them is where an apparently reassuring badge can become misleading, even when the software's narrower result is correct.
The right response is not to dismiss provenance technology. It is to describe its evidence precisely enough that the reader can use it. A successful check is valuable for the thing checked. An absent record is meaningful as a limitation on the available evidence. A result that depends on a particular trust configuration should retain that configuration. None should be silently translated into a universal verdict about the world depicted by the content.
As checked on October 30, 2026, C2PA's specification landing page points to version 2.5, whose history identifies October 2026. The specification distinguishes well-formed, valid and trusted manifests; trusted implies valid, and valid implies well-formed. Asset validity is a separate determination involving the active manifest and the portions covered by content bindings. These technical distinctions do not establish the factual truth of a caption. C2PA 2.5 technical specification
That last distinction matters to the title of this article. Valid, untrusted and missing should not be read as three interchangeable labels on a single true-or-false switch. They can concern different parts of an evaluation or different reasons that evidence is unavailable. A report needs to identify the object and the check before anyone can responsibly interpret the word attached to it.
This article examines that interpretation problem through original fictional cases called Lantern Evidence. They are not reports from a deployed verifier, tests of a commercial product or claims about any real photograph. The only executed experiment is a small local comparison of original text bytes using SHA-256, described with its exact limits below. No real media was copied, uploaded or authenticated for these examples.
The aim is a better public explanation of what a result supports, what it leaves open and what additional evidence would change the conclusion. That is narrower than declaring an image genuine, but also more useful. It lets a reader distinguish a protected record from an unsupported interpretation without requiring the reader to become a cryptographic implementer or take a publisher's reassuring vocabulary on faith.
2. Separate the file, its provenance record and the claim being published
Lantern's first fictional case concerns an image described as showing an empty station platform. A reporter receives the file, a provenance report and a proposed caption saying that a transit service has permanently closed. The three items are related, but they do not contain the same assertion. A platform can be empty for many reasons. Nothing about the bare description establishes permanent closure.
Suppose the exercise stipulates that the verifier reports the supplied asset and associated record passed its applicable checks. That is a fact of the fictional report, not an actual test conducted for this article. The result may support a carefully bounded statement about that file and record. It does not supply the missing closure notice, service schedule or account of when the platform was photographed. Those missing facts belong to the proposed story.
A second caption describes the same image as showing the platform before the morning service began. A third describes a rehearsal for a film. The byte-identical file can appear beside all three captions. Which caption is justified depends on information not established merely by preserving the file. The example does not say those captions are equally plausible; it says that file integrity alone cannot select among them.
This distinction is not unique to photography. A graph can retain a verifiable production history while its accompanying article misstates the denominator. A recording can be unaltered while a quotation is placed in the wrong context. A diagram can accurately disclose that it was generated for illustration and still be presented misleadingly as a measurement. In each case, the evidence question must follow the particular factual assertion, not just the presence of a provenance record.
A useful annotation therefore names the checked object and then names the remaining claim. For Lantern, the first line could identify the supplied file by a reproducible reference and summarize the fictional tool's reported outcome. The second line would state that the proposed closure caption has not been established by that result. Combining these lines into a single word such as authentic would discard the very distinction the reader needs.
The result is not skepticism for its own sake. It creates a concrete route to a stronger conclusion. Obtain a dated closure notice, verify its relevance to the depicted station, establish the photograph's context, and the story may become supportable. If those records point elsewhere, revise the caption. Provenance evidence stays in the analysis, but it does not replace the evidence about the event.
3. Trust configuration is part of the reported result
The Content Authenticity Initiative's tool documentation describes configurable trust lists and shows a test certificate producing an untrusted-credential result when it is not on the selected lists. That is an implementation example about the verifier's configured trust context, not a general verdict that the depicted subject is false. Tool settings belong in a reproducible account of the result. CAI's C2PA Tool documentation
Lantern's second exercise gives two fictional analysts the same file and the same accompanying record. Their normalized report summaries differ in the field describing accepted signing trust. The exercise stipulates that their configurations are different. These summaries are invented explanatory records, not official C2PA JSON structures and not output produced by running the tool cited above.
Before deciding that one analyst must have found a forgery, a reviewer would ask what differed between their evaluations. Did they examine the same bytes? Did they use the same software release? Did the reports identify the same credential and trust-policy snapshot? Were external resources available to both? These questions separate a difference in evidence or configuration from an allegation that someone altered the subject of the image.
The useful reconciliation is explicit. Report A can be described as accepting the credential under its stated policy; report B can be described as not establishing that acceptance under its different policy. Neither fictional report becomes a statement that the scene occurred as captioned. Nor should the article collapse their differences into whichever result sounds more favorable to the story it wants to tell.
A comparison can remain unresolved. If report B omits its configuration identifier, the reviewer may be unable to establish why the outcomes differ. That omission is a reproducibility limitation. It is not proof that the software is defective, that the signer is dishonest or that the image is synthetic. A responsible account identifies the missing field and stops short of selecting an explanation without evidence.
The same discipline applies over time. A result saved last month describes an evaluation under the information and configuration then used. A later result should not silently replace that historical record or be represented as though it had always been available. Preserving both reports can show what changed, while a versioned explanation prevents a change in policy from masquerading as a change in the underlying media.
4. Missing evidence is not a positive finding of fabrication
CAI's introductory guidance explicitly distinguishes missing from invalid Content Credentials and cautions that absence alone does not show that content is false. That is a narrower conclusion than saying all missing records have an innocent explanation. It means the absence does not, by itself, choose between the possible histories of a file. CAI's Content Credentials introduction
Lantern receives three fictional files with no usable provenance information in the supplied packet. In the first case, the creator never supplied such a record. In the second, the packet contains only a derivative copy. In the third, a referenced resource is unavailable to the analyst. These are stipulated scenarios, not claims that a particular verifier must issue the same code for all three. Their common feature is that the analyst lacks the relevant evidence at the time of review.
The public description should preserve the distinction between not found, not retrieved and not evaluated. A search may locate nothing. A retrieval may fail after a reference is found. A tool may not support the relevant format. Each limitation affects what the analyst can conclude, but none supplies an observation of the scene's factual truth. A report that translates every one of these outcomes into fake would invent information that the analysis did not produce.
A numerical example shows how missingness can distort a summary. Imagine a fictional review receiving 100 files. Its chosen tool can process 60 of them; 20 of those 60 yield the relevant provenance record and 40 do not. Forty additional files remain outside the tool's supported evaluation in this exercise. The proportion yielding records is 20 percent of all received files, but about 33.33 percent of the processed subset. Neither percentage establishes how common credentials are across the internet.
Calling the remaining 80 files invalid would be wrong under the example's facts. Forty were processed without the record being found, and 40 were not evaluated by that tool. Even the 20 with records have not been described here as passing every check. Presence, processability and evaluation outcome are separate measurements. A useful public chart would keep those groups separate instead of squeezing them into a green-or-red total.
This matters because a missing record can become a rhetorical shortcut in either direction. One person may call the content fabricated; another may insist the absence proves that the system is useless. The limited result supports neither claim by itself. It tells the reader what evidence was unavailable and helps identify an appropriate next question, such as whether an original file or a missing resource can be obtained through an authorized, ordinary channel.
5. Product conformance and an individual story are different objects
C2PA's conformance landing page says the program opened in June 2025 and has been upgraded to version 0.2. It describes evaluation of products against specification and security requirements and links public product and trust lists. That describes a program for implementations; it is not a publication declaring that every factual assertion accompanying every output is true. C2PA Conformance Program
Lantern's fictional product record names a generator, its version and the scope of an evaluation. A reporter then receives a file and a claim that the generator created it. Before using the product record as evidence about this file, the reporter needs the connection between the two. A product's presence in a list does not by itself identify the origin of an arbitrary file carrying a familiar logo.
Even after that connection is established in the exercise, the scope remains important. An assessment of a generator is not automatically an assessment of every viewer that later interprets its output. A record referring to one version should not silently become evidence about another. A statement covering a particular implementation should not be expanded into a guarantee about unrelated components in a distribution chain. These are ordinary boundaries of an evaluation, not objections to having evaluations.
Consider two invented product records that share a vendor name but identify different releases. One applies to release Cedar 4; the other to release Cedar 5. The supplied report identifies Cedar 4. A search result showing Cedar 5's more recent evaluation is not enough to describe the supplied report's implementation as having that newer evaluation. The evidence requires an explicit relationship, not a convenient match on the vendor name.
The same mistake appears when a product list is treated as a general reputation score. A reviewer might decide that a recognizable vendor makes every accompanying caption credible or that an unfamiliar entry makes a scene suspicious. Neither inference follows from the narrow product-record facts. Context about an event still needs to be established through relevant evidence, and a product's listed status should be described in the terms the record actually uses.
A careful published explanation can therefore separate three lines: the implementation record found, the evidence connecting the supplied file to that implementation, and the checks reported for the supplied file. If one line is missing, leave it missing. Combining them prematurely makes the result harder to audit and can wrongly imply that an organization vouched for a particular image or story when it evaluated something much narrower.
6. A referenced ingredient is not automatically a fully inspected history
C2PA's FAQ explains that an ingredient can refer to another asset and that checking its full provenance requires access to the relevant data. Without that access, a recorded prior validation is not the same thing as independently examining the complete ingredient chain. That distinction prevents a history display from being mistaken for unlimited access to every source behind it. C2PA FAQ on ingredients and provenance
Lantern's fictional composite image G uses inputs A and B. The supplied packet includes G, the record associated with it, a copy of A and a reference to B. The analyst can inspect A's supplied bytes. B is not available in the packet. The evidence sheet should record those facts separately instead of marking both inputs reviewed simply because both appear in the history display.
Suppose the packet also contains a statement that B was checked during an earlier production step. That statement is evidence of a recorded earlier result, subject to the checks and context applicable to the record containing it. It does not recreate B's missing bytes for the present analyst. Describing the earlier statement and independently repeating the earlier examination are different activities. The article should say which occurred.
The difference becomes concrete when the story turns on B. Imagine that G is an illustration containing a background from A and a small sign from B, and the proposed news caption relies on the words on the sign. A strong result about A does not answer the question about B. The missing material is not automatically unimportant because it occupies fewer pixels or appears deeper in the displayed history.
Nor can provenance completeness be inferred from a long list. An extensive record might document many intermediate steps while omitting the particular context needed for a claim. A short record might support a narrow, clearly stated purpose. Counting entries is not a substitute for asking which assertion each entry can help establish. More history can be useful without turning quantity into proof of the disputed fact.
For this fictional case, the defensible account identifies G and A as supplied, B as referenced but unavailable, and the sign's interpretation as unresolved. It can explain what would be needed to strengthen the conclusion: authorized access to B or independent evidence about the sign and its context. It should not fill the gap by assuming that a prior successful result meant the same thing the current story needs to prove.
7. A documented creative process can still produce fiction
Adobe's Content Credentials overview, updated August 25, 2026, describes automatically applying credentials to content made with Firefly and its APIs. That is a useful concrete reminder that a provenance record can accompany deliberately generated content. Presence of credentials is therefore not equivalent to a declaration that a camera recorded a real-world event. Adobe's Content Credentials overview
Lantern's next fictional artifact is an illustration of a proposed pedestrian bridge. The accompanying description clearly identifies it as an artist's concept. The illustration can serve an honest purpose: showing a design idea that has not been built. Its usefulness does not depend on pretending it is a photograph, and a transparent creation history can help communicate its actual status.
Now reuse the same illustration beneath a caption saying the bridge opened yesterday. The problem lies in that factual claim. A well-documented creative process does not make the opening occur. Conversely, the fact that the illustration is synthetic does not make the original artist's-concept caption dishonest. The relevant distinction is between how the artifact was made and how it is being represented in the particular publication.
An ordinary staged photograph raises a similar issue without any generative tool. In a fictional safety training session, actors demonstrate an evacuation. A photograph accurately records that demonstration. If another publication describes it as an actual emergency, the image's origin and the publication's claim no longer match. Detecting digital alteration would not necessarily reveal the mistake because the misleading assertion concerns the setting and purpose of the scene.
AP's August 15, 2023 published guidance treats generative output as unvetted source material and retains editorial sourcing judgment. That is an example of an organization's stated editorial policy, not a technical C2PA rule or a claim that this article's cases underwent AP review. AP's generative-AI standards
For the Lantern examples, the productive questions are specific. Was this presented as a concept or an observation? What event, place and date does the caption assert? Which evidence supports those assertions independently of the artifact's production record? Those questions allow provenance to contribute useful information without forcing it into a role it cannot perform alone. They also avoid treating every creative edit as deception, a mistake that would obscure rather than clarify the public record.
8. What the local byte experiment actually demonstrates
For this article, a small reproducible exercise was executed locally using Python 3.12.14. It created an original text file, an exact copy and an edited version. The first file contains two lines stating that the exercise is synthetic and describing a blue square. It does not contain a photograph, an actual drawn square, a C2PA manifest or a digital signature. The experiment concerns those text bytes alone.
Python's hashlib documentation provides a SHA-256 interface accepting bytes and returning a digest. That is the function used here. No C2PA software was invoked, no signing credential was generated and no trust list was consulted. The operation should not be described as content-credential verification merely because a cryptographic hash appears in its output. Python's hashlib documentation
The original and its copy each contained 58 bytes. Both produced the SHA-256 digest beginning 99ba03b7f4a2. Replacing the word blue with green created a 59-byte file whose digest began 3fdc78a650b4. The complete input files, script, runtime and full digests were retained in the exercise packet. These are observed results of this local comparison, not hypothetical verifier outcomes.
The first conclusion is precise: the two copied byte strings matched in the exercise, while the deliberately edited fixture produced a different digest. It would be inappropriate to generalize from this tiny exercise to a benchmark of all possible edits, a proof about every collision possibility, or a test of a media-binding implementation. It is an elementary demonstration with a defined input and a defined computation.
The second conclusion concerns an external caption. A separate file attached the invented descriptions Fictional Tuesday exercise and Fictional Wednesday exercise to the same original text file. Those captions were intentionally outside the bytes passed to the hash function. Changing which caption an observer reads does not change the computation on that unchanged input. The unchanged digest therefore cannot establish which external description is factually justified.
This is not a recipe for C2PA binding. Actual asset formats and their applicable checks must be understood through the relevant specification and implementation; the article does not reproduce those algorithms. The simple exercise instead makes an evidence boundary visible: a computation over one object does not automatically evaluate every statement someone later places beside it.
Even this small result depends on preserving the actual input. Copying the text through an editor that changes line endings or adds a final character can produce a different byte sequence. A reader reproducing the exercise needs the retained files or an exact definition of their bytes, not only a screenshot of the words. That observation supports careful artifact identification; it does not establish whether the sentence describing the square refers to anything that exists in the world.
A fourth retained fixture tested that last boundary directly. It kept the original wording but replaced the two line-feed characters with carriage-return-and-line-feed pairs. The file grew from 58 to 60 bytes and produced a digest beginning 9531fa2fd24d. Its words still described the same synthetic exercise and blue square. The observed difference was a formatting-related byte change, not a new claim about a different square. This comparison demonstrates why a changed digest needs an explanation of the changed object rather than an automatic allegation of deceptive editing.
The two deliberate changes thus answered different questions. Replacing blue with green changed a word in the description; changing line endings preserved the words while changing their byte representation. Both produced different digests in the executed exercise. The digest comparison alone did not classify either change's meaning. That classification came from inspecting the known inputs and the controlled transformations. Again, none of these operations reproduces a C2PA asset-format binding rule.
9. Read the scope of a report before promoting a successful subcheck
A technical report often contains several observations. The mistake is to find one favorable line and treat it as a summary of everything the report could have checked. Lantern's fictional report contains a successful signature-related subcheck, an unresolved asset association and an unavailable source reference. Those are invented explanatory fields, not a claim that an actual C2PA report uses this exact schema or necessarily combines these states in that form.
A headline saying the entire artifact was verified would omit two important limitations. It would also upgrade a successful component result into a completed evaluation. The correct account describes the positive finding alongside the unfinished parts. A partial result can be useful without being complete; its value does not depend on hiding the remaining work.
The current specification's separate manifest and asset concepts are a reason not to equate a successful signature subcheck with complete asset validation. C2PA 2.5 validation model
In Lantern's exercise, a reviewer initially writes that the signature-related result supports the supplied record's reported check, while the association with the submitted artifact remains unresolved. Later, additional evidence resolves the association. That changes the report's scope, but it still does not establish the proposed caption's independent claims about an event. The record can become technically more complete while a journalistic question remains open.
An attached report is also an artifact that needs identification. A screenshot might show the result for a different file with a similar name. A copied text summary might omit warnings. A report generated before a later edit might no longer describe the file being circulated. These are possible evidence problems in the fictional workflow, not claims that a named verifier produces unreliable output. The remedy is to connect the retained report to its stated input and evaluation context.
For example, Lantern's packet has two files both displayed as platform.jpg in separate folders. One is the originally supplied asset; the other is an exported derivative. A report naming only platform.jpg cannot distinguish them for a later reviewer. Adding a stable artifact reference and preserving the report alongside the relevant file makes the claim more reproducible. It does not make the image's caption true, but it prevents a different ambiguity from undermining the technical evidence.
This is where precise language earns its space. Say which reported check succeeded, which input it concerns and which limitations remain. Avoid using passed as a floating adjective with no subject. A reader should be able to tell whether the article is discussing a signature, a manifest, an asset, a product evaluation or a factual claim about the depicted world.
10. Report counts should not become truth percentages
Lantern's next example is a fictional editorial review of 120 submitted items. Forty have a retained technical report and the input artifact identified; 30 have a report but its connection to the submitted artifact remains unresolved; 25 have no report in the packet; and 25 were excluded from this particular review because the required material was not supplied. These mutually exclusive groups total 120. They describe evidence availability, not the truth of 120 stories.
If a summary calls the first 40 verified content, the label is already too vague. The group only establishes that a report and its identified input were retained. We have not specified the reports' outcomes or independently assessed the captions. Forty divided by 120 is one third, but that fraction is not an estimate of how much of the submitted content is true.
Changing the denominator changes the statistic again. If the reviewer excludes the final 25 incomplete submissions, the 40 identified report-and-input pairs become about 42.11 percent of the remaining 95. Both calculations are arithmetically correct for their definitions. Neither supports a claim that the tool's factual accuracy is 33.33 or 42.11 percent. No truth-labelled test set or relevant accuracy evaluation was supplied in this exercise.
A second classification can be maintained separately. Suppose independent reporting establishes the factual context for 18 of the 120 captions and leaves the rest unresolved. That is another evidence dimension. Without a cross-tabulation, the reader cannot know how those 18 overlap with the 40 retained report-and-input pairs. Adding 18 and 40 would risk counting the same items twice, and treating one group as a subset of the other would invent a relationship not provided by the data.
To make the overlap explicit, stipulate that 12 items are in both groups. Then six have independently established caption context but are outside the 40 identified report pairs, and 28 have identified report pairs without established caption context. The union contains 46, not 58. The numbers help demonstrate that technical evidence and contextual reporting can contribute different information rather than forming a single ladder on which every item occupies the same rung.
The full fictional cross-tabulation has four groups: 12 with both kinds of evidence, 28 with identified report pairs only, six with established caption context only, and 74 with neither established in this review. Those four groups total 120. The final 74 are not thereby proven false; the exercise has only specified that these two kinds of evidence were not established for them. Keeping the empty-evidence category distinct from a factual finding is essential to interpreting the table.
This matters for public dashboards. A statistic should retain its unit, its denominator and its test definition. Counting files, reports, claims, captions and product records as though they were one population produces impressive totals with unclear meaning. A smaller, well-defined count is more informative than a sweeping authenticity score whose components answer different questions.
11. A label should preserve the uncertainty rather than decorate over it
NIST's final November 2024 report on synthetic-content transparency distinguishes machine-readable provenance information from the labels shown to people. Its discussion emphasizes context and the unresolved challenges of designing effective disclosures. That is a reason to evaluate what a label communicates, not to assume that displaying a technical result automatically gives the audience the right understanding. NIST AI 100-4, labels and user perception
Consider a fictional interface presenting a large green check beside the word verified. The underlying report actually concerns a particular provenance evaluation, while the adjacent headline alleges that a local event happened yesterday. A reader might reasonably interpret the check as endorsement of the headline. The interface has allowed the meaning of the result to expand beyond its documented object, even if the underlying report has not changed.
A more informative alternative would name the object and preserve a separate line for the story's unresolved context. That does not require displaying pages of certificate detail to every reader. It requires refusing to compress materially different claims into one ambiguous word. The detailed report can remain available for people who need it, while the summary states the scope in ordinary language.
The same principle applies to unfavorable results. A red indicator saying fake may be unjustified when the actual limitation is that a resource could not be retrieved. An indicator saying unknown may be too vague if the report contains a specific, material failure. The label should communicate the observed result rather than force every case into the publisher's preferred emotional tone. The fictional examples do not establish that a particular real interface has these problems.
Accessibility matters to the reasoning as well as to presentation. If the distinction appears only as red versus green, a reader using a text representation may lose it. If a qualification exists only in a hover panel, someone reading a screenshot may never encounter it. These are original communication-design observations, not claims of a tested accessibility audit. They show why the wording and placement of the scope statement deserve attention alongside the icon.
A useful evaluation would ask readers what they think the label establishes and compare their answers with the intended claim. That would be a human-understanding test, different from a cryptographic test and different again from an assessment of factual reporting. No such user study was conducted here. The article proposes the distinction so that an eventual study would measure the right outcome rather than assuming a successful computation guarantees a successful explanation.
12. Make the next verification question specific
The strongest conclusion from a provenance review is often a more exact question. Lantern's station image needs evidence about its time and context. Its composite image needs access to a particular source. Its conflicting reports need configuration identifiers. Its edited fixture needs the exact bytes if someone wants to reproduce the local comparison. Each question follows a different gap in the evidence. None is answered by adding another generic badge.
An original report card for the station case could therefore have three separate findings. The supplied artifact and associated technical report are identified. The evaluation context is documented to the extent the packet permits. The assertion that the station permanently closed is not established by those materials. This is not a weaker version of saying true or false. It is a more faithful description of what the review actually did.
If a dated, relevant closure record later arrives, add it as new evidence about the caption. If an original file later resolves an artifact mismatch, update that separate finding. A correction should state which part of the analysis changed and why. That prevents the useful discovery of one missing fact from being portrayed as vindication of every earlier assumption, or as proof that every previous record was worthless.
The method also leaves room for an honest stopping point. A publisher may lack access to a source asset, a needed report or an independent witness. It can say so without declaring the entire story fabricated or pretending the investigation is complete. The unfilled field is a description of the evidence available to that publisher, not a universal claim about what can ever be known.
There is a practical advantage to preserving this structure. A later reader can reproduce the bounded technical check, inspect the relevant source, or challenge the link between evidence and caption without disputing an undefined concept of authenticity. The discussion becomes about identifiable objects, reported operations and particular factual assertions. Disagreement can then produce a better record instead of an argument over the emotional meaning of a green check.
C2PA evidence is most useful when it remains evidence: a contribution to understanding a file's provenance and the reported checks, interpreted with its scope and limitations intact. It should not be stretched into a truth engine, and it should not be discarded because it is not one. Valid, untrusted and missing become informative only when the reader is told what each finding concerns—and what still has to be established about the story being told.