Sign the version that was agreed

Exporting a negotiated document to a signing tool breaks the one link that matters: the signature is attached to a file, not to the negotiation that produced it. In Paqt, signing is the final state of the agreement — same room, same instrument, same record.

What breaks when signing lives somewhere else

A standalone signing tool receives a file with no memory. Everything that gave the document meaning stays behind in the thread it came from.

  • Negotiate here, sign there: Someone chooses which file to upload, and that choice is the agreement
  • Negotiate here, sign there: The signed PDF has no link to the negotiation that produced it
  • Negotiate here, sign there: Approvals live in email and are not bound to the signed version
  • Negotiate here, sign there: A late change means re-exporting and starting the signature over
  • Negotiate here, sign there: Two systems hold two partial records of the same transaction
  • Negotiate here, sign there: Proving what was agreed means reconciling a PDF against a mailbox
  • Signing inside the agreement: The version is the one the parties resolved to, not the one someone uploaded
  • Signing inside the agreement: The signature attaches to a versioned instrument with its full history
  • Signing inside the agreement: Approvals are bound to the exact version and approver identity
  • Signing inside the agreement: A late change creates a new version and an explicit re-approval
  • Signing inside the agreement: One record covers conversation, negotiation, approval and execution
  • Signing inside the agreement: Proof is an export, because the evidence was never in two places

The parts that have to work every time

  • Version locking — Sending for signature locks the version. Any change after that produces a new version and invalidates signatures collected against the old one, rather than silently moving the goalposts.
  • Multiple signers and entities — Several signatories across several entities sign the same version, with identity captured per signer and signing order enforced where the agreement requires it.
  • Approvals as preconditions — Internal sign-offs are conditions on execution, so an agreement cannot reach a counterparty's signature page before the approvals it required were given.
  • Signature requests that follow up — Reminder cadence is handled, and a counterparty's questions land in the room rather than in a reply to a no-reply address.
  • Signature blocks from the document — Signatory roles come from the agreement's own parties, so the signing order reflects the instrument instead of someone's drag-and-drop.
  • Sealed record on completion — When the last signature lands, the executed version is sealed, obligations are extracted and the whole record becomes exportable as one package.

Evidence that survives a hostile reading

The test of a signature is not the pen graphic. It is whether, years later, you can show what was signed, by whom, after which approvals, and that none of it changed since.

  • Tamper-evident history — The agreement's version history is timestamped and tamper-evident, so the signed text is demonstrably the text that was signed.
  • Identity captured per signer — Who signed, against which version and when — recorded per signatory rather than as a single event on a file.
  • The negotiation attached — Every proposal, counter and resolution that produced the signed language is part of the same record, in order.
  • Scoped access, encrypted at rest — Visibility is per party inside the room, data is encrypted in transit and at rest, and external agents act under scoped credentials.

When the assistant sends for signature

Signature is the step where autonomy matters most, so it carries the strictest controls. An agent can run the process without being able to change what it means.

  • What an agent cannot do: Sign on a human's behalf
  • What an agent cannot do: Alter a version that is locked for signature
  • What an agent cannot do: Skip an approval that execution depends on
  • What an agent cannot do: Proceed past a clause configured as mandatory review
  • What it does do: Lock the agreed version and request signature
  • What it does do: Collect approvals in the order the agreement requires
  • What it does do: Chase the counterparty on a cadence you set
  • What it does do: Answer document questions from the instrument itself
  • What gets recorded: Every agent action attributed in the timeline
  • What gets recorded: The version each signature was collected against
  • What gets recorded: Each approval with its approver and timestamp
  • What gets recorded: The sealed executed agreement and its obligations

What buyers ask about signing

  • Does the counterparty need an account? They participate by invitation into the room and sign there. They are not asked to adopt a platform to countersign an agreement, and they keep the executed document and its record.
  • What happens if a term changes after signatures start? The change creates a new version, and signatures collected against the previous one no longer apply to it. That is deliberate: the alternative — a document that moves underneath a signature — is the failure this design exists to prevent.
  • Can we require internal approval before anything is sent? Yes. Approvals are preconditions on execution rather than reminders, and they bind to the specific version, so an approval of version 5 does not silently authorise version 7.
  • What do we get for an audit or a dispute? One export containing the conversation, every version with diffs, each negotiation turn, every approval with its identity, and the signature capture per signatory — assembled continuously rather than reconstructed on request.