Sealed contract storage: know what was in force, prove it

1. The problem: version truth lives in filenames

Ask a deal team which version of a master services agreement governed Q3 last year. The answer involves a shared drive, files named MSA-final-v2-REALLY-final.pdf, an email thread with a redline nobody saved, and a side letter in someone's inbox. Each artifact is individually plausible; together they prove nothing about sequence or supremacy.

The standard tooling narrows but does not close the gap:

• E-signature envelopes. Excellent at proving signing ceremony — who clicked, when. Weak at everything after: amendments live outside the envelope, and the envelope is a point in time, not a history.
• Shared drives and CLM folders. Access control is not integrity. Anyone with write access can replace a file; modification dates prove nothing; “version history” features are operator-dependent and editable by admins.
• Email as archive. The thread is the worst database: incomplete, deletable, and organized by nobody. Opposing counsel knows this.

When versions are disputed, the costs are lawyers reconstructing timelines, deals delayed while both sides re-verify, and settlements discounted for evidentiary uncertainty. The underlying need is simple: a record where each version's content, order, and custody are checkable facts.

2. What good looks like on your infrastructure

1. Every version sealed. Executed text, amendments, and side letters each get an integrity seal plus a signed receipt at the moment they enter the vault. Nothing enters unsealed.
2. History as a chain. Each seal commits to its predecessor, with supersession recorded explicitly. The question “what replaced what, when” has one answer, derivable from the artifacts.
3. Custody with review gates. Touches — store, share, review, export — are logged against the item. NDA-controlled review lets counterparties inspect without taking uncontrolled copies.
4. Date queries answerable. “What was in force on March 14?” replays the chain to that date. No archaeology, no inference.

The vault runs on your infrastructure. Counterparties verify their own sealed copies locally — no shared platform, no vendor in the middle of your agreements.

3. How sealed storage works — seal, amend, replay

Seal

Private Contract Vault ingests the executed document, computes its integrity hash, and writes a sealed record: content hash, parties, effective date, and a receipt signed under your keys. The original stays in your store; the seal makes later alteration detectable. Unsealing for review happens under NDA through the vault interface, with access logged — reviewers see the document without taking an uncontrolled copy.

Amend

Amendments, renewals, and side letters enter as new sealed versions chained to what they modify, with the relationship — amendment, supersession, extension — recorded in the receipt. The chain preserves the full negotiation archaeology: draft, executed, amended, renewed. Nothing is overwritten; history only appends.

Replay

To answer “what was in force when,” walk the chain to the date and read the active version. For cross-party assurance, exchange sealed copies: each side verifies signatures and the hash chain independently, arriving at the same history without sharing systems. Anchor key receipts with Hash Anchor when you need the timeline itself timestamped apart from the vault.

4. The components

One vault for agreements, one locker for everything else, one anchor for time.

Start with Contract Vault for the agreement portfolio. Extend to Evidence Locker when matters need the same custody for exhibits and correspondence.

5. How to verify it — chains, dates, and custody

• Chain walk. From any version, follow seals backward to inception and forward to present. Every link verifies; a broken link localizes the tamper exactly.
• Date replay. Pick three historical dates and derive the in-force version from the chain alone. Then confirm against your matter records — they should agree without interpretation.
• Counterparty cross-check. Exchange sealed copies with the other side and verify independently. Matching histories from separate systems is the strongest possible agreement proof.
• Custody review. List every touch on a high-stakes agreement — who stored, shared, reviewed, exported — and confirm each maps to an authorized review event.
• Amendment completeness. Confirm every supersession names its predecessor and every predecessor names its successor. Orphan versions are findings.

6. Buying checklist

• ☐ Every version sealed at ingest with content hash and signed receipt
• ☐ History is an explicit chain — amendments and supersessions recorded as relationships
• ☐ “In force on date X” answerable by replay, not by folder inspection
• ☐ NDA-gated review with logged access — no uncontrolled copies for reviewers
• ☐ Counterparties verify independently with no shared platform
• ☐ Custody log covers store, share, review, and export per item
• ☐ Vault, registry, and verification run on your infrastructure
• ☐ Studio experiment available without signup — isolated demo host, try before installing
• ☐ No e-signature replacement or legal-advice claims — custody and proof, not counsel

7. Common anti-patterns to avoid

• Filename versioning. If the version lives in the file name, it lives in whoever renamed it last. Versions must be structural, not nominal.
• Signature as the whole story. Signing proves ceremony. Amendments after signing need their own seals — an envelope from 2023 says nothing about the 2024 side letter.
• Review by attachment. Every emailed copy is an uncontrolled fork that will resurface in discovery. Route reviewers through the vault.
• Admin-editable history. If an administrator can rewrite version metadata, the chain is decorative. Seals must be tamper-evident against insiders too.
• One system for proof and storage. Keep time-anchors separate from the vault so no single compromise moves both the file and its timeline.

Frequently asked questions