Resources · 10

Information integrity: verify provenance, context and transformations

A procedure for qualifying a document, image or video before citing, sharing or using it in a decision.

Updated 23 October 2026 · 10 min

Illustration · fictional scene

What this guide helps achieve

Find the earliest accessible version
Separate a genuine file from a false caption
Document transformations
Correct without erasing the trail

Quick check

Who published the file and where did they get it?
Does an earlier version exist?
Are location and light compatible?
Are metadata consistent but not treated as sufficient?
Which content depends on this evidence?

Step-by-step method

01
Preserve the item
Retain the URL, access date, received file, visible context and a hash where lawful. Work on a copy and record every conversion.
Deliverable: log entry and hash.
02
Trace provenance
Look for the earliest publication, claimed creator, intermediary relays and any cropped or recompressed versions.
Deliverable: provenance chain.
03
Check content and context
Compare terrain, buildings, weather, shadows, language, chronology and known events. A genuine image can be reused with a false place or date.
Deliverable: confirmed and rejected hypotheses.
04
Inspect metadata
Use EXIF, encoding, dimensions and history as clues. Their presence or absence never proves authenticity alone.
Deliverable: interpreted technical record.
05
Corroborate independently
Find a primary source, another angle, official record or independent witness. Identify repetitions that all depend on the same file.
Deliverable: corroboration matrix.
06
Publish and correct
State confidence, limitations, method and source. If the conclusion changes, update linked pages and keep a dated correction note.
Deliverable: editorial decision and correction register.

Understand · try · decide

Real photograph: separate image, caption and publishing page

NASA describes this “Earthrise” image as a Lunar Orbiter 1 view, with Earth to the right of the Moon, and credits NASA. The page displays a 2017 publication date. That page date alone does not date the capture. The title “Earthrise” alone cannot attribute an image to a mission.

Start with a specific claim to check: which object, mission, date or place? Return to the institutional page and retain the file link. Compare visible details with the caption; record transformations made for display.

A credit or institutional source documents provenance without validating every interpretation of an image. A file hash similarly identifies a particular copy; it does not prove the scene is true. For publication, record separately what the source states and what you have verified.

Reference points and evidence to retain

Reference point	What you can conclude	Evidence to retain
File	The copy you consulted	File URL, consultation date and hash
Caption	Attribution given by the publisher	Mission, credit and source-page text
Page date	Information about publication	Exact label; capture date checked separately
Rights and transformations	Reuse conditions and modifications	NASA guidelines, credit and local resizing

From observation to decision

State the claim
Find the source
Compare file and caption
Record the limits

Two Earthrise images, two attributions

A shared title does not identify a unique file. The first NASA page attributes its view to Lunar Orbiter 1. The second credits the colour photo to Bill Anders on Apollo 8 and separates its historical date from publication. Comparing both files helps verify attribution before interpretation.

NASA photograph showing the lunar surface with Earth on the right. — Real photograph — NASA, Lunar Orbiter 1. Copy resized for the website. Source and reuse guidelines below. NASA — Lunar Orbiter 1

NASA colour photograph showing blue and white Earth above the grey lunar horizon. — Real photograph — NASA/Bill Anders, Apollo 8. Historical date listed: 24 December 1968. Resized copy with no alteration to the scene. NASA/Bill Anders

Read the date labels on the Apollo 8 page
Displayed date	Label and scope	Supported conclusion
24 December 1968	Historical Date	Historical date attributed to the photograph by NASA.
22 February 2019	Page publication date	Date of this publication, separate from the event.
9 September 2023	Original, under Downloads	Displayed date for this download entry, not a new photograph.

Dates read on the NASA page accessed on 14 October 2026. A local file date after download does not replace any of these labels.

Minimum attribution record
Element	Lunar Orbiter 1 copy	Apollo 8 copy
Title	Earthrise	Apollo 8’s Iconic Earthrise
Mission in source	Lunar Orbiter 1	Apollo 8
Credit in source	NASA	NASA/Bill Anders
Visual cue	Earth on the right of the lunar view	Blue and white Earth above the grey horizon

