Decentralised News · Editorial by Heath Muchena · Evidence reviewed 11 November 2026. Original DN analysis and local instrument; field testing is claimed only where expressly reported.
What Matters
Content Credentials can help establish an asset’s provenance and detect changes within their stated scope. They do not make a financial report accurate, identify every human contributor or prove that an unsigned copy is fake. DN’s review record separates the validator’s result, the signer’s assertions and independent fact-checking, so an agent cannot mistake a provenance badge for permission to act.
Decentralised News · Information Integrity Research · Edition 1.0 · Reviewed 11 November 2026
DN Evidence Block
Established by documentation: C2PA content-binding, trust and assertion concepts; official implementation guidance and SDK validation states. Original DN work: a financial-report review workflow and local evidence record. Not measured: crypto-media adoption, validator accuracy, credential survival or any publication’s trustworthiness. DN has not cryptographically validated a report for this article.
The report is signed. The revenue number still needs checking.
An agent receives a financial report announcing a protocol’s latest quarterly revenue. A Content Credentials viewer displays a trusted result. The document could nevertheless contain a calculation mistake, an ambiguous revenue definition, an outdated reporting period or a forecast presented too confidently. Provenance helps investigate who asserted what about the asset; the financial claim requires its own evidence.
This is the key publishing decision. Treat provenance as one layer of review with a defined output. Do not let a successful cryptographic check silently replace checking the source accounts, methodology, denominator and date. A signed document is useful precisely because its origin and version can be examined, including when someone later discovers an error.
DN’s existing content-platform comparison addresses production workflows. This article concerns a different decision: how an editor or consuming agent should interpret provenance evidence attached to a particular asset. It does not rank creative tools or assign a trust score to media outlets.
What the current specification establishes
C2PA’s technical specification describes manifests containing signed claims and assertions, with content bindings connecting the record to an asset. Its version 2.5 also distinguishes assertions made by the signer from assertions gathered from other workflow components. That distinction matters when deciding who is actually asserting a location, identity or process claim. [1]
The official explainer states the essential limit: provenance alone cannot determine whether the depicted or written content is factually true. It also rejects a blanket inference that media without credentials is untrustworthy. Content Credentials use established cryptographic techniques and do not require a blockchain, although implementations may use distributed-ledger infrastructure alongside them. [2]
DN inference: anchoring a report’s hash on a chain can add a publication reference, but it does not strengthen an unsupported revenue figure into an audited fact. First define the claim the anchor is intended to support. Then examine whether the asset, signing process and financial evidence support that claim.
Version discipline is part of the review. The current C2PA index presents technical specification 2.5 while linking some guidance at earlier versions. This article records those versions separately. A software product’s supported version, a guidance document’s version and the date a trust list was obtained should not be collapsed into a single “latest C2PA” label.
Five results that should not share one green badge
| Recorded result | Reasonable interpretation | Unsupported leap |
|---|---|---|
| Trusted under a specified validator configuration | The validator reports the relevant validity and trust requirements satisfied. | The report is true or every named contributor authorized it. |
| Valid, trust not established | The reported structural or cryptographic checks do not establish the required signer trust. | The author is necessarily malicious. |
| Invalid | The recorded failure codes need investigation. | Deliberate deception has been proved. |
| No credential found | This examination did not locate one in the asset or supported discovery path. | The asset is fake or was made by AI. |
| Not checked | No validator result is established. | An icon or screenshot substitutes for validation. |
The current CAI SDK documentation distinguishes Invalid, Valid and Trusted validation states and provides detailed results for the active manifest and ingredients. It also notes that older validation_status reporting has been superseded by newer result structures. Keep the actual tool version and result codes instead of assuming screenshots from different validators are equivalent. [7]
The table is DN’s review vocabulary, not an assertion that every application displays these exact labels. When a product uses different language, preserve its raw result and document the mapping. An editor should be able to reconstruct why the review reached its conclusion.
The signer may be an application, not the analyst
C2PA’s identity recommendation distinguishes a claim-generating product’s identity from human and organizational identity. It recommends CAWG specifications for expressing the latter. A signing credential associated with an editing application should therefore not automatically be described as a verified identity for the person named on the report’s cover. [5]
For financial media, ask three separate questions. Which implementation signed the asset? What organization takes responsibility for publishing the report? Which person or process stands behind the financial analysis? Sometimes the credential carries useful evidence for more than one question. Sometimes another channel must establish the relationship.
Preserve that distinction when an agent summarizes the report. “A credential identifies the signing application” is a different statement from “the issuer verified this analyst.” If organizational identity is crucial, retain the relevant identity assertion, its validation result and its scope rather than relying on a display name alone.
The C2PA Conformance Program evaluates product implementation and security requirements and maintains public product and trust lists. Conformance is relevant to how credentials are created and validated. It should not be marketed as an endorsement of every article, forecast or business claim signed by a conforming product. [6]
AI disclosure is another assertion with a scope
C2PA’s AI/ML guidance describes provenance for models, datasets and outputs, including identification of AI-generated output and optional links to related inputs and model information. The amount of information available depends on what the workflow records. A useful credential can reveal a process without supplying a complete history of every contribution. [3]
A financial report may contain a human-written conclusion, a model-generated chart, a licensed photograph and data imported from several sources. Review at the level of the relevant component. A broad “AI involved” description does not tell a reader which numbers were verified, which text was edited or whether a quoted source supports the conclusion.
For publishers, the useful design is to join the provenance record to the editorial evidence record. Preserve the dataset version, calculation method, source date and reviewer decision as permitted by the workflow. Do not place confidential prompts, customer information or private source identities into a public manifest merely to make the history appear more complete.
Examine the asset that reaches the reader
Start the review from the actual distributed file or supported asset representation. A screenshot of a report, a recompressed social image and a downloaded original are different artifacts. Record which one was examined. If an agent extracted text from the original, retain enough lineage to connect the extracted passage back to the examined version.
Transformation is not automatically evidence of wrongdoing. Publishing workflows resize graphics, redact material and create derivatives for legitimate reasons. The reviewer’s job is to determine what history is available and whether it supports the specific claim. An unavailable ingredient should stay unavailable in the record; the agent should not invent the missing step.
Distribution testing can be commissioned as a separate, controlled task. Publish a permitted sample through the intended workflow, recover the delivered assets and compare the relevant validation results. State the file types, versions and transformations. This article offers that test design; it does not claim DN has measured credential preservation on social platforms.
Plan for signing failures and corrections
The official security considerations discuss key compromise, access to signing systems, revocation planning and privacy risks. A valid-looking provenance chain is not a reason to stop monitoring the signing infrastructure. The system needs a way to explain a compromised credential or a change in trust status without making unsupported claims about every historical asset. [4]
For an ordinary editorial correction, keep the reason for the correction separate from the signature state. A report can be correctly signed and wrong about a number. Publish a corrected version with a clear relationship to the earlier one, identify the changed claim and maintain the source evidence. Readers need to know whether the content changed, the provenance interpretation changed or both.
Similarly, an invalid result needs its actual diagnostic context. The wrong file, an unsupported feature or an altered asset can lead to different investigations. Do not turn the failure label into an accusation. The review record should make the remaining question visible and identify who is responsible for resolving it.
The DN Content Credentials Review Record
The instrument records an asset alias, validator version and date, the reported validation result and the particular factual claim under review. Its eight evidence areas cover asset binding, trust configuration, signer identity, assertions, history, facts, distribution and privacy. References may be entered, issues recorded or gaps left explicitly unknown.
There is no file upload. The instrument does not parse manifests, verify signatures, fetch trust lists or contact a blockchain. Its purpose is to prevent a reviewer’s findings from being compressed into a misleading binary badge. Every exported evidence entry is labelled as unverified by DN.
A reported trusted result produces a reminder that factual truth and authorship remain separate. A reported absent credential produces a reminder that absence does not establish falsity. A record with references in every area still requires review of those references. Completion of the form cannot authenticate a financial report.
DN Content Credentials Review Record
This tool records a reviewer’s statements. It does not parse files, validate C2PA signatures, contact trust lists or determine whether content is true.
Use non-sensitive aliases and reference labels. Inputs remain in this page’s temporary memory; downloading creates a local JSON file. Nothing is submitted to DN.
No record has been built. Missing evidence will remain visible.
Give the consuming agent a bounded instruction
A practical editorial policy might allow an agent to describe the provenance result while requiring independent evidence before repeating a market-moving claim. For the hypothetical revenue report, that means checking what “revenue” includes, matching the reporting period, reproducing the arithmetic where possible and identifying whether the figure is audited, issuer-reported or estimated.
The provenance record helps preserve the source version used for that work. The financial evidence determines whether the number is supportable. The authorization system determines whether any downstream action is allowed. Keeping these decisions explicit reduces the chance that a technically successful check becomes an unrestricted instruction to publish or trade.
DN’s social-management workflow comparison addresses the distribution layer. A tool that can schedule and publish efficiently still needs the editorial and provenance decisions described here. More automated distribution increases the value of a precise record; it does not lower the standard for the underlying claim.
Methodology, limitations and change log
Edition 1.0, 11 November 2026. DN reviewed technical specification 2.5, the guidance versions linked below, current conformance information and CAI SDK documentation. No adoption census, validator benchmark or cryptographic examination of a media outlet’s assets was conducted. The article does not certify a vendor or publication.
The JSON record uses dn.content-credentials-review.v1, version 1.0.0. Documentation review time, local record creation time and user-described validation time have different meanings. The export retains the input basis, evidence references and limitations so that a downstream system can preserve those distinctions.
Change log: Initial edition replaces the proposed on-chain adoption tracker with a scoped provenance review instrument. Update the article when specification, trust-list or validator semantics materially change. Corrections should provide the relevant asset alias, tool version and source evidence to press@decentralised.news; do not send confidential assets without arranging an appropriate review channel.
Frequently asked questions
Does C2PA prove a report is true?
No. It provides evidence about provenance and integrity within its trust model. Factual accuracy requires its own review.
Does a missing credential mean a deepfake?
No. The examination may lack provenance for many reasons. Missing credentials alone do not establish how content was created.
Is blockchain required?
No. C2PA does not require a distributed ledger. A separate ledger reference does not replace the content, identity or factual checks.
Does the DN tool validate my file?
No. It records the result and evidence you report from an appropriate validator and your separate review.
