Jump to content

Metopedia digital evidence standards

From Metopedia



This page governs digital evidence used on Metopedia. It covers screenshots, files, logs, metadata, hashes, archives, provenance, AI-manipulation concerns, and chain-of-custody notes. Source hierarchy appears in Metopedia:Source standards, and file-upload rules appear in Metopedia:File and media standards.

Metopedia digital evidence standards
Type Evidence standard
Applies to Screenshots, files, datasets, logs, web pages, emails, PDFs, images, videos, archives, code, metadata, and AI-manipulation claims
Core rule Digital evidence must be preserved with enough provenance, context, and integrity information for another reader to inspect what was used.
Related pages Metopedia:Source standards, Metopedia:Research method, Metopedia:File and media standards, Metopedia:Transparency report

Digital evidence includes any source material stored, displayed, transmitted, captured, or preserved in digital form. On Metopedia, digital evidence may include screenshots, documents, file metadata, web archives, logs, emails, PDFs, images, videos, source code, export files, DOI records, platform notices, social-media posts, hash manifests, or structured datasets.

The purpose of this standard is not to turn every Metopedia page into a courtroom exhibit. The purpose is to keep digital claims inspectable. A reader must be able to understand what was captured, where it came from, when it was captured, how it was preserved, what may have changed, and what the evidence can or cannot establish.

Core principles

Principle Meaning
Preserve before interpreting Capture and record the source before building a conclusion from it.
Record provenance Identify where the item came from, who created it when known, when it was accessed, and how it was obtained.
Protect integrity Store originals separately from edited, annotated, cropped, OCR-processed, compressed, or resized versions.
Separate source from analysis The original evidence, the processed version, and the interpretation must not be merged into one untraceable object.
Hash important files Use fixity checks for important files, datasets, screenshots, archives, and evidence packages.
Disclose uncertainty State when authenticity, origin, capture method, date, or chain of custody is incomplete.

NIST defines chain of custody as a process tracking evidence through collection, safeguarding, and analysis by documenting who handled it, when it was collected or transferred, and the purpose of transfer.[1] Metopedia uses this concept in a non-court editorial form: document enough handling history to make evidence use transparent.

Evidence levels

Level Description Use on Metopedia
Original digital object The file, page, email, log, dataset, source code, or image in its most direct available form. Highest practical preservation target.
Verified copy A copy with hash, archive, metadata, or documented transfer record. Strong evidence when the original is not publicly accessible.
Screenshot or capture Visual capture of a page, message, interface, or file state. Useful evidence, especially when accompanied by URL, timestamp, and archive.
Archive record Web archive, DOI landing page, repository record, or preserved page copy. Useful for source stability and dead-link prevention.
Transcript or OCR text Text extracted from speech, image, scanned page, or screenshot. Must be checked against the original when accuracy matters.
Summary of evidence A paraphrase of what the evidence shows. Requires citation and must not replace preservation.
Unverified claim about evidence A person says a file, screenshot, or message exists. Treated as a claim until the evidence is inspected.

Minimum documentation

When adding digital evidence, record as many of the following fields as practical:

Field Requirement
Source URL or origin The page, repository, sender, device, archive, DOI, platform, or file source.
Access date Date and time when the evidence was viewed, downloaded, captured, or received.
Creator or uploader Person, institution, platform, account, or unknown status.
File name Original file name and any renamed file.
File type PDF, PNG, JPG, TXT, CSV, DOCX, XML, MP4, HTML, ZIP, TAR, or other format.
File size Size in bytes when relevant.
Hash SHA-256 preferred for important evidence files.
Capture method Browser screenshot, browser save, platform export, API query, command-line download, manual copy, OCR, scan, or camera photo.
Processing Cropping, resizing, annotation, OCR, compression, conversion, redaction, enhancement, or analysis.
Preservation location Uploaded file page, archive link, repository link, evidence table, local retained copy, or source record.
Limits Missing metadata, incomplete chain, possible edits, unstable source, login-only access, private source, or redactions.

Hashes and fixity

A hash is a fingerprint of a file. It helps confirm that a file has not changed. SHA-256 is the preferred default on Metopedia.

