Why we freeze the document at send

Here is a small disaster that happens in document tools every week. An agreement goes out for signature on Tuesday. On Wednesday somebody notices a typo in clause 4 and fixes it, because fixing a typo is obviously fine. On Thursday the other side signs. Now there is a signed agreement, and nobody in the building can say with certainty which wording of clause 4 the signature landed on.

Usually the answer turns out to be benign. Occasionally it is not, and the thing that was edited was a number. Either way the problem is the same: the document was treated as one object with a history, when from the moment it was sent it was two objects with separate futures.

Sending takes a snapshot

So XDocs makes the split explicit. Sending an envelope freezes a copy of the document body as it stood at that instant, and that copy is what recipients see, what fields are bound to, and what is hashed into the completion digest. The document in your editor carries on being editable, because work carries on. The two simply have nothing further to do with each other.

Which means the typo fix on Wednesday is harmless, and also ineffective: it lands in the draft, not in the thing being signed. That is the correct trade. An edit that could reach into a live envelope is a feature with no safe version of itself — it either changes an agreement under somebody who already read it, or it silently does nothing while appearing to work.

What the freeze makes possible

• A digest that means something. The certificate of completion carries two SHA-256 digests, one over the document and one over the completed record. A digest over a mutable body would be a number that stops matching for innocent reasons, which is worse than no number at all.
• An honest audit trail. "Viewed at 14:02" is only evidence if what was on the screen at 14:02 can still be produced.
• Resending without ambiguity. Correcting a real mistake means voiding and sending again, which leaves a visible record of two envelopes rather than an invisible edit inside one.
• Version history that is not load-bearing. The draft's snapshots are for authors; the sent copy is evidence. Keeping them separate means neither job compromises the other.

The gap is a thing you can ask about

Splitting one document into two creates a new question — *how far apart have they drifted?* — and the honest way to handle a new question is to answer it rather than to hide it.

So the assistant treats the gap as a first-class fact. Ask it about an agreement that is out for signature and it reports on the sent copy, and says so. It will not describe a live envelope as though the editor's current wording were the text under signature, which is the single most plausible way for a confident answer to be wrong. Where the two have diverged it can tell you what changed between them, in prose rather than as a patch, and open either one: a named version, or the exact copy that went out.

The same thinking runs through the sharing half of the product. A tracked link serves a document that can keep changing, which is usually the point — a deck is replaced weekly and every link already sent keeps working. But it means readers can have seen different texts under one URL, so the scheduled watcher notices when a live link's document has changed under readers who already saw the old version, and says so while telling them is still easy.

What it looks like day to day

1. 1

   Before sending

   The draft is the only object, and everything is editable: wording, recipients, which fields belong to whom. This is the cheap moment to change your mind, and the product tries to make it obvious that you are still in it.

2. 2

   At send

   The body is snapshotted and the recipients are bound to that snapshot. Routing order, access codes, expiry and reminders are set here, because they are properties of the envelope rather than of the document.

3. 3

   While it is out

   Edit the draft freely; nothing you type reaches the signers. Reminders, reassignment and voiding all act on the envelope. Reading analytics and signing status report on the frozen copy, which is what the counterparty actually has.

4. 4

   On completion

   One PDF is produced — the signed text, every signature, and a certificate carrying the audit trail, the consent records and both digests — then archived and emailed to every party.

The general version

Most of the integrity work in this product is this same move. Find the place where one object is quietly serving two purposes, split it, and then build the tooling that keeps the two reconciled — rather than leaving one object that is almost right for both jobs and hoping nobody edits it at the wrong moment.