The two acts
Accepting is agreeing to the words. It is what happens when the other side reads a proposed change and says yes to it. It moves the contract into an agreed state, and an agreed contract is a real and useful thing: everybody knows what the deal is. Signing is putting your name to a version. It is a separate act, made by a person, on a specific set of words, at a specific moment. A contract can be agreed and unsigned. That is a normal state and the product draws it as one, rather than as an error on the way to a green tick. Andagreed is not a one-way door: somebody opens a new question and the contract
goes back to negotiating. Signatures already given go held — the words have not
moved, so what those people signed still reads exactly as it did.
Why the difference is load-bearing
Because a signature has to bind to something that cannot move afterwards. They are two separate records in the model, not two values of one status field. An Acceptance is a party agreeing to a Version’s words. A Signature is that party’s name on the same hash of the same words — and it cannot exist without an Acceptance by the same party on the same hash, recorded no later. If the two were one state, either the signature would float free of the words, or an acceptance would be treated as a signature nobody meant to give. A paper can therefore sit fully accepted and wholly unsigned, and the model has a worked example that is exactly that: two versions, a proposal, a decision, an acceptance, and no signatures at all.What the paper says
The paper always says which of the two has happened, and who did it. Not “signed off”. Not a status pill that could mean either. The language in the product follows the same rule everywhere. Lex will say a change was accepted, or that a version was signed, and it will never round one into the other.The two records in the model
Acceptance, Signature, and the three signature states.
Read the long version
“Accepting is not signing” on the contracts.io blog.