NIST digital-evidence preservation guidance identifies hashing digital images and other objects with a NIST-approved hashing algorithm as a best practice, with hashes stored separately from the evidence object.[2]

Use hashes for:

  • original evidence files;
  • exported account data;
  • ZIP/TAR evidence bundles;
  • important screenshots;
  • datasets;
  • code packages;
  • downloaded PDFs;
  • images used for forensic comparison;
  • files involved in malware, chain-of-custody, or alteration claims.

Example command: 

sha256sum evidence-file.pdf

Record the output in the file description page or evidence table: 

SHA-256: 4f8e6c... [full hash]

Do not hash only the edited version when the original is available. Preserve and hash the original first.

Screenshots

Screenshots are acceptable digital evidence when the original source may change, disappear, or require login access. They are not automatically proof of authenticity.

A screenshot evidence record must include:

  • source URL or platform;
  • date and time captured;
  • browser or device when relevant;
  • visible account context if relevant and safe;
  • whether the image was cropped or annotated;
  • archive link when possible;
  • transcription of important visible text;
  • redaction note if private information was hidden.

Do not rely on screenshots alone when stronger evidence is available. Pair screenshots with archive links, downloaded source files, headers, metadata, DOI records, page history, or independent captures where possible.

Web archives

Archive unstable web pages. Use archive services to preserve source pages, platform notices, public records, and references likely to change.

Record:

  • live URL;
  • archive URL;
  • date archived;
  • date accessed;
  • whether the archive captures the relevant content;
  • whether scripts, images, or documents failed to load.

An archive is evidence of what the archive captured. It is not proof that the page was never different before or after capture.

Metadata

Metadata can support provenance, but it can also be stripped, altered, generated by software, or misleading.

Common metadata fields:

  • file creation time;
  • modification time;
  • camera/device model;
  • software used;
  • embedded author;
  • GPS data;
  • image dimensions;
  • compression type;
  • PDF producer;
  • document revision data.

Use metadata as supporting evidence, not as a final conclusion unless the context justifies it. When metadata is important, preserve the original file and note the tool used to inspect metadata.

Example tools: 

exiftool image.jpg
pdfinfo document.pdf
mediainfo video.mp4

Emails and correspondence

Emails may be used as evidence when correspondence is directly relevant.

Preserve:

  • sender;
  • recipient if safe to disclose;
  • date and time;
  • subject;
  • message body;
  • attachments;
  • relevant headers when authenticity is disputed;
  • redactions for private addresses, phone numbers, tokens, or unrelated personal data.

Use correspondence boxes or blockquotes for formal letters. Do not publish unrelated private content because it appears in the same email thread.

Logs and technical records

Logs are useful for server events, import errors, moderation actions, file access, command output, malware blocks, and system behavior.

A log excerpt must include:

  • system or application name;
  • date/time zone;
  • command or process if relevant;
  • exact error message;
  • redactions;
  • surrounding context enough to interpret the event.

Do not publish secrets, passwords, API tokens, session cookies, private keys, IP addresses of uninvolved users, or private account identifiers unless there is a specific public-interest reason and redaction review.

AI-generated or AI-altered evidence

AI-generated material can be evidence of what an AI system produced. It is not evidence that the underlying facts are true.

When using AI-generated or AI-assisted material:

  • identify the tool if relevant;
  • record the prompt or task where useful;
  • preserve the output date;
  • verify factual claims against external sources;
  • do not cite AI output as a primary factual source;
  • label AI-generated images, transcripts, summaries, and reconstructions.

When alleging that evidence is AI-generated, manipulated, deepfaked, or synthetic, state the basis:

  • visual artifacts;
  • metadata inconsistency;
  • source history;
  • model watermark;
  • platform disclosure;
  • forensic analysis;
  • independent expert review;
  • comparison with known originals.

Do not dismiss evidence as “AI” merely because it conflicts with an existing belief. That pattern overlaps with Source Attribution Bias.

Image and video forensic caution

Image analysis, compression analysis, error-level analysis, lighting comparison, metadata analysis, and frame inspection can be useful. They can also be overread.

