GitLaw How-To guides

Negotiate and redline a contract with the other side


GitLaw supports the complete negotiation lifecycle: draft, share, redline, counter-redline, and converge - with each side's context kept entirely separate. Track changes work exactly as they do in Microsoft Word, so you can exchange DOCX files with counterparties who do not use GitLaw without losing any markup.

Steps

  1. Prepare your draft Open or upload your contract. Before sending, you can ask the Agent to check it against your playbook, flag one-sided clauses, and tighten the language. See Review a document using Agent for a full walkthrough.

    If you want your edits recorded as redlines rather than direct changes, turn on Track Changes in the editor toolbar. All subsequent edits - including those generated by the Agent - will appear as track changes attributed to you.


  2. Share the draft with the counterparty Invite the other side by email from the document's share panel. Counterparties receive Viewer access by default, meaning they can read the document and create their own working copy but cannot edit your original. For a detailed explanation of roles, see File sharing permissions in personal and organisation accounts and Share a document or invite a counterparty.

    RoleCan do
    Viewer (counterparty default)Read, copy the document, submit a change request
    EditorEdit, accept/reject changes, reshare
    OwnerFull control, including deletion and participant management

  3. Counterparty redlines their copy The other side works in their own copy. Their Agent only has access to their own context and playbooks - your internal notes, negotiation tactics, and playbook details are never shared. Only the document and its markup pass between parties.

    When they are ready, they submit their edits back to you as a change request (similar to a pull request in version control). GitLaw computes the diff and presents their changes as track changes on your base document.


  4. Review the counterparty's redlines Open the incoming change request to see the other side's edits highlighted inline - insertions in colour, deletions as strikethrough.

    Ask the Agent to analyse the counterparty's changes:

    • "Summarise what the other side changed and flag any high-risk edits."
    • "Compare their edits against my playbook and suggest responses."
    • "Draft a reply email that accepts the liability cap and counters the indemnity clause."

    The Agent can suggest counter-redlines, which appear as additional track changes for you to review before accepting. See Accept or reject tracked changes for the mechanics of individual and bulk accept/reject.


  5. Set your negotiation posture (optional) Before asking the Agent to propose counter-redlines, you can tell it in chat how you want to negotiate - for example, take a collaborative approach or hold a firm line. This influences the tone and assertiveness of the Agent's suggestions without changing your underlying playbook. See Use playbooks and negotiation posture for details.


  6. Return your counter-redlines As the owner of the original document, you don't send a change request back - you make your edits directly in the document. Accept the changes you agree with, reject the ones you don't, and add your own changes; turn on Track Changes if you want them recorded as tracked changes, and leave comments where useful. The counterparty can then raise their next round of change requests against the updated document. Each round creates a new version with a full diff and audit trail.


  7. Converge and finalise Once both sides accept all outstanding track changes, ask the Agent to run a final check:

    • Cross-references and defined terms are consistent.
    • Signature blocks and exhibit attachments are complete.

    Export a clean DOCX (all changes accepted) or PDF for execution. The DOCX will open in Word with no residual redline markup.

Key points to remember

  • Word compatibility. GitLaw track changes round-trip through DOCX. Redlines you produce in GitLaw open correctly in Microsoft Word, and DOCX files with existing redlines import into GitLaw preserving all markup and author attribution.
  • Data isolation. Each party's Agent works only with that party's own context, playbooks, and history. The only information that crosses the boundary is the document itself and its track changes.
  • Human in control. All Agent-suggested redlines appear as track changes pending your explicit accept or reject - nothing is applied to the document automatically.
  • Audit trail. Every share action, role change, and negotiation round is logged with actor, timestamp, and scope.

Sign up to source, customize, and store contracts for free

Sign Up