Skip to main content

Verify

TECHNIQUE
πŸ“–11 min read

Introduction​

This is Stage 3 of the Research Gate. Preserve & Store secured the original: a read-only vault, a hash for every file, an open evidence log. This stage decides whether the material is what it claims to be. The collect stage ran on the working assumption that anything could be authentic, so nothing was filtered at acquisition. That assumption ends here: only material with a recorded verdict moves on to Process.

The Berkeley Protocol frames the stage as "establishing the accuracy or validity of information that has been collected online"[1]. It breaks verification into three considerations, looked at collectively and compared for consistency: the source, the digital item or file, and the content[1]. The work on this page follows the same three.

CRITICAL: The output of this stage is a log entry. Every verdict names its basis: what you checked, what you found, and what would change the answer. A verdict without a basis is an opinion, and an opinion does not gate anything.

The question

Per item: is this item what it claims to be? The answer, with its basis, goes to the evidence log before any processing.

Three considerations

Source, file, content: looked at together and compared for consistency, per the Protocol's verification chapter.

The verdict

Authentic, inconclusive, or not authentic, plus the weight the item carries. Inconclusive is a legitimate answer.


What this page is, and is not​

This page is the full authenticity pass on secured material. Input: the vault contents plus the evidence log. Output: a verdict per item, with basis and weight, written to the log.

  • Collect runs a preliminary check at capture: can you find the original file? The answer goes in the log, but no filtering happens there.
  • This stage re-runs that question with the full toolkit, adds the source and content checks, and issues the verdict.
  • Process transforms working copies. It starts after the verdict exists.
  • Analyze builds the reconstruction from verified material. It does not re-judge authenticity.

Source analysis​

The Protocol's first consideration is the source itself: "assessing a source's credibility and reliability"[1]. Online sources are often anonymous or pseudonymous, so the first step is attribution: determining where the item comes from, a website, an account, or the person who created it. Attribution may require extra search steps, and it may fail. The Protocol is direct about that: identifying authorship is helpful, but a lack of it "is not generally critical for establishing an online item's authenticity", because other ways to authenticate exist[1].

Work through five source checks:

Provenance. The origin or earliest known existence of the content. For online material, record the "first copy found online", not the first copy online: the original may be removed, and closed channels like email or private groups may have carried the item before it appeared publicly[1]. This is the record define calls the one you can never fully prove. The collect stage logged what was known at capture; this stage deepens it with the original-file pass below.

Credibility. The source's posting history, online activity, and internet presence weigh for or against it. A source posting about events in a particular country: do the surrounding posts suggest the source was actually there? A mismatch can reveal a deliberate attempt to deceive[1].

Independence and impartiality. Affiliations, organizations, and how the source makes money. Is there a connection to any party involved in the incident? Ideology and group affiliation count as well. The Protocol asks investigators to uncover the underlying motivations, interests, or agendas, and the degree to which these might influence veracity[1].

Specificity. The more precise a claim, the easier it is to prove or disprove. Broad and vague claims are harder to assess critically[1]. When a source makes a broad claim, narrow it to a testable one before checking.

Attenuation. Text drafted contemporaneously with the events is generally more reliable than text produced long afterward[1]. For open source material this check can be hard, when it is unclear when a text was created. Record what you can establish, and say what you cannot.


Finding the original​

The preliminary question from collect, run with the full toolkit: where is the earliest copy of this item, and what does it show?

  • Reverse image search. Exact-match search (TinEye) finds byte-identical copies and earlier timestamps; approximate search (Google Lens) finds visually similar images. Treat every hit as a lead: a match places the item in a chain of copies, and the earliest copy in that chain is what you want.
  • Archives. The Wayback Machine and other caches hold the page that carried the source, with its original timestamp. An archived capture can be the earliest public appearance you can document.
  • EXIF and embedded data. Creation dates, device identifiers, and geodata inside the file often predate every copy. Run this check once and use it twice: here, and in the technical analysis below.
  • Visual clues. Architecture, vegetation, power lines, street furniture, reflections, and shadows can place the item in a location and a season, which dates it indirectly.
  • Opsec. External search tools upload the image to a third party. If the item is sensitive or the source is protected, note which tool received the image and when, in the evidence log, so the chain of custody covers the search itself.

The field walk-throughs run this same pass for a single item: reverse search for earlier copies, EXIF where present, visual clues, archive checks[2]. Whatever the pass finds goes to the log: the earliest copy located, with URL and date, or a statement that the earliest copy could not be found and what you searched. A documented not-found is a stronger record than a silent skip.


Technical analysis​

The Protocol's second consideration is the file itself: testing "the integrity of a file, that is whether it has been digitally altered, manipulated or modified"[1].

Integrity first. Before any content judgment, re-hash the material you are examining and compare it to the vault record from preserve-store. A match confirms the copy is the one that was sealed. A mismatch stops the stage: restore from the vault, re-verify, and log the event. The fixity loop from preserve-store runs here too, on every access.