Rules:

  • preserve the original image or video when possible;
  • state whether the file is original, resized, reposted, compressed, downloaded, cropped, or platform-processed;
  • identify tools and settings;
  • compare like with like;
  • avoid claiming “proof of manipulation” from a single artifact unless the method supports that conclusion;
  • distinguish “inconsistent with the expected pattern” from “confirmed fake.”

Redactions

Redactions must be visible and explained. Do not silently alter evidence.

Use redaction for:

  • private email addresses;
  • phone numbers;
  • home addresses;
  • account tokens;
  • passwords;
  • private messages unrelated to the claim;
  • names of uninvolved private persons;
  • sensitive security details.

Mark redactions clearly: 

[redacted email address]
[redacted private account token]

Chain-of-custody notes

Use chain-of-custody notes for evidence where handling history affects trust.

A Metopedia chain-of-custody note may include:

  • who captured the item;
  • date captured;
  • source location;
  • storage location;
  • processing steps;
  • hash of original;
  • hash of derivative;
  • transfer method;
  • known gaps.

SWGDE digital-evidence collection guidance states that documentation includes chain of custody and an evidence inventory, and may include descriptions, photographs, device state, physical characteristics, software used, logs, reports, screenshots, downloaded data size, and collection notes.[3]

Evidence tables

Use evidence tables for complex investigations.

Recommended columns:

Column Purpose
Item Short name of the evidence item.
Source URL, file page, DOI, platform, sender, or archive.
Date Date created, accessed, received, or captured.
Status Live, archived, removed, disputed, redacted, unavailable, unverified.
Integrity Hash, archive, original retained, screenshot only, metadata available.
Relevance What the item supports.
Limits What the item does not establish.

Authentication and verification

Verification depends on the evidence type. Use multiple methods when a claim is important.

Evidence type Verification methods
Public web page Live page, archive, screenshot, page history, independent capture, source code.
DOI record DOI resolver, repository landing page, DataCite/Crossref metadata, archive.
Image Original file, metadata, reverse search, hash, source page, compression history.
Video Original file, frame inspection, metadata, source upload, transcript, audio comparison.
Email Headers, sender domain, DKIM/SPF/DMARC results, attachment hashes, thread context.
Dataset Source repository, checksum, version, schema, sample validation, documentation.
Code Repository history, commit hash, release tag, dependency list, reproducible output.
Malware/security claim Sandbox report, hashes, scanner outputs, file origin, network indicators, safe handling notes.

Limits and uncertainty

Every digital evidence page must state important limits. Examples:

  • screenshot only;
  • archive missing images;
  • metadata stripped by platform;
  • source behind login;
  • file obtained from third party;
  • hash unavailable;
  • chain of custody incomplete;
  • OCR uncertain;
  • redactions present;
  • file may have been platform-compressed;
  • timestamp may reflect download time rather than creation time.

Minimum rule by claim strength

Claim strength Minimum digital evidence standard
Routine claim Stable citation or archive.
Disputed claim Citation plus archive, screenshot, or preserved source.
Removal/takedown claim Screenshot, URL, date, platform notice, archive if possible, and source status.
File-integrity claim Original file, hash, metadata, and processing notes.
Forgery/manipulation claim Original or closest available file, method, tools, comparison, and limitations.
Security/malware claim Hash, sandbox/scanner report, safe-handling note, and no direct unsafe download link without warning.

See also

References

  1. ↑ NIST CSRC Glossary, “Chain of Custody.” https://csrc.nist.gov/glossary/term/chain_of_custody
  2. ↑ Barbara Guttman et al., NIST IR 8387, Digital Evidence Preservation, 2022. https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8387.pdf
  3. ↑ Scientific Working Group on Digital Evidence, “Best Practices for Digital Evidence Collection,” 2025. https://www.swgde.org/wp-content/uploads/2025/07/2025-06-30-Best-Practices-for-Digital-Evidence-Collection-18-F-002-2.0.pdf
Retrieved from "https://metopedia.com/index.php?title=Metopedia:Digital_evidence_standards&oldid=1051"