Data Room Diligence · M&A

Proving what was in the data room, and when

For deal counsel, M&A associates, and R&W insurance underwriters who need to establish, after the fact, exactly which documents a buyer or insurer had access to at a specific point in a transaction.

🔒 All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data — use synthetic or anonymised inputs only.
Scope. This guide covers two tools: a manifest builder and a manifest verifier. Neither tool hosts documents, controls data room access, or replaces a virtual data room platform. Both hash files locally and never transmit file contents.

Disclosure Manifest Builder

Hash a folder of files, build a signed Merkle-rooted manifest, diff it against a prior version, and anchor the root.

Open tool →

Disclosure Manifest Verifier

Verify a manifest's signature, prove one file's inclusion, or run a full coverage report against a folder.

Open tool →

The problem this solves

A data room's own activity log tells you who opened what, inside that platform. It does not give a counterparty a way to independently confirm, months or years later, that a specific document was actually present at a given point in time, without trusting the platform operator's word for it. In a deal that closes and later triggers an R&W insurance claim, or a dispute over whether a schedule was disclosed, the question is rarely "was this file uploaded" but "can a third party verify this file was disclosed, using only public math, without asking the platform to vouch for it."

A Merkle-rooted manifest answers that question directly. Every file in the room is hashed. The hashes are combined into a single root value. That root, and only that root, needs to be anchored somewhere independent and timestamped. Anyone holding the manifest and a copy of one file can then prove, on their own, that the file was part of the disclosed set, without needing access to any other file in the room.

How the two tools fit together

  1. Build a manifest at each disclosure milestone (initial data room open, pre-signing bring-down, post-signing update). The builder hashes every file locally, produces a Merkle root, and signs the manifest with a one-time key generated in your browser.
  2. Anchor the root at an independent timestamp service by following the manifest's anchor link. This step is optional but is what converts a self-reported manifest into third-party-verifiable evidence of a point in time.
  3. Diff versions by pasting the prior manifest into the builder before hashing the next round. The output shows exactly which paths were added, removed, or changed, and the new manifest carries a digest of the one before it, forming a version chain.
  4. Verify later with the verifier tool. A counterparty, insurer, or arbitrator holding the manifest can prove a single file's inclusion, or run a full coverage report across an entire folder, without access to the original data room.

Use in R&W insurance underwriting

Representations-and-warranties insurers price a policy in part on what the buyer's diligence team actually reviewed. A signed manifest gives the underwriter a fixed, hash-anchored record of the disclosure set at binding, separate from the deal parties' own account of what was shown. If a claim later turns on whether a specific schedule was disclosed before signing, the manifest and its anchor let any party recompute the answer independently.

What "absence" does and does not prove

The verifier's coverage report can show that a file is missing from a manifest. That only means the file is absent from the specific manifest version being checked. It is not proof a document was withheld in some larger sense: confirm the manifest version and Merkle root through an independent channel before treating an absence as evidence in a dispute.

Scope note. Two related capabilities are intentionally out of scope for this release. A per-disclosure activity receipt log (recording which recipient saw which subset of a manifest, hash-chained) is scoped as a follow-on and requires an explicit product decision before it is built. Agent-facing MCP tools that build or verify manifests from a caller-supplied digest list, without a file ever reaching the worker, live in a separate deploy (the MCP worker repository) and ship in a later change once that repository is updated in step.