Suppose your framer builds a beam pocket in the wrong location. You revised the plans four weeks ago. The framer says he never saw the revision. You say you sent it. Can you prove it?

If you sent it by email and the framer deleted the thread, your proof is "I have a sent-mail record." In court, that establishes that you sent a file. It doesn't establish that he opened it, identified the revision, or understood that it superseded the previous version he had on-site.

Most builders discover this gap after a warranty claim, a rework dispute, or a subpoena. At that point, the gap costs real money. The fix has to happen years before the dispute — which means it has to happen at delivery time, every time.

What "proof of delivery" actually requires

A defensible plan delivery record answers four questions:

  1. What was sent? — The specific file, version, and page list. Not "the plans," but "Clearwater 3+2, Rev 4, sheets A1.1 through S3.2, dated April 14, 2026."
  2. Who received it? — Identified by name, role, and method. Not "the framing crew," but "Marcus Webb, lead framer, delivered to his portal account."
  3. When? — Date and time, logged by a system outside the builder's control.
  4. Did they see it? — Opened, acknowledged, or at minimum delivered to a system they're on record accessing.

Most plan delivery processes answer the first question and maybe the second. Almost none answer the fourth.

A real scenario

A buyer closes on their home in November. In March, the master bath shower floor cracks. The buyer calls it a warranty issue. The tile trade partner says the floor wasn't sloped properly; the waterproofing spec was wrong. The builder says the spec was revised in September and the trade partner was notified. The trade partner says he never received the revision.

Now everyone's in mediation. The builder's attorney asks for the delivery record. The builder has an email thread with "plans attached." The trade partner's attorney points out the email was forwarded twice and the attachment version doesn't match the file hash of the revision in question.

Eighteen months later, the builder pays for the repair plus legal fees. Total cost: $34,000. The original spec revision cost $200 to produce.

Why email isn't enough

Email creates a record you control. A record you control can be questioned, manipulated, or simply dismissed as "not an official channel." It also doesn't stop a trade partner from claiming they missed it, didn't recognize it as a superseding document, or received it but couldn't open the file.

The more defensible model is delivery through a system where:

  • The trade partner logs in with their identity to receive plans — not just a download link
  • The delivery is logged by a neutral system at a timestamp that can't be backdated
  • The trade partner is required to acknowledge receipt of each delivery before the record closes
  • The document is sealed with a cryptographic hash — so if a dispute arises, you can prove the file the trade partner acknowledged is identical to the file in question
The goal is to make "I never saw it" an implausible claim, not an unprovable one. Every step in the delivery process should leave a record that costs something to dispute.

The cryptographic hash detail

A file hash (SHA-256 is the standard) is a fingerprint for a document. If a single character in the file changes, the hash changes. This means:

  • You can prove that the document a trade partner acknowledged is the exact file in your archive
  • You can prove that the file in your archive wasn't modified after the acknowledgment
  • Neither party can claim the document was swapped after the fact

This level of proof is what "forensic" means in the context of plan delivery. It's not about being paranoid about your trade partners. It's about building a paper trail that's strong enough to survive a dispute without relying on trust, memory, or the honesty of an adversarial party.

The operational side

A forensic delivery process doesn't have to be a burden on the trades. The work is on the builder's side — setting up the delivery, tagging which trades receive which pages, logging the acknowledgment. The trade partner's experience should be: open the portal, see the new plans, tap "I've reviewed this delivery." Thirty seconds.

The important design principle is that acknowledgment is required before the delivery record closes. A "delivered but not acknowledged" status is a signal that needs follow-up — not a completed delivery.

In Lotwright: Plan delivery is trade-tagged by page — the framer sees the structural pages, the electrician sees the MEP pages, the finisher sees the finish schedule. Each delivery is SHA-256 hashed and timestamped at delivery. The trade partner acknowledges from their portal. The builder's dashboard shows a daily health check: any deliveries pending acknowledgment for 48+ hours get flagged. Every delivery record is retained permanently with the job archive.

Before you need it

Builders who haven't been through a plan-delivery dispute tend to view forensic logging as overkill. Builders who have been through one tend to view it as the minimum viable protection.

The asymmetry is stark: implementing a proper delivery process costs almost nothing per job. A single warranty dispute where delivery is in question can cost tens of thousands in legal fees alone, before you get to any rework costs.

Plan delivery is a legal document. The delivery process should treat it like one.