Visual cues help match a copy to its source; they are not independent proof of location or date.

Checks before concluding

Identify the claim, source page and exact file. A search result or thumbnail is insufficient.
Record mission, credit and date labels separately; do not turn a publication date into a capture date.
Retain a description of transformations: resizing here, or cropping and retouching if another publisher applies them.
Check reuse conditions and any third-party rights. A NASA credit does not imply NASA endorsement of this website.

Decision: attribute each copy to the mission stated by its own source. A real scene can carry an incorrect caption even when the file is unaltered.

Change an assumption

Check the caption before judging the file

The historical photographs above show why attribution must be checked separately from whether a scene is real.

Identify
Match the copy to the Lunar Orbiter 1 view or Apollo 8 photograph.
Attribute
Record mission, author or credit and historical date from the matching source.
Publish
Describe the copy and its transformations without repeating an unverified caption.

Reading exercise: the variations describe fictional situations.

What if the filename contains “Apollo”?

New evidence: The view matches Lunar Orbiter 1 despite its filename.
What changes: A local name can be changed freely. Prioritise the match to the source and explain the attribution error.

What if the page was updated this week?

New evidence: The recent date concerns the page or record, not necessarily the photograph.
What changes: Keep historical, publication and update dates separate. A site date alone does not establish a new exposure.

Worked example

Illustrative situation

A viral image claims to show a recent event. The team searches for the earliest publication, compares visible locations and reads provenance metadata if present.

Decision and expected evidence

The note separates what technical provenance attests, what independent sources confirm and what cannot yet be concluded.

Management indicators

Indicator	What it measures	First action
Provenance	Items connected to a documented origin	Handle decisive evidence without a source first
Corroboration	Conclusions supported by independent clues	Remove circular repetition
Correction delay	Time from discovering an error to updating content	Maintain the dependent-page list
Visible unknowns	Important limitations stated explicitly	Prevent a hypothesis becoming a fact

Common pitfalls

Treating missing EXIF as proof of fabrication
Stopping after an empty reverse search
Counting republications as independent sources
Correcting one page but not its copies

Frequently asked questions

Do metadata prove an image is genuine?

No. They can be removed, altered or inherited from a device. Corroborate them with content, context and provenance.

How should synthetic content be handled?

Look for available provenance information, examine consistency and context, then assess the truth of the associated claim.

Should an error be deleted?

Correct the content and its distribution clearly. When it has already influenced readers, a dated note explains the change better than silent disappearance.

References: data, uses and limitations

Documentation reviewed on 2026-10-22.

References: data, uses and limitations
Source and purpose	Verified data or benchmark	How to use it	Limitation to retain
FIRST · Traffic Light Protocol Indicate who may receive redistributed information.	TLP 2.0 uses RED, AMBER, GREEN and CLEAR; AMBER+STRICT restricts sharing to the recipient organisation. Labels must not be translated.	Keep the marking with the information and check recipients before forwarding. Ask the source to clarify any ambiguity. Explore the method →	TLP is neither a formal classification nor a reuse licence. It does not guarantee content accuracy.
C2PA · Content Credentials Describe and verify certain content provenance information.	C2PA specification 2.4 defines manifests, assertions and cryptographic binding mechanisms associated with media.	Examine what the manifest asserts, who signed it and whether validation succeeds. Test preservation after transformations and distribution. Explore the method →	Validated provenance does not establish the truth of a scene. Absence of a manifest does not demonstrate a fake.

Media provenance and C2PA validation

A provenance report combines findings with different scopes. Signature, credential trust, content binding and scene context are separate assurances. Retain the exact asset and full report before summarising a result.

References use C2PA 2.4, dated April 2026 in its version history. This explorer explains twelve selected codes; it validates no file, retrieves no manifest and detects no AI-generated image. Cases are fictional and proposed checks are editorial guidance.

