Skip to content
PlagiatScanner.de
Examination procedures · information · PRV-14

File metadata as evidence of independent work

In brief: Metadata can identify the file examined, preserve a system-recorded timestamp and show whether two byte sequences match. On its own, it does not establish who wrote the text or what happened between saved versions. Preserve the source file, record collection method and time zone, calculate a checksum, and interpret each field according to its technical layer. Combine those observations with contemporaneous drafts, research records and feedback.

Metadata evidential-weight matrixSources reviewed 4 September 2026

Start by identifying the technical layer

The word metadata covers several distinct sources. A file system records properties of the copy stored on a particular volume. Word-processing software embeds document properties. A PDF exporter may name its generating application. A cloud platform keeps account events. These systems do not necessarily describe the same moment or actor.

Copying, downloading, extracting an archive or restoring a backup can reset file-system creation times. An author field may come from a shared template or configured profile. “Total editing time” may include a document left open or exclude work completed in another application. Such fields are contextual clues, not direct observation of a person composing text.

Preserve first, inspect second

Do not experiment on the only copy. Place the received object in a protected evidence folder and record its source, collection route, date, local time zone and responsible person. Calculate a SHA-256 checksum. That digest can later identify the same bytes; it does not authenticate the content’s author or truth.

Use a working copy for inspection. Record the extraction software and version, and export findings as readable text where possible. Some applications update document properties when a file is opened or saved. If the workflow changes any bytes, calculate a new checksum and preserve both states with a clear relationship.

Authority asset: metadata evidential-weight matrix

What common fields may support, and what they cannot establish alone
FieldMay supportDoes not proveQuestion to ask
File-system creationWhen this copy appeared on this file systemWhen its content was first authoredWas it downloaded, copied or restored?
File-system modificationA saved change affecting this objectNature, extent or author of the changeWhich clock and time zone applied?
Office authorThe profile name stored in a propertyThe identity of the writerWas a template or shared device used?
Editing time/revisionApplication-specific activityFocused writing time or independent workHow does this software define the value?
PDF creator/producerThe named export application or libraryAuthorship of the source documentWere there intermediate conversions?
ChecksumWhether compared bytes are identicalProvenance, accuracy or authorshipWhen and under whose control was it recorded?
Cloud eventAn action associated with an accountThe human operating the account or offline activityIs the export complete and attributable?

Read DOCX, PDF and operating-system properties separately

A DOCX file is a package containing XML and other resources. Core properties can name a creator, last modifier and dates, but templates, “save as”, privacy inspection and third-party libraries can change them. A revision number is not a universal count of substantive drafts. Interpretation should rely on documentation for the software path actually used.

PDF properties often illuminate conversion rather than composition. Creator and producer fields may identify the source application and PDF engine. Printing to PDF, merging files or optimisation can replace them. A plausible producer value does not show who wrote the text before export.

Operating-system timestamps belong to a storage instance. Cloud synchronisation and backup restoration can alter them without changing the document’s internal content. Conversely, internal properties can remain unchanged while the outer file-system dates move. Record both layers instead of selecting whichever supports a preferred narrative.

Combine technically independent records

Metadata becomes more informative when it corresponds with meaningful content changes. An early outline, dated supervisor comments and a later chapter that addresses those comments form an interpretable sequence. Research logs, a reference-manager export, analysis outputs and the exact submission file may add independent anchors. Each source still retains its own limitations.

Look for explanations that could challenge the initial interpretation. A large paste event might reflect moving a chapter from another authorised editor. Missing document properties may result from a routine privacy clean-up or conversion. A new creation date may record download to a replacement laptop. These alternatives require evidence; they should neither be assumed nor ignored.

Cloud activity needs its own provenance record. The cloud-version preservation workflow separates service display, export, checksum and recovery test. The hearing-record review can then connect accurately stated technical findings to what was discussed. A submission-check foundation supports file review but is not a forensic examination.

Write an observation report that can be repeated

Identify the object with filename, size and checksum. State where it came from, who collected it, when, and whether it is an original or copy. Name the operating system, extraction tool and version. For every relevant field, preserve the raw value, technical layer, interpretation and uncertainty. Record extraction errors rather than silently omitting them.

A careful sentence would say: “The DOCX object with the recorded SHA-256 digest contains the value … in its modified property. That observation is consistent with a save event recorded by compatible software, but does not alone identify the operator or exclude later copying.” The boundary is part of the finding.

Avoid saying that timestamps “prove three months of work”. A series of saves does not show continuous labour or authorship of every passage. Equally, absence of rich metadata does not prove manipulation. Some workflows routinely strip information. The report should remain usable whichever overall conclusion the decision-maker reaches.

Seven controls before metadata enters a case file

  1. Identify the examined bytes with a checksum.
  2. Record provenance from receipt to analysis.
  3. Separate preserved source and working copy.
  4. State clock, time zone and any known offset.
  5. Verify field meaning for the relevant format and software.
  6. Document plausible alternative technical explanations.
  7. Link the finding to contemporaneous content evidence.

The examination-procedures hub places metadata beside other evidence types. Responsible analysis preserves observable facts, makes the extraction repeatable and avoids turning editable technical fields into a verdict on authorship.

Official technical references

  1. Library of Congress: DOCX format description – institutional description of the OOXML package and document properties.
  2. NIST: Secure Hash Standard – official specification covering SHA-256.
  3. UK Forensic Science Regulator: Codes of Practice – official principles concerning validation, records and reporting limitations.

Sources reviewed 4 September 2026. Consult the current documentation for the specific application and platform used.