Accepting is not signing

Most software that moves a contract around treats agreement as one event. Somebody presses a button, something happens, and afterwards the file says signed. It is tidy, and it is wrong about the way people actually come to terms.

There are two acts, and they happen in that order.

The first act: these are the words

Accepting is agreeing that the sentence in front of you is the sentence. Someone proposed a change to the payment terms, you read it, and you agreed to it — so that phrasing is now the phrasing, and the argument about it is over.

That is a real event and it deserves its own name. It is the one that takes the time. A contract spends most of its life here: one side proposes words, the other reads them, and the two of them converge on a paragraph. Nothing has been signed during any of it, and pretending otherwise makes the whole exchange feel heavier than it is.

The second act: your name

Signing is putting your name to a specific set of words. Not to a document in general, and not to the idea of the deal. To those words, in that order, as they stood at the moment your name went on.

That is a separate decision, and it is one a person makes on purpose. It is not a consequence of having agreed to the last redline, and it is not something that happens because a workflow reached its final step.

Why we keep them apart on purpose

Because a version does not change. Once a set of words exists it is fixed; editing it makes a new version rather than quietly rewriting the old one. A signature binds to that version.

Collapse the two acts into one and you lose the thing that makes the second one worth anything. If agreeing were signing, then every accepted redline would put a name on a moving target, and the words under that name could keep moving afterwards. The reason a signature means something is that the words it sits on cannot move.

Keeping them apart also matches how the conversation actually goes. "Yes, that clause is fine" is not "yes, I am bound." People say the first one all day while they are working out whether they want to say the second one. Software that treats the first as the second is asking everyone to be more careful than they need to be about every sentence, which is a good way to make a two-day negotiation take two weeks.

What the paper says

The paper says which of the two happened, and who did it. Not a status colour, not a progress bar — the record on the document itself, in the order it happened.

That is the part worth insisting on. The interesting question about a contract is rarely "is this done." It is "who agreed to what, and when, and is anyone's name on it yet." A document that can answer that without anybody opening an inbox is doing the job.

What never does either of them for you

Lex writes. It does not send and it does not sign. There is no setting that grants it either act, because those two acts are the entire reason anybody trusts the page.

The same rule holds for every automatic thing on the site. Software can prepare anything — draft a clause, propose a replacement, lay out what changed — and none of it moves a word toward another person or puts a name on a page. A person presses, every time.

What this post is not

It is not advice about whether accepting binds you. That depends on your deal, your words, and the law you have chosen to read them under, and it is not a question a product page gets to answer. We make paper, not legal advice.

What we can tell you is what this product does with the two acts: it keeps them separate, it binds signatures to exact words, and it writes down which one happened. The e-signature disclosure, the signer terms and the privacy page go live before launch, and they will say the rest of it properly.