The Negotiation Playbook

In Lesson 1, you installed both plugin layers and ran your first /review-contract against a vendor agreement. The output flagged clauses as GREEN, YELLOW, or RED -- but against "widely-accepted commercial standards." That review was useful but imprecise. It told you what a generic commercial lawyer would notice. It did not tell you what your organisation cares about.

Fatima Al-Rashidi at PayGulf Technologies runs the same plugin on the same types of vendor SaaS agreements. Her output looks nothing like yours. When her agent flags a limitation of liability clause, it does not say "this cap appears low." It says "3-month cap is AED 375,000 against PayGulf's minimum of AED 500,000 -- 25% below floor. DFSA-regulated entity requires conservative posture. Recommend 12-month mutual cap with standard IP indemnity carve-out." When it reviews a data protection clause, it does not say "consider adding a DPA." It says "vendor processes merchant personal data without DPA -- required under DIFC DP Law 2020. Maximum penalty: USD 100,000. RED: escalate to GC."

The difference is one file: legal.local.md. Fatima's playbook encodes PayGulf's risk tolerance, regulatory obligations, and eight years of negotiation experience into a structured configuration. The plugin is infrastructure. Your playbook is the product.

Build Your Playbook

Copy the template to your working directory:

Copy the legal.local.md.template to legal.local.md in your working folder.
If using Cowork, ask Claude: "Copy the Legal Plugin's playbook template
to my working folder as legal.local.md"

Open legal.local.md and fill in the Organisation Profile using Noor Technologies (or your own organisation if you prefer):

# Noor Technologies Legal Negotiation Playbook

# Version: 1.0 | Last Updated: 2026-03-11 | Owner: Ayesha Malik (GC)

## Governing Principles

- We are typically: CUSTOMER (we buy cloud infrastructure, dev tools, SaaS)
- Risk tolerance: Moderate (growing SaaS, not yet regulated)
- Relationship context: New vendor relationships as we scale into UAE/UK
- Primary jurisdictions: Pakistani law (primary), English law (UK clients),
  DIFC law (Gulf expansion)

Now configure the six priority clause positions. Each follows the same structure: standard position, acceptable range, and RED escalation triggers.

1. Limitation of Liability

### Limitation of Liability

STANDARD POSITION: Mutual cap at 12 months' fees paid/payable
ACCEPTABLE RANGE: 6-24 months' fees, mutual
ESCALATE (RED) IF: Uncapped liability on either side;
cap below 6 months' fees; asymmetric carve-outs favouring vendor
NOTES: For contracts under PKR 2,000,000/year, 12-month cap
is non-negotiable. For strategic vendors above PKR 10,000,000/year,
24-month cap acceptable with GC approval.

2. Intellectual Property Ownership

### Intellectual Property Ownership

STANDARD POSITION: Each party retains pre-existing IP; work product
developed using our data or on our systems = our IP
ACCEPTABLE RANGE: Joint ownership of jointly developed materials
with prior written approval only
ESCALATE (RED) IF: Vendor claims ownership of deliverables created
using our data; broad licence-back without compensation;
no open-source component disclosure
NOTES: Pakistan is first-to-file for trademarks (Trade Marks
Ordinance 2001). Ensure vendor contracts do not create competing
TM registrations in our product categories.

3. Indemnification

### Indemnification

STANDARD POSITION: Mutual indemnification for third-party IP
infringement and gross negligence / wilful misconduct
ACCEPTABLE RANGE: Standard mutual with proportional contribution
ESCALATE (RED) IF: One-sided indemnification; uncapped IP indemnity;
indemnity triggered by our intended use of deliverables

4. Data Protection

### Data Protection and Privacy

STANDARD POSITION: PDPA 2023-compliant DPA required; data residency
in Pakistan or jurisdiction with adequacy determination;
72-hour breach notification; deletion on termination
ACCEPTABLE RANGE: Breach notification up to 96 hours; data residency
in Singapore or EU (adequate jurisdictions) acceptable
ESCALATE (RED) IF: No DPA offered; vendor stores data in jurisdiction
without adequacy determination; retention exceeds project term
plus 1 year; no deletion commitment on termination
NOTES: For UK/EU clients, UK GDPR / EU GDPR compliance required
in addition to PDPA 2023. SCCs required for transfers outside
adequate jurisdictions.

DPA (Data Processing Agreement): A DPA is a contract between a data controller and a data processor, required by data protection laws whenever one party processes personal data on behalf of another. When Noor Technologies uses a cloud ERP vendor that stores textile manufacturer employee records, that vendor is a data processor and a DPA must specify what data is processed, for what purpose, retention periods, breach notification timelines, and deletion obligations. Under Pakistan's PDPA 2023, failure to have a DPA exposes both parties to regulatory action. Under DIFC DP Law 2020, fines reach USD 100,000.

5. Termination

### Termination

