Contract Analysis — Obligation Extraction
A vendor contract auto-renewed. The notice deadline was 90 days before renewal. The renewal date was 14 March. Nobody tracked the deadline. The first anyone knew was when the invoice arrived in April — £180,000 for another full year of a service the team had mostly stopped using six months ago. The clause that caused it was on page 17 of a 22-page Master Service Agreement. It read: "Unless either party provides written notice of non-renewal no fewer than 90 days prior to the end of the Term, this Agreement shall automatically renew for successive one-year periods."
Standard language. Easily missed. Expensive to ignore.
This is not an edge case. Across an organisation's vendor portfolio, contracts contain obligations, SLA commitments, auto-renewal traps, liability limits, price escalation clauses, and data ownership terms that nobody has systematically read, extracted, and tracked. The vendor portfolio audit from Lesson 3 told you what vendors you have and when they renew. This lesson teaches you what those contracts actually say — and what you have unknowingly agreed to.
This exercise requires the Operations plugin (official) and the Operations Intelligence plugin (custom). If you have not installed them, follow the instructions in the Chapter 38 prerequisites before continuing.
Why Contracts Are Unread
Most vendor contracts are signed, filed, and forgotten. The person who negotiated the contract may have left. The team that uses the service does not know the contract terms. The finance team knows the invoice amount but not the SLA commitments. Operations knows the renewal date but not the notice period.
The result is that the organisation has legal obligations it cannot enumerate and contractual rights it cannot exercise. Vendor SLAs are missed without anyone claiming credits. Auto-renewals fire without challenge. Price escalation clauses compound silently.
The gap between "we have a contract with this vendor" and "we know what that contract commits us to" is where operational risk lives. Contract analysis closes this gap — systematically, for every contract in the portfolio.
The Four Contract Analysis Task Types
The /contract command handles four types of analysis, each addressing a different operational need:
| Task Type | When to Use | Output |
|---|---|---|
| Obligation extraction | Onboarding a new contract; preparing for audit; understanding commitments | Structured tables: Our Obligations, Vendor Obligations, Key Dates, SLAs |
| Risk flagging | Pre-renewal review; new contract evaluation; risk assessment | Risk-flagged clause list with severity and negotiation position |
| Contract summary | Briefing a non-legal reader; executive summary; new team member onboarding | Plain-language one-page summary of what both parties have agreed to |
| Renewal strategy input | 90-180 days before renewal; renegotiation preparation | Current terms + performance against terms + negotiation levers |
For most contracts, you will run obligation extraction first, then risk flagging. Together these produce the full intelligence picture the organisation needs.
Running Obligation Extraction with /contract
Worked example. Your portfolio audit identified a cloud infrastructure provider as your highest-value vendor at £385,000 per year, renewing in eight months. Before you can negotiate, you need to know exactly what the current contract says. You type:
/contract
Extract all obligations, SLAs, and key dates from this vendor contract.
Vendor: Apex Cloud Solutions. Contract: Master Service Agreement + Schedule A.
[Paste or describe the full contract text]
I want:
1. All our obligations (what we must do, by when, consequence if breached)
2. All vendor obligations including SLAs with exact metrics and breach consequences
3. Every key date with the notice period and action required
4. A complete SLA table
5. Any auto-renewal clauses flagged explicitly
What to expect: A structured extraction with five clearly separated sections.
| Output Section | What to Verify |
|---|---|
| Our Obligations | Every obligation is specific: named, dated, and consequence-linked |
| Vendor Obligations | Each SLA has a metric, a target, and a credit/remedy if breached |
| Key Dates | Every date includes the notice period required and the action needed |
| SLA Table | Measurement method and reporting frequency are specified, not just targets |
| Auto-Renewal Flags | The exact notice mechanism (written notice to whom, via what channel) is captured |
A well-formed extraction looks like this:
CONTRACT OBLIGATIONS: Apex Cloud Solutions — MSA + Schedule A
Contract date: 1 March 2024 | Effective: 1 March 2024 | Expires: 28 Feb 2026
════════════════════════════════════════════════════════════════
OUR OBLIGATIONS:
| # | What we must do | By when / How often | Consequence if breached |
|---|---|---|---|
| 1 | Pay monthly invoices | Net 30 from invoice date | Late payment interest at 2% above base rate |
| 2 | Provide 30 days notice of significant usage increase (>20%) | Rolling basis | Vendor may revise pricing |
| 3 | Assign a named technical contact for incident escalation | Contract start; update within 5 days of change | Escalation SLA may be voided |
| 4 | Maintain data security practices per Schedule B requirements | Continuous | Right to audit; potential termination |
VENDOR OBLIGATIONS:
| # | What vendor must do | Metric | Consequence |
|---|---|---|---|
| 1 | Maintain service uptime | 99.9% monthly | 10% monthly fee credit per 0.1% below threshold |
| 2 | P1 response time | Within 1 hour of report | SLA credit: 5% of monthly fee per breach |
| 3 | P1 resolution | Within 4 hours | SLA credit: 10% of monthly fee per breach |
| 4 | Monthly reporting | By 5th of following month | No specified consequence |
| 5 | Data security compliance (ISO 27001) | Continuous certification | Termination for cause |
KEY DATES:
| Date | Event | Notice required | Action needed |
|---|---|---|---|
| 1 Dec 2025 | Auto-renewal notice deadline | 90 days written notice to prevent | Decide: renew, renegotiate, or exit |
| 28 Feb 2026 | Contract expiry / auto-renewal | — | If notice sent, ensure transition plan in place |
| 1 Mar 2026 | Annual price review (Schedule A, Clause 8.2) | 60 days to object | Review and respond to any proposed increase |
| Quarterly | SLA performance review | — | Schedule review meeting; request quarterly reports |
SLA TABLE:
| Metric | Target | Measurement | Reporting | Credit if breached |
|---|---|---|---|---|
| Monthly uptime | 99.9% | Continuous monitoring | Vendor reports by 5th | 10% of monthly fee per 0.1% below |
| P1 response | 1 hour | Time from report to acknowledgement | Monthly SLA report | 5% of monthly fee per breach |
| P1 resolution | 4 hours | Time from report to resolution | Monthly SLA report | 10% of monthly fee per breach |
AUTO-RENEWAL FLAGS:
⚠️ AUTO-RENEWAL: Contract auto-renews for successive one-year periods
Notice deadline: 1 December 2025 (90 days before 28 Feb 2026 expiry)
Notice method: Written notice to legal@apexcloud.com (Clause 18.1)
Current calendar entry: [NONE FOUND — ADD IMMEDIATELY]
════════════════════════════════════════════════════════════════
The obligation extraction you build here feeds directly into Lesson 7 (Compliance), where your contractual obligations become part of your organisation's obligation landscape. Save this work — you will reference it again.
The Six Risk Flag Categories
After extracting obligations, run risk flagging. The /contract command identifies six categories of clauses that most frequently create unintended risk. Understanding each category helps you know what to look for when evaluating AI output.
| Flag Category | What It Looks Like | Why It Matters |
|---|---|---|
| Auto-renewal traps | Contract renews unless written notice given by [date] | Missing the notice window commits to another full term |
| Liability caps | Vendor liability capped at [N] months of fees | Recovery may be far less than actual loss |
| Price escalation | Annual increase of CPI or [N]%, whichever is higher | Budgets set today understate future obligations |
| Unilateral change rights | Vendor may amend terms with [N] days' notice | Your agreed terms can change without your consent |
| Termination for convenience | Either party (or only vendor) may terminate with [N] days notice | Vendor can exit; your operational continuity depends on this |
| Data ownership / return | Absence of explicit data portability clause | Data lock-in; difficulty or expense in switching |
Worked example — risk flagging:
/contract
Risk-flag this vendor contract. I want every unfavourable clause identified,
categorised against the six standard risk flag types, and rated by severity.
For each flag, provide a suggested negotiation position.
Contract: Apex Cloud Solutions MSA — I have already run obligation
extraction; paste the relevant clauses for risk analysis:
[Paste contract sections or describe specific clauses]
What to expect: A risk flag report organised by category, with severity ratings and negotiation positions.
RISK FLAG REPORT: Apex Cloud Solutions MSA
════════════════════════════════════════════════════════════════
FLAG 1: AUTO-RENEWAL TRAP — 🔴 HIGH
Clause (18.1): "...shall automatically renew for successive one-year periods
unless either party provides 90 days' written notice of non-renewal."
Risk: Missing the 1 December 2025 deadline commits to another full year
at current pricing (£385,000). No exception for price disputes.
NEGOTIATION POSITION:
Our position: Reduce notice period to 30 days; add option to renew
month-to-month during negotiation period
Rationale: 90 days is above market standard for SaaS agreements
Accept if: Vendor agrees to price freeze during any renewal period
Walk-away if: Vendor insists on 90 days AND refuses price freeze
FLAG 2: LIABILITY CAP — 🟡 MEDIUM
Clause (14.2): "Vendor's total liability shall not exceed fees paid in
the three months preceding the claim."
Current exposure: 3 months = ~£96,000. Our operational dependency on
this service suggests potential loss from an extended outage could
substantially exceed this.
NEGOTIATION POSITION:
Our position: Increase cap to 12 months (£385,000)
Rationale: Cap should reflect operational dependency, not be
arbitrary; 12-month cap is common in enterprise agreements
Accept if: Cap remains at 3 months but SLA credits are enhanced
Walk-away if: Cap below 6 months for this level of operational dependency
FLAG 3: PRICE ESCALATION — 🟡 MEDIUM
Clause (8.2): "Annual pricing subject to increase of CPI or 5%, whichever
is higher."
Current annual cost: £385,000. At 5% per year: Year 3 = £424,000.
NEGOTIATION POSITION:
Our position: Cap at CPI only; no minimum escalation floor
Rationale: 5% floor is above current inflation environment;
we are accepting volume and payment risk, not inflation risk
Accept if: 3% floor agreed; or multi-year fixed price with CPI review at Year 3
FLAG 4: DATA OWNERSHIP — 🔴 HIGH
Clause (12.1-12.3): No explicit statement that customer data remains
customer property. No data return clause on termination. Clause 12.4
permits vendor to retain data for "up to 12 months post-termination."
NEGOTIATION POSITION:
Our position: Add explicit ownership clause; require data return in
portable format within 30 days of termination
Rationale: Data portability is essential for operational continuity;
absence of this clause creates switching lock-in
Walk-away if: Vendor refuses to add any data return obligation
════════════════════════════════════════════════════════════════
The Negotiation Position Framework
For each risk flag, the /contract command generates a negotiation position with five components. Understanding each component ensures the output is actionable:
| Component | What It Means |
|---|---|
| Issue | The specific clause and why it creates risk in your context |
| Our position | What you want the clause to say instead |
| Rationale | Why your position is reasonable — market standard, business logic, or precedent |
| Accept if | The minimum acceptable alternative if your preferred position is declined |
| Walk-away if | The condition under which this clause becomes a deal-breaker |
The walk-away threshold is the most important component to define in advance. Without it, negotiations drift toward accepting whatever the vendor offers, because "something is better than nothing." Knowing your walk-away threshold before the negotiation starts is what gives you leverage.
Exercise: Contract Obligation Extraction and Risk Analysis (Exercise 5)
Type: Contract management
Time: 40 minutes
Plugin command: Custom /contract
Goal: Extract full obligations from three vendor contracts, identify risk flags, and draft a negotiation position for the highest-risk clause
Step 1 — Select Your Contracts
Using the vendor portfolio from Lesson 3, identify three contracts for analysis:
- High-value vendor — your largest contract by annual spend (>£100,000/yr)
- Auto-renewal candidate — a contract renewing in the next 6 months
- SLA-critical vendor — a vendor whose performance directly affects service delivery
If you are working with your own organisation, use actual contracts. For this exercise, you may also use the following scenarios:
- Contract A (High-value): ERP software vendor, £210,000/yr, 3-year agreement, renewing in 14 months
- Contract B (Auto-renewal): Marketing automation platform, £67,000/yr, auto-renews in 45 days, 90-day notice required
- Contract C (SLA-critical): IT managed services provider, £95,000/yr, P1 SLA 4-hour resolution
Step 2 — Run Obligation Extraction
For each contract, run:
/contract
Extract all obligations, SLAs, and key dates from this vendor contract.
Vendor: [Vendor name and type]
Contract type: [MSA / SaaS / Service agreement]
Annual value: £[amount]
Renewal date: [Date]
[Paste contract text or describe the key terms and clauses in as much
detail as you have. Include: payment terms, notice periods, SLAs with
targets and consequences, any auto-renewal language, liability cap,
price escalation, data ownership, and termination rights.]
Produce: Our Obligations table, Vendor Obligations table, Key Dates
table, SLA Table, and Auto-Renewal Flags section.
What to evaluate:
- Does the output separate our obligations from vendor obligations? The distinction matters — these represent different types of risk.
- Are all key dates extracted, including notice periods? The notice deadline is more operationally critical than the renewal date itself.
- Are auto-renewal clauses explicitly flagged with the exact notice mechanism (not just the deadline)?
- Does every SLA entry include the consequence for breach? An SLA without a consequence is aspirational, not contractual.
- Would a procurement manager find this extraction actionable without reading the full contract?
Step 3 — Run Risk Flagging
For your highest-value or auto-renewal contract, run:
/contract
Risk-flag this contract. I want all unfavourable clauses identified,
categorised against the six standard risk flag types (auto-renewal traps,
liability caps, price escalation, unilateral change rights, termination
convenience, data ownership/return), and rated by severity (High / Medium / Low).
For each flag, provide a complete negotiation position:
- Issue: [clause description]
- Our position: [what we want]
- Rationale: [why this is reasonable]
- Accept if: [minimum acceptable alternative]
- Walk-away if: [deal-breaker condition]
Contract: [contract details from Step 2]
What to evaluate:
- Are all six flag categories checked, not just the obvious ones? Price escalation and data ownership are frequently missed.
- Is the severity rating appropriate for the vendor's operational importance? A liability cap on a low-value vendor has different implications than the same cap on a mission-critical one.
- Is the negotiation position specific? "We want better terms" is not a position. "We want the liability cap increased to 12 months of fees" is.
- Are the walk-away conditions realistic — not so demanding that no vendor would accept them, but not so weak that they offer no protection?
Step 4 — Identify Risk Flags Across All Three Contracts
Run risk flagging on all three contracts and produce a consolidated risk summary:
| Contract | Flags Found | Highest Severity | Notice Deadline | Negotiation Priority |
|---|---|---|---|---|
| Contract A (ERP) | [N] | [H/M/L] | [Date] | [High/Medium/Low] |
| Contract B (MarTech) | [N] | [H/M/L] | [Date] | [High/Medium/Low] |
| Contract C (IT MSP) | [N] | [H/M/L] | [Date] | [High/Medium/Low] |
Deliverable: Three obligation extraction tables, one risk flag report with negotiation positions for the highest-risk contract, and a consolidated risk summary. Save this work — you will use the contractual obligations extracted here when mapping your compliance landscape in Lesson 7.
The contract obligations you have extracted here are not just procurement intelligence — they are compliance obligations. In Lesson 7 (Compliance Tracking), you will map your organisation's full obligation landscape, and contractual obligations are a significant part of it. Keep this extraction work available.
Try With AI
Reproduce: Apply what you just learned to a simple case.
Analyse this SaaS vendor contract and extract obligations:
Vendor: ProjectPro (project management SaaS)
Annual fee: £18,000 (£1,500/month, billed annually in advance)
Term: 1 year, auto-renews unless 60 days' written notice given
Uptime SLA: 99.5% monthly; credit of 5% monthly fee if below 99%
Support SLA: P1 response 4 hours; no credit specified for breach
Our obligations: pay annually in advance; maintain accurate user count;
notify vendor within 30 days if users exceed 50 (current: 38)
Data: vendor retains data for 90 days post-termination; export available on request
Price: increases by CPI annually from year 2
Liability cap: total liability capped at fees paid in prior 2 months
Produce: Our Obligations, Vendor Obligations, Key Dates (assuming today
is 1 March 2026 and renewal is 28 February 2027), SLA Table, and all
risk flags with severity ratings.
What you are learning: This exercise builds the pattern: read the contract terms, map them into the five output sections, and flag every risk category present. Notice that even a simple £18,000 SaaS agreement contains four of the six risk flag types. Now imagine this repeated across 47 vendors.
Adapt: Modify the scenario to match your organisation.
I have a vendor contract that I want to analyse for risk. Please extract
all obligations and flag any unfavourable clauses.
Vendor: [describe what they provide and the contract value]
Term and renewal: [describe the renewal terms including any auto-renewal]
SLAs: [list any service level commitments the vendor has made]
Our commitments: [describe what we are required to do under the contract]
Liability: [describe the liability cap if you know it]
Data terms: [describe what happens to our data if we leave]
Price terms: [describe any escalation or review mechanism]
For each risk flag, provide a negotiation position I could use at renewal.
What you are learning: Applying this to a real contract reveals the gap between what you thought the contract said and what it actually commits both parties to. Most organisations discover at least two risks they did not know they had.
Apply: Extend to a new situation the lesson didn't cover directly.
I am about to sign a new vendor contract for a critical supplier. Before
signing, I want to pressure-test the terms.
Vendor type: [e.g., legal tech SaaS / professional services firm / cloud provider]
Contract value: [annual amount]
Initial term: [e.g., 2 years with auto-renewal]
Proposed terms: [describe or paste the key clauses]
Rather than just extracting current obligations, help me identify which
clauses I should push back on BEFORE signing. For each clause I should
challenge, explain: (1) what the market standard looks like, (2) what
counter-proposal I should make, and (3) what I should accept as a
compromise if pushed.
What you are learning: Contract review before signing is where the real leverage lies. After signature, you negotiate from a position of compliance with existing terms. Before signature, you set the terms. This prompt shifts the mode from analysis to pre-signing review — a different and higher-leverage application of the same framework.
Flashcards Study Aid
Continue to Lesson 5: Process Documentation — SOPs and Runbooks →