References consulted on 2026-10-22.

Four technical dimensions, followed by a separate context check

Read twelve C2PA codes without overinterpreting them

The groups below are those used by the specification: success, informational and failure. A success code describes its particular check rather than replacing full validation. Missing information and a failed check cannot be reduced to a fake label.

Read twelve C2PA codes without overinterpreting them
Code and group in C2PA 2.4	Reported finding	Proposed follow-up	Conclusion to avoid
`claimSignature.validated` Success · success	The claim signature validated.	Also inspect trust, validity period and binding to the relevant asset.	The whole scene is true or every validation check is complete.
`signingCredential.trusted` Success · success	The validator recognises the signing credential as trusted.	Record the trust list, its version and applied policy.	A signer’s name alone confirms the depicted event.
`timeStamp.validated` Success · success	The time-stamp token passes the checks described in the specification.	Distinguish it from capture time and inspect trust in the time-stamping authority.	The attested time necessarily dates the photographed scene.
`assertion.dataHash.match` Success · success	The data-hash binding matches within the checked scope.	Inspect the assertion, excluded ranges and any other applicable bindings.	Every byte and every metadata field is covered without exception.
`signingCredential.ocsp.inaccessible` Information · informational	An online OCSP check was attempted without a response.	Retain network conditions and distinguish no response from a returned status.	The certificate is revoked, or certainly not revoked.
`signingCredential.ocsp.unknown` Information · informational	The OCSP response reports unknown for the signing credential.	Read the report and the policy used to handle that status.	Unknown means good or revoked.
`ingredient.unknownProvenance` Information · informational	The relevant ingredient has no C2PA manifest.	Identify that ingredient and what its history actually makes available.	All ingredients were verified or that ingredient must be fake.
`assertion.dataHash.additionalExclusionsPresent` Information · informational	The binding excludes ranges beyond the C2PA Manifest Store.	Identify the excluded regions and their relevance to the claim being examined.	A hash success automatically protects excluded metadata.
`claimSignature.mismatch` Failure · failure	Claim signature verification fails.	Retain asset, manifest and report; compare with the available source copy.	The cause of failure or somebody’s intent is already established.
`signingCredential.untrusted` Failure · failure	The credential appears on none of the validator’s applicable trust lists.	Check policy and lists; distinguish this from a mathematically incorrect signature.	The file must be fabricated or its signature must be mathematically invalid.
`assertion.dataHash.mismatch` Failure · failure	An asset byte range does not match the hash declared in the assertion.	Identify the checked copy and its transformations before explaining the difference.	Every difference establishes intentional falsification of the scene.
`signingCredential.ocsp.revoked` Failure · failure	The OCSP response indicates revocation under the applied check.	Read the temporal evidence and validation procedure behind the result.	A summary detached from its date and report establishes the status of every copy.

C2PA 2.4 · §15.2 →

Four version details useful to editorial and technical teams

Published version: The history dates C2PA 2.4 to April 2026. Record your validator version: reading a recent specification does not update the tool.
specVersion: In this version the recommended field belongs in claim_generator_info. It is informational; validators should not change logic solely because of its value.
crJSON: This JSON-LD representation is a derived view of C2PA data for reporting and interoperability. It is not independently verifiable or a validation input format.
c2pa.ai-disclosure: The assertion carries an AI transparency declaration. It is not a universal detector, and its absence does not prove human origin.

Six fictional situations for a publication decision

Six fictional situations for a publication decision
Fictional situation	Concrete check	Decision proportionate to evidence
A signed photo receives a new caption	Match the asset and report against the scene, date and location claimed by the new caption.	Describe checked provenance and leave the event attribution unresolved if uncorroborated.
A resized variant no longer matches the old binding	Compare original, transformation tool, distributed variant and manifest associated with each.	Handle the validation break without inferring malicious manipulation from the hash code alone.
Two validators do not trust the same signer	Record versions, trust lists and policy, then compare other findings.	Explain the trust-policy difference rather than treating it as contradictory truths about the scene.
A screenshot no longer presents a Content Credential	Seek the earlier asset and document the known copy chain.	Retain the screenshot’s status and incomplete history; an absent manifest does not establish a fake.
A binding success accompanies excluded metadata	Identify excluded fields or ranges and caption claims depending on them.	Limit the conclusion to covered data and verify decisive fields another way.
A supplier sends only a crJSON report	Request the asset and provenance data needed for verification, plus tool version and policy.	Examine the report without claiming to have repeated cryptographic validation.

Retain a usable verification record

Exact object: Examined asset or stream, known origin, copy and transformations.
Tool and policy: Validator, version, configuration and relevant trust lists.
Complete findings: Codes, relevant object, explanations and time evidence; keep inconclusive information as well.
Examined claim: Exact statement about location, date, creator or AI use and its source.
Editorial decision: What is established, what is missing and what could change the conclusion.

Examine information origins and repetitions →

Primary sources and limits of this reader

This is not an exhaustive C2PA code inventory. Full procedures, formats and trust policies remain those of the specification and your validator. Diagrams, cases and records are CIE teaching proposals.

C2PA · Content Credentials Technical Specification 2.4 · 2.4 · April 2026 · 2026-04
§5.3.1; §14.3; §15.2; §15.7–15.12
C2PA · Content Credentials Explainer · 2.4
§2; §7.2–7.4
C2PA · Security Considerations · 2.4
§2.2–2.6; §4; §5

STIX indicators and TLP sharing

Check TLP scope before publishing an excerpt

A traceable note does not by itself grant permission to redistribute it. TLP markings, additional restrictions and intended recipients must accompany a redaction or publication decision.

AMBER+STRICT limits sharing to the organisation; AMBER’s scope for protecting clients does not apply by default.
GREEN excludes public channels; CLEAR does not remove copyright rules or separate restrictions.
Check the marking of each quoted field and obtain explicit source permission if the intended sharing exceeds the received scope.

Read the STIX, observations and TLP sharing reference →

Sources checked on 2026-10-22 · FIRST · TLP 2.0

OSINT: evidence preservation

Claimed provenance and preservation answer different questions

An edit history or manifest does not replace collection context. Preservation connects objects actually received, copies created and documented handling actions.

Separate binary integrity, source identity and an assertion’s truthfulness.
Keep derivative versions with their own identifiers and references.
Document missing material before reaching a trust conclusion.

See copy lineage and the eight preservation cases →

Sources reviewed on 2026-10-22 · NIST · Digital Evidence Preservation · NIST IR 8387 · Full report · NIST · SP 800-86 · NIST SP 800-86 · Full report · NIST · FIPS 180-4 · Secure Hash Standard

PDF: redaction and release

A documented transformation still needs release review

Derivative lineage explains technical provenance; it does not prove all excluded information was removed. Visible, hidden and embedded surfaces still need checking.

Separate pending marks, applied redaction and hidden-data sanitization.
Check a positive control before interpreting a negative search.
Bind the decision to the delivered version and its recipients.

See surfaces and the pre-sharing review matrix →

Sources reviewed on 2026-10-22 · Adobe · Redacting and sanitizing PDFs · Adobe · Redact sensitive content · Adobe · Sanitize PDFs · ICO · Avoid accidental breaches when redacting · ICO · Hidden information in documents · Microsoft · Document Inspector

Citation chains and social monitoring

Separate origin, repost and corroboration

A capture or provenance signature may document a record without proving its claim. Before citing multiple publications, check whether they reference the same document.

Keep the consulted version and its exact reference.
Name missing citations instead of assuming their contents.
Treat distinct documents as records to compare, without assuming independence.

Read the method and explore citation chains →

Government Communications · RESIST 3 · RESIST 3 · 2025 · consulted 2026-10-23

Government Communications · RESIST 3 quick reference · RESIST 3 · 2025 · consulted 2026-10-23

Official references

References consulted: 23/10/2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.