Metadata. Metadata describe the item: creator, creation date, upload data, modifications, file size, geodata. They may be embedded in the file, visible on a web page, or present in source code. Two caveats from the Protocol. Some metadata are stripped before or during upload, and platforms transcode uploaded media, so surviving metadata may describe the platform's copy, not the original[1]. That is the platform-strip point: a missing or rewritten field tells you about the chain of copies, and where metadata are stripped, the Protocol says researchers should seek other ways to verify the item.

EXIF. For images and audio, exchangeable image file format data specify the formats used by cameras and scanners: the device that made the file, and when.

Source code. For web items, the page's source code may hold meta-content, hidden or manipulated content, and the link structure, including broken links[1].

The output of this section is a single statement: what the file shows, what was stripped, and what survives to support or undercut the item's claims.


Content analysis​

The Protocol's third consideration is what the item depicts: "the process by which the information contained within a video, image, document or statement is assessed for its authenticity and veracity"[1].

Unique identifiers. Start with distinctive features: buildings, flora and fauna, people, symbols, insignia. One caution from the Protocol: analyzing human features to identify a specific person usually requires the specialized skills of a forensic expert; lay identifications can be inaccurate and prejudicial[1]. Describe what a person is doing. Identifying who they are is a different discipline.

Objectively verifiable information. Some content checks against external records: the weather on a specific day, the name and rank of a commanding officer, the location of a building. The Protocol expects an examination of the content against exactly this kind of information[1].

Chronolocation. Corroborating the dates and times of the events depicted, usually visual imagery: shadow length against the sun's position, lighting conditions, other time markers[1].

Geolocation (the option). The identification or estimation of the location of an object, an activity, or the position from which an item was generated, for example by matching unique geographic features in a photograph to their position on a map[1]. This is an option, taken when the material is fitted: a still image or a video with visible, identifiable features such as landmarks, vegetation, power lines, or street furniture. The field method is the Bellingcat walk-through: reverse search for earlier copies, EXIF where present, visual clues matched to maps, and shadow and sun-time checks to date the scene[2]. The suitability question is part of the stage: can this be geolocated, and is it worth doing? When the answer is no, close the option and log it. A closed option is a record, and a silent skip is a gap.

Completeness. An incomplete document or clip may still be probative, but the gaps affect the weight the item carries. The Protocol asks collectors to capture the file in its entirety and its surrounding context[1], and to note here what is missing.

Internal consistency. A single item should be consistent and coherent on its own terms: it should not contradict itself. A body of material from the same source or provenance gets the same check across items[1].

External corroboration. Information outside the item that coincides with its content supports the item's veracity[1]. Corroboration is the check that keeps a single compelling item from carrying the whole finding.


The verdict​

The three considerations converge on one question per item: is this item what it claims to be? The stage answers it with three possible verdicts:

  • Authentic. The item is what it claims to be, on the evidence recorded in the log.
  • Inconclusive. The evidence does not reach a decision. SWGDE's video best practices make this an expected outcome: where the opinion "cannot definitively answer the question being asked, an answer of 'inconclusive' may be the only appropriate response"[3].
  • Not authentic. The evidence shows the item is not what it claims to be. The item leaves the reconstruction, and the log keeps the reason.

Every verdict carries weight: "the value attributed to an item and the degree to which it will ultimately be relied upon in drawing a legal or factual conclusion". The Protocol wants that determination to be a holistic assessment that depends on "the other information that may support, corroborate or contradict the fact in question"[1]. Weight is what lets a reviewer use a partial result: an inconclusive item with strong corroborating weight can support a finding that states its limits, the same rule the report stage applies.

The verdict entry goes to the evidence log: item, verdict, basis (which checks ran and what they showed), weight, date. The verdict gates the Process stage. Material with a verdict of authentic proceeds. Inconclusive material may proceed only with its limits stated where it will be used. Material with a verdict of not authentic does not enter the working tree.


The Standards Behind This Practice​

StandardWhat it isWhat it covers here
Berkeley Protocol, part VI.E (ΒΆ176-194)[1]The UN/Berkeley verification chapter for open source investigationsThe three considerations: source, file, content
SWGDE 18-V-001-2.0 (2025)[3]U.S. consensus best practice for digital forensic video analysisThe opinion rule: inconclusive as a legitimate answer
Bellingcat geolocation walk-through (2022)[2]A published field method for placing an image in a locationThe geolocation option: search, EXIF, visual clues, shadow time

Summary​

This stage turns "I have the files" into "I know which files I can use, and why." In order:

  1. Source. Attribution, provenance, credibility, independence, specificity, attenuation: who, and why it should be believed.
  2. Original. The earliest copy, found or documented as not found: reverse search, archives, EXIF, visual clues, opsec noted.
  3. File. Hash re-verified against the vault; metadata reviewed with the platform-strip caveat; EXIF and source code where present.
  4. Content. Identifiers, objectively verifiable information, chronolocation, completeness, internal consistency, external corroboration.
  5. Geolocation. Taken when the material is fitted and logged; closed and logged when it is not.
  6. Verdict. Authentic, inconclusive, or not authentic, with basis and weight, written to the evidence log.

The stage ends where Process begins: the material that proceeds has a recorded verdict, and the log shows the basis for each one.