Loading...

Audit log - how it is done?

Evidence for disputes & audits


Turn “trust me” into a verifiable trail: timestamps, immutable anchors, and exportable evidence.

When a file changes hands, the real problem is rarely the file itself. It’s the story around it: who produced what, when, and whether anything changed after approval. WrittenInStone helps you build a repeatable evidence trail you can export and reuse in reviews, audits, and disputes.

What “evidence” means in WrittenInStone

Evidence is not a long PDF full of claims. It’s a small set of verifiable facts:

  • What: the file’s fingerprint (hash).
  • When: a timestamp anchored in an immutable registry (blockchain).
  • How it changed (or didn’t): match / mismatch results over time.
  • Context: optional labels you control (project ID, export run ID, handoff note).

How the blockchain anchor fits in (without the hype)

Blockchains are good at one thing: providing a shared, hard-to-rewrite timeline. We use that property to anchor your proof records. Once a fingerprint is anchored with a timestamp, it becomes difficult to backdate or quietly rewrite the record later.

Our evidence chain: what gets written and why

Think of each proof record as a small “event” in an evidence chain. For each event, we write a compact bundle of data:

  • Fingerprint (hash) of the file (content is not required).
  • Timestamp (plus blockchain transaction reference).
  • Record ID you can cite later.
  • Optional metadata you choose (labels, project IDs, workflow references).

Later, these events can be discovered by record ID (or through your dashboard) and used to generate exports: logs, timelines, and verification summaries.

A better (cleaner) way than “hash everything again”

For audits and disputes, you often need a single artifact that summarizes many events. Instead of rehashing everything repeatedly, we can produce an evidence manifest:

  • a structured list of evidence events (proof record IDs, timestamps, results),
  • one or more summary hashes (hashes of the manifest, or a Merkle-style root),
  • references to the immutable anchors (blockchain tx / block numbers).

This gives you a compact “one-page” proof: the manifest can be shared, archived, or attached to a report. If anyone questions it later, they can recompute the manifest hash and confirm it matches the anchored reference.

What you can export

  • Evidence log: a chronological list of stamps and verification events.
  • Verification report: a summary for handoff, approvals, or disputes (match/mismatch, timestamps, IDs).
  • Audit-friendly bundle: a manifest + summary hash + anchor references for long-term storage.

When it helps most

  • Vendor / client handoff: prove “this is what we delivered” and detect silent edits.
  • Internal approvals: lock the approved export and keep a clean timeline.
  • Regulated reporting: show that a report or dataset wasn’t altered after generation.
  • Disputes: reduce arguments to a simple check: match or mismatch.

Privacy and metadata (practical guidance)

Evidence works best when it’s shareable. Keep the public part minimal: a fingerprint, a timestamp, and a verification link/QR. If you add metadata, treat it like a public label—avoid secrets and personal data.

What this does not replace

This is technical evidence of integrity and time. It doesn’t replace legal advice, formal signatures, or notarization. But it does remove a huge class of ambiguity: whether a file changed after a specific point in time.

Verify a file Create a proof record