How buyers verify documents

When you're considering equipment on Haubot, the documents on the listing are part of the offer. This guide is the practical version of how to make sure those documents are exactly what they claim to be — both at the moment you read the listing, and later if you need to refer back.

Step 1 — Read the trust panel

If a listing has documents and the seller has chosen to disclose them, you'll see a "Verified document record" box near the documents section. The box tells you:

• The date the document set was locked ("snapshot taken on …").
• How many files are included in that locked record.
• A short SHA-256 hash. Click "Copy full hash" to grab the full 64-character value.

This hash is the cryptographic fingerprint of the entire document set on that date. We'll use it in step 4.

Step 2 — Open the file you care about

Click any file in the documents block. Three things can happen:

• Public file: it downloads. Done.
• Sign-in required: you'll see "Sign in to download". Do that, then it downloads.
• Approval required: you'll see "Request access". Click it, write a short message describing who you are and why you want this document, submit. The seller reviews and you get notified when they approve. After approval the same button becomes "Download".

For each file, you'll also see a small Details button. It opens a panel with:

• The file's title and description.
• The original filename, type and size.
• Upload date.
• The SHA-256 content hash.

Note the per-file hash if you plan to verify later.

Step 3 — Download the package (when offered)

Some listings offer a downloadable package — a single ZIP with the manifest, a README, and the files you have access to. Use this when you want a portable record you can store in your own files, away from the platform.

Click "Download package" in the trust panel. You'll get a ZIP named something like vault-snapshot-42-1179c57d.zip. Inside:

• manifest.json (full export) or filtered_manifest.json (buyer-filtered export) — the document this proves.
• README.txt — verification instructions in plain English.
• documents/ — the actual files.

Open README.txt. It tells you exactly what hashes should match what.

Step 4 — Verify the package (optional, recommended)

You have two independent ways to confirm the ZIP is genuine.

The easy way: in-browser verifier

Open /verify/unitvault-disclosure and drop the ZIP onto the page. The verifier reads the file locally in your browser, recomputes the SHA-256 of combined_manifest.json, checks it against the signed hash inside the ZIP, and verifies the Ed25519 platform signature against Haubot's published key registry at /.well-known/disclosure-keys.json. Nothing is uploaded — the file never leaves your browser tab.

A green "Verified: Signed by Haubot" result means three things at once: the bytes are intact, the signature is valid, and the signing key is currently registered as an official Haubot key.

The thorough way: command-line hashes

You don't need any special software. Most operating systems ship with a SHA-256 tool.

macOS / Linux terminal

shasum -a 256 manifest.json
shasum -a 256 documents/inspection-report.pdf

Windows PowerShell

Get-FileHash -Algorithm SHA256 manifest.json
Get-FileHash -Algorithm SHA256 documents\inspection-report.pdf

Compare each output against the corresponding value:

1. The hash of manifest.json (or filtered_manifest.json) should equal the hash printed in README.txt and on the listing's trust panel.
2. The hash of each file in documents/ should match its content_hash value inside the manifest.

If everything matches, you have cryptographic proof that the bytes you have are exactly what was sealed at snapshot time.

If anything doesn't match — stop and contact Haubot support. A mismatch means the package was altered after export, or you're verifying against the wrong reference.

Step 5 — Keep the package

The platform retains snapshots indefinitely under our retention policy, but you don't have to take our word for it. Keep your downloaded ZIP. If you ever need to dispute what was disclosed, the package on your machine, the hash on the listing page (also signed into our audit log), and the canonical manifest format all line up.

What to do if a document is later edited or removed

That's allowed — sellers can edit metadata or replace files in their vault. But:

• Existing snapshots are immutable. They keep the frozen copy. If you took a snapshot package, your bytes still match.
• The live listing may show a newer version. The Compare feature on the seller dashboard can show added/changed/removed files; on the buyer side, you see whatever the current vault contains.
• Replaced files create a new entry with a new fileid and a new contenthash. The previous version stays inside the snapshot it was part of.

In short: anything you saw at snapshot time is still verifiable, even if the live listing has moved on.

Common questions

"Why doesn't the buyer-filtered package's hash match the listing's snapshot hash?" They reference different documents. The original snapshot manifest covers every file in the vault (including files you weren't allowed to see); the filtered manifest covers only the files you received. The README inside your package clarifies which hash matches what, and includes a based_on_snapshot_hash field cross-referencing the original.

"Can I trust the trust panel itself?" The trust panel shows what our database says. If you want a second opinion, the audit log is the canonical record on our side, the hashes are math you can re-run, and the Ed25519 platform signature inside combined_manifest.sig.json is independent crypto you can verify against our public key registry at /.well-known/disclosure-keys.json. Three layers, each verifiable on its own. The in-browser verifier at /verify/unitvault-disclosure checks all three at once.

"What if the seller deletes the listing?" Snapshots and audit logs are retained; the listing page may go away but the proof artefacts don't. Our support team can help you locate them.