← Framework

Stage 2 · Capture

Time Evidence

How to preserve evidence of when a file, record, claim, work, dataset, message, decision, or digital event existed or changed.

creatorsbusinessesresearchersadvisersorganisations

Time Evidence

Time evidence is evidence of when something existed, happened, changed, was captured, was received, was published, or was preserved.

It is one of the most important parts of digital evidence, but also one of the most commonly misunderstood.

A timestamp can be useful. It can help show that a file or record existed at a certain point. But a timestamp alone rarely proves the full claim people want to make from it.

The purpose of this guide is to help users preserve timing evidence clearly, without overstating what time evidence can prove.

Quick Read

  • Time evidence helps show when a file, record, claim, decision, event, dataset, or output existed or changed.
  • A timestamp is stronger when it is connected to the correct record, source material, sequence, custody position, and verification route.
  • Time evidence does not automatically prove ownership, authorship, originality, permission, legality, accuracy, or truth.

What this means

Time evidence is the timing layer of an evidence record.

It may come from file metadata, system logs, emails, messages, platform records, publication records, version history, transaction records, audit logs, trusted timestamps, blockchain anchors, receipts, exports, signed records, or other captured timing signals.

The value of time evidence depends on the context.

A timestamp on a final file may show that the file existed at that time. It may not show who created it, whether it was original, whether it was copied, whether it was lawful, or whether the person making the claim had the right to make it.

Time evidence should therefore be treated as one part of the evidence position, not the whole proof.

Why it matters

Many people rely on timing evidence too late or too casually.

They assume a file creation date proves authorship. They assume an upload date proves priority. They assume an email date proves the attachment has not changed. They assume a platform timestamp will remain available. They assume metadata will survive file transfer. They assume a later screenshot can prove an earlier event.

Those assumptions are weak.

Time evidence matters because disputes often turn on timing: who had something first, when a decision was made, when material was published, when a record was received, when a version changed, when a dataset existed, or when an incident was known.

If the timing record is weak, the wider claim may become weak.

What strong time evidence should include

A stronger time evidence position usually includes:

  • The timed item — the file, record, message, decision, dataset, output, event, or claim being timed.
  • The time claim — what is being said about when the item existed or changed.
  • The timing source — where the timestamp or timing signal came from.
  • The source material — the original or underlying record connected to the timestamp.
  • The system context — the device, platform, application, account, service, or workflow that generated or recorded the time.
  • The time zone context — where relevant, the time zone or time standard used.
  • Sequence context — what happened before and after the timed event.
  • Custody context — how the record was preserved after the timing signal.
  • Verification context — how someone else could check the timing evidence later.
  • Claim boundaries — what the timestamp supports and what it does not support.

The stronger the claim, the more important these surrounding details become.

Common weak points

Time evidence is usually weak when:

  • the timestamp is platform-only
  • the original file is missing
  • metadata is relied on without preserving the file properly
  • the timestamp is separated from the source material
  • the time zone is unclear
  • the system clock may have been wrong
  • the record was copied, exported, downloaded, or converted without preserving timing context
  • the timestamp shows upload or publication but is treated as proof of creation
  • an email date is treated as proof that an attachment has not changed
  • the timing source cannot be independently checked
  • a later screenshot is used to prove an earlier event
  • the claim says more than the timestamp supports

A timestamp can be useful while still being incomplete.

How to apply this yourself

For each important record, create a clear time note.

Ask:

  • What exactly needs to be timed?
  • What time claim are we making?
  • What is the source of the timestamp or timing signal?
  • Is the original or source material preserved?
  • Does the timestamp relate to creation, receipt, capture, upload, publication, change, approval, or preservation?
  • What happened before and after this point?
  • Is the time zone or time standard clear?
  • Can the timing evidence be checked later?
  • Is the timing evidence independent of the person or system making the claim?
  • What does this timestamp not prove?

Then preserve the timed record, the timestamp source, and the surrounding context together.

Do not rely on a timestamp without explaining what kind of time it represents.

What this does not prove

Time evidence does not automatically prove:

  • ownership
  • copyright
  • authorship
  • originality
  • permission
  • legality
  • authenticity
  • accuracy
  • identity
  • complete sequence
  • absence of alteration
  • that the person making the claim created the record
  • that EviWrite has verified the timing

A timestamp may show that something existed at a point in time. It does not, by itself, prove every claim about that thing.

Framework-aligned claim boundary

A person or organisation may use this guide as part of EviWrite Framework alignment if they apply the guidance honestly and avoid implying EviWrite involvement.

Acceptable wording may include:

“We use the EviWrite Framework to preserve time evidence for important records.”

It must not be used to imply:

  • EviWrite has verified the timestamp
  • EviWrite has confirmed creation time
  • EviWrite has confirmed authorship
  • EviWrite has approved the claim
  • the record is EviWrite-backed
  • the record is EviWrite-certified
  • the record carries the controlled ⓔ mark

Framework-aligned means public guidance was followed.

EviWrite-backed means the record was created through EviWrite or an authorised evidencing channel.

Related checklist

Use the Time Evidence Checklist to check whether timing signals, source materials, time context, sequence context, and claim boundaries have been preserved.

This guide is public evidence-readiness guidance. It does not mean EviWrite has verified, certified, approved, anchored, or backed any record.

Return to Framework map