OOFMODE · PUBLIC DOCUMENTATION

VERIFYING A VAULT EXPORT

If somebody has handed you an OOFmode Paper Trail Vault export and you want to check it yourself rather than trust the certificate, this page tells you how. You do not need an account, our cooperation, or any of our software.

What the export contains

Two files. A PDF — a chronological timeline plus an integrity certificate — and a JSON file containing, for every entry: its position in the chain (seq), the dates, and three hashes (content_hash, prev_hash, entry_hash). The JSON also carries a SHA-256 of each entry's stored ciphertext.

By default the JSON contains no readable content at all. That is intentional: it means the person checking the chain does not have to be a person who is allowed to read the records. The exporter can choose to include the text.

The formula

Every hash is plain SHA-256 over a byte string assembled exactly as below. Timestamps are rendered in UTC with microsecond precision — the format is pinned because a hash input that moved with a reader's timezone would not be a hash input.

ts_iso(t) = to_char(t AT TIME ZONE 'UTC', 'YYYY-MM-DD"T"HH24:MI:SS.US"Z"')

content_hash = sha256_hex(
    body_ciphertext_bytes           (base64-decoded; empty if erased)
  + 0x00
  + source_meta_ciphertext_bytes    (base64-decoded; empty if absent)
  + 0x00
  + utf8(type)
  + 0x00
  + utf8(ts_iso(occurred_at))
)

entry_hash = sha256_hex(utf8(
  user_id + "|" + seq + "|" + content_hash + "|" + prev_hash + "|" + ts_iso(created_at)
))

prev_hash = the previous entry's entry_hash, or 64 zeros for seq 1.

How to check it

Take the entries in ascending seq order and confirm four things:

1. Sequence continuity. seq starts at 1 and increases by exactly 1 with no gaps. A gap means an entry was removed.
2. Links. Each entry's prev_hash equals the previous entry's entry_hash. The first entry's prev_hash is 64 zeros.
3. Content. Recompute content_hash from the ciphertext bytes, the type and occurred_at. Skip this for entries marked erased — their content was destroyed on request, so it cannot be recomputed.
4. Position. Recompute entry_hash from the user id, the seq, the content hash, the prev hash and created_at. Note that the JSON uses a pseudonymous subject rather than the raw user id, so a full entry_hash recomputation requires the exporter to supply the user id separately — steps 1 to 3 are checkable without it.

Any SHA-256 implementation will do. If all four hold, the records are internally consistent: no entry's content, type or dates have changed, and none has been inserted or removed, since the server saved each one.

What this does and does not demonstrate

WHAT THIS COVERS. The entry content, the sender/subject metadata, the entry type and the event dates (occurred_at, created_at) are hash-linked and therefore tamper-evident: altering any of them breaks the chain at a specific, reportable position.

WHAT THIS DOES NOT COVER. Titles, tags, confirmation statuses, evidence links and PIP trackers are editable by the user at any time and are deliberately outside the hashes. Do not treat them as verified.

WHAT THIS PROVES. That the records listed here are internally consistent and unaltered since the date each was saved by the server. It does NOT prove that the events described in them actually happened, or that the descriptions are accurate — the content is what the user saved, and this cannot speak to its truthfulness. It is also not a statement about how any court, tribunal or employer would treat this document.

ERASED ENTRIES. An entry marked erased had its content permanently destroyed at the user's request. Its hashes are retained, so the chain around it still verifies; its content_hash can no longer be recomputed, which is the unavoidable price of real erasure.

The limit worth understanding

A hash chain proves internal consistency. It does not prove that the chain was built when it claims to have been built. Anybody with full write access to the underlying database — including us — could in principle rebuild an entire chain from scratch with different content and different dates.

What the chain genuinely changes is the cost and the visibility of tampering. Altering a single entry is not a small edit: it invalidates that entry's hash and every hash after it, so a convincing alteration requires recomputing the whole remainder of the chain. Any partial attempt is detected, and the verifier reports the exact position where it fails.

Closing the remaining gap needs an external anchor — publishing the chain head somewhere the vault owner does not control, so that a hash existed at a provable point in time. OOFmode does not currently do this, and nothing in an export implies otherwise.

Questions this page cannot answer

Whether a record like this carries any weight in a particular dispute, process or jurisdiction is a question for a qualified lawyer in that jurisdiction. This page describes a cryptographic property and nothing more.