STANDARD POSITION: Either party may terminate for convenience on
30 days' written notice
ACCEPTABLE RANGE: 14-60 days for convenience; termination for cause
on 10 days' notice with cure period
ESCALATE (RED) IF: No termination for convenience; auto-renewal
without 60-day notice window; exit penalties exceeding
3 months' fees; no data return/deletion on termination
NOTES: Ayesha missed 3 auto-renewals last quarter. Every contract
MUST have explicit auto-renewal notice periods tracked in the
compliance calendar.

6. Governing Law

### Governing Law and Jurisdiction

STANDARD POSITION: Pakistani law, courts in Karachi
ACCEPTABLE RANGE: English law for UK clients; DIFC law for Gulf
contracts; ICC arbitration for international contracts above
PKR 10,000,000
ESCALATE (RED) IF: Non-English governing law without translated
summary; mainland UAE law for contracts above AED 500,000
(Arabic version prevails in mainland courts -- translation risk);
any jurisdiction without established commercial law framework
NOTES: For Gulf expansion contracts, always specify DIFC law
over mainland UAE law. DIFC Courts are English-language, and
judgments are enforceable in 30+ jurisdictions.

NDA Configuration

Below the clause positions, add the NDA triage configuration:

## NDA Configuration

Standard form: Noor Technologies mutual NDA v2.1
Review SLA: Tier 1 = 1 business day; Tier 2 = 2 days; Tier 3 = 5 days

### Tier Criteria

Tier 1 (Auto-approve): Counterparty NDA on our template, no modifications,
mutual obligations, standard 2-year term
Tier 2 (Review): Counterparty's own form, or our template with
modifications to scope/term/return provisions
Tier 3 (Escalate to GC): Residual rights clause; non-compete restrictions;
no carve-outs for publicly available information; unilateral
obligations; term exceeding 5 years; governing law outside
Pakistan/UK/DIFC

Save the file. Your playbook now encodes Noor Technologies' institutional knowledge -- the positions Ayesha has developed across dozens of vendor negotiations, the lessons from three missed auto-renewals, the jurisdictional awareness needed for Pakistan/UAE/UK operations.

SCCs (Standard Contractual Clauses): SCCs are pre-approved contractual terms for transferring personal data from a jurisdiction with strong data protection to one without an adequacy decision. When Noor Technologies transfers client data from Pakistan to a cloud server in a country not recognised as adequate under PDPA 2023, SCCs provide the legal mechanism making the transfer lawful. The EU adopted new SCCs in June 2021; the UK has its own International Data Transfer Agreement (IDTA). DIFC and ADGM each maintain separate approved transfer mechanisms. Using the wrong SCCs for your jurisdiction -- or none at all -- can result in regulatory enforcement.

Test Your Playbook

Now run /review-contract on the same CloudStack agreement you reviewed in Lesson 1. Before you run it, predict: which clauses will change classification? If CloudStack's liability cap is 3 months' fees and your playbook standard is 12 months, what colour should it be?

/review-contract

Upload the CloudStack vendor SaaS agreement (same document from Lesson 1).
I am Noor Technologies, the customer. This is a standard SaaS vendor
agreement for cloud infrastructure. Contract value: PKR 2,400,000/year.
We need to finalise within 30 days.

Compare the two outputs side by side. Look for these differences:

Dimension	Without Playbook (Generic)	With Playbook (Calibrated)
Classification changes	Clauses tend to be YELLOW (generic concern)	Clauses may escalate to RED when they breach your specific thresholds
Specificity of analysis	Vague observations ("cap appears low")	Quantified comparison against your playbook floor ("X months' fees against your standard of Y months")
Redline language	Generic suggestions ("consider negotiating")	Position-specific instructions matching your playbook ("recommend mutual N-month cap")
Regulatory context	General data protection observation	Organisation-specific regulatory requirements (e.g., PDPA 2023 DPA requirement for your jurisdiction)

Your output will vary

The specific classifications and redline language depend on your playbook configuration and the plugin version. The teaching point is the difference in specificity and actionability between generic and playbook-calibrated output — not the exact clause classifications. Look for at least two clauses that change classification or become materially more specific.

The playbook turns generic observations into actionable instructions. That is the difference between a tool and an institutional knowledge system.

The agent reviews, triages, drafts, and flags. The licensed attorney advises, decides, and signs. The playbook makes the agent's output more specific, but the attorney still reviews every RED flag and makes the commercial judgment call.

PayGulf's Playbook: DFSA-Regulated Positions

Fatima Al-Rashidi's playbook at PayGulf looks different because her organisation's risk profile is different. PayGulf is DFSA-regulated. Fatima's data protection clause specifies DIFC DP Law 2020 compliance, not PDPA 2023. Her governing law clause defaults to DIFC law and DIFC Courts -- never mainland UAE law above AED 1,000,000 because Arabic-language versions prevail in mainland courts. Her limitation of liability floor is higher (AED 500,000) because DFSA-regulated entities require conservative postures.

Same plugin. Same commands. Radically different output -- because the playbook encodes institutional knowledge, not generic standards.

MCP Connector Categories

The Legal Plugin ships with connector definitions for nine categories of enterprise tools. Each skill in the plugin uses ~~category placeholders -- references like ~~cloud storage or ~~email -- that resolve at runtime to whatever MCP server you have connected.

Category	Placeholder	What It Enables	Example Providers
Calendar	~~calendar	Meeting context for briefing prep, deadline tracking	Google Calendar, Microsoft 365
Chat	~~chat	Escalation alerts, team notifications	Slack, Microsoft Teams
Cloud Storage	~~cloud storage	Read/write contracts from your document management system	Box, Egnyte, SharePoint
CLM	~~CLM	Contract lifecycle management integration	Ironclad, Agiloft
CRM	~~CRM	Client and vendor relationship context	Salesforce, HubSpot
Email	~~email	Contract intake, correspondence monitoring	Gmail, Microsoft 365
E-Signature	~~e-signature	Route documents for digital signature	DocuSign, Adobe Sign
Office Suite	~~office suite	Read and create Word, Excel, PDF documents	Microsoft 365, Google Workspace
Project Tracker	~~project tracker	Log matters, track obligations, manage legal projects	Atlassian (Jira), Linear

The design is category-agnostic. When a skill references ~~cloud storage, it works with Box, Egnyte, SharePoint, or Google Drive -- whichever you have connected. Swapping from Box to SharePoint requires changing your connector configuration, not modifying any skill. This means the plugin adapts to your existing tools rather than forcing you onto a specific platform.

Without connectors, the plugin is a document reviewer -- you upload contracts and paste text. With connectors, it becomes a process manager: the Contract Intake Agent in Lesson 10 monitors your Gmail for incoming agreements, the compliance calendar in Lesson 11 syncs deadlines to your Google Calendar, and the vendor management workflow in Lesson 9 pulls meeting context from your calendar and Slack channels.

You configured connectors as an optional step in Lesson 1. If you skipped that step and find yourself wanting the connected experience, return to Cowork's Customize menu and add connectors for the categories you use.

What You Built

1. Configured legal.local.md with Organisation Profile, 6 clause positions (Limitation of Liability, IP Ownership, Indemnification, Data Protection, Termination, Governing Law), and NDA Tier 1/2/3 criteria
2. Tested the playbook against the CloudStack agreement and compared before/after output -- seeing generic YELLOW flags become specific RED escalations with PKR-denominated analysis
3. Understanding of MCP connector categories and the ~~category placeholder system that makes the plugin provider-agnostic

Flashcards Study Aid

Try With AI

Setup: Use these prompts in Cowork or your preferred AI assistant.

Prompt 1: Reproduce

I am configuring a Legal Plugin negotiation playbook for
[describe your organisation: size, industry, primary jurisdiction].

Help me build the "Limitation of Liability" clause position using
this structure:

- STANDARD POSITION: [what we ideally want]
- ACCEPTABLE RANGE: [what we can live with]
- ESCALATE (RED) IF: [hard limits that require attorney review]
- NOTES: [jurisdiction-specific considerations]

Ask me questions about my organisation's risk tolerance, typical
contract values, and past negotiation outcomes to calibrate each
field. Then produce the complete clause position ready to paste
into legal.local.md.

What you are learning: The playbook is not a template you fill in abstractly -- it encodes real institutional knowledge. The questions the AI asks mirror the expert interview methodology legal operations professionals use to extract negotiation positions from senior counsel. Learning to answer these questions is learning to articulate your organisation's risk profile.

Prompt 2: Adapt

I want to understand the difference between a generic contract
review and a playbook-calibrated review.

Here is a contract clause:
"The total aggregate liability of Vendor shall not exceed the fees
paid by Customer in the three (3) months immediately preceding
the event giving rise to the claim."

Show me two analyses of this clause:
1. A generic review against "widely-accepted commercial standards"
2. A playbook-calibrated review where the playbook specifies:
   - Standard position: 12 months' fees
   - Acceptable range: 6-24 months
   - RED escalation if cap below 6 months

For each analysis, show the classification (GREEN/YELLOW/RED),
the issue identified, and the proposed redline language.

What you are learning: The playbook does not just change a label from YELLOW to RED -- it changes the specificity and quality of the entire analysis. A generic review says "this seems low." A playbook-calibrated review says "this is PKR 600,000 against your minimum of PKR 2,400,000 -- 75% below your floor -- and here is the exact replacement language." The playbook transforms observations into instructions.

Prompt 3: Apply

Take a real contract or vendor agreement from your own organisation.
Build a negotiation playbook entry for the clause type that causes
the most friction in your reviews (liability cap, indemnity,
governing law, or IP ownership).

For your chosen clause:
1. Define your ideal position
2. Define your acceptable fallback
3. Define your walk-away threshold
4. Write the agent instruction that encodes these three positions

Compare the result against a /review-contract run on the same
agreement — does the playbook change the agent's classification?

What you are learning: The gap between a generic playbook and one calibrated to your organisation's actual risk appetite. A liability cap that is RED for a startup may be GREEN for an enterprise with insurance coverage. Your playbook entries encode institutional knowledge that no generic plugin can replicate.