Checking a Haven record.
Someone has handed you a Word document produced by Haven — a record of correspondence about a dispute, or an Estate Record of the accounts found in someone’s mailbox — and alongside it a file ending .manifest.json. This page checks that the document has not been altered since it was made, right here in your browser, and explains what that check does and does not establish.
01What you were given.
A Haven record is not a single file. Haven saves it as a folder — the document, its manifest, any attachments, and a short note pointing to this page — and the things in it need to stay together, because the check compares them against each other.
- something.docx The record itself. Opens in Word, Pages, Google Docs or LibreOffice. It contains a statement of what was searched, a dated chronology, the messages themselves as numbered exhibits, and a section at the end describing how it was produced. An Estate Record also carries a register: one row per bank, insurer, utility, adviser or agency found in the mail.
- something.manifest.json A small text file listing a fingerprint for every exhibit and every attached file, plus two cryptographic signatures. This is what makes the record checkable. It is meant to travel with the document.
-
attachments/
Present only if files attached to the emails were included. Each file is listed in the document with its own fingerprint. (Records made before September 2026 name this folder
something-attachments/and keep it beside the document.)
If you were sent only the .docx
You can still read it, but you cannot check it. Ask whoever sent it for the whole folder, or at least the .manifest.json saved beside it — and the attachments folder, if the document's index refers to one.
For executors and estate attorneys An Estate Record lists what one person’s mailbox shows about their accounts, policies, obligations and contacts. Three things about it are worth knowing before you rely on it.
Account, policy and member numbers are copied exactly as they appeared in the mail — usually partial, such as “account ending in 4471” — and have not been confirmed with the institution. Nothing in the record says an account is open, a balance exists, or a policy is in force.
The links in it open the original messages in the provider’s own interface, and only for someone signed in to that mailbox. The exhibit number and the quoted text are the reference.
Where an institution wrote many times, the record reproduces the first and last messages and a few between. The register’s dates and counts include every message it found.
02What a check proves.
This matters more than the mechanics, so it comes first. A Haven record is self-signed. The signing key is generated on the computer that produced the document and belongs to the person who ran Haven — not to Haven the company. There is no central authority attesting to anything here.
A successful check tells you
- The document, the exhibits listed inside it, and the attached files were all signed together as one set.
- None of them has been altered since that moment — not a figure in a quoted email, not a date, not an attached invoice.
- Two records showing the same key fingerprint were produced by the same installation of Haven.
It does not tell you
- That Haven vouches for the contents. It does not. The signature is the sender's, in the same way a signature on a letter is.
- That the underlying emails are genuine. Haven read them from the mail provider; it did not witness them being sent.
- That the record is complete. It shows what was searched — deleted mail, paper statements and other addresses are outside it. Read the “Known gaps” section on its first page.
- That any account listed is open, any balance exists, or any policy remains in force. An Estate Record reports what the mail shows; only the institution can confirm those.
Put plainly: verification is evidence of integrity, not of authorship or truth. It rules out the document having been quietly edited after the fact, by the sender or anyone else. It cannot rule out someone having assembled a misleading record in the first place.
If the contents are disputed A verified record is a good starting point, not an endpoint. Where what a message said actually matters, the original mailbox is the authority — obtain it from the account holder or the mail provider directly. The document lists a provider reference for every exhibit precisely so it can be traced back.
03Running the check.
In this browser
Drop the record’s folder anywhere on this page, or choose it below; the check runs as soon as both the document and its manifest are in. This page reads the files on your computer and they never leave it: the page is not permitted to make network connections at all, which you can confirm on the Network tab of your browser’s developer tools.
Check against a key you obtained separately (optional)
Without one, the check uses the key inside the manifest, which shows the record is intact but not who produced it. If the sender gave you their key another way, paste it here (base64 or hex) or choose the file.
With the script
Haven also publishes a small script that does the whole thing, for anyone who would rather not trust a web page. It reads the two files, compares them, and prints a plain-language result. It makes no network connections and sends nothing anywhere — you can read it first; it is about two hundred lines.
You need Python 3, which macOS and most Linux systems already have; on Windows install it from python.org. Put the script in the same folder as the document, then run:
A record that checks out prints:
The signature checks need one of two Python libraries — pip install pynacl is the usual way. Without it the first three checks still run and are still worth having: a document whose fingerprint does not match its manifest has been modified regardless of any signature.
04If a check fails.
A failure is not automatically evidence of bad faith. In order of likelihood:
| What it says | Usually means |
|---|---|
| document does NOT match the manifest | The file was opened and re-saved. Word rewrites a document on save, which changes it. Ask for the original as it was exported. |
| attachment missing from the folder | The attachments folder was not sent, or files were moved out of it. |
| attachment does NOT match its fingerprint | A file in the folder is not the one that was gathered. Worth asking about. |
| signature does NOT verify | The manifest itself has been edited. This one is hard to do by accident. |
| this browser cannot check signatures | An older browser. The fingerprint checks still ran; use the script, or a current Chrome, Edge, Firefox or Safari, for the signatures. |
The first is by far the most common and is almost always innocent — simply opening the document in Word and saving is enough to cause it. If you need a checkable copy, ask for the file to be sent again untouched.
05How it works.
For anyone who wants to check the reasoning rather than trust the script.
There are two Ed25519 signatures, because one alone would not be enough. The first covers a list of fingerprints — one per exhibit, one per attached file, with the counts included so that quietly dropping an entry changes the result. That signature is printed into the document, which is why it cannot also cover the document: it has to exist before the document does.
So a second signature covers the finished document's fingerprint, and is stored only in the manifest. Without it, the recorded fingerprint would be an unsigned number that anyone holding both files could simply rewrite to match an edited document. Together the two mean: these exhibits and files were assembled as a set, and this is the document that came out of them.
Fields inside the signed data are length-prefixed rather than joined with a separator, so that text inside a quoted email can never shift where one field ends and the next begins. The public key needed to check both signatures is inside the manifest, since the key is generated per-installation and there is nowhere central to look it up. That is what makes the record self-signed, as described in section 02.
The script is the reference implementation and is deliberately short enough to read end to end. The check on this page is the same procedure written in JavaScript, using your browser’s own SHA-256 and Ed25519 implementations; view the page source to read it.