Context Brief: Legal Contract Clause Review

content/demos/legal-clause-review-demo.json

{
  "raw_materials": {
    "key_facts": [
      {
        "label": "Contract value",
        "value": "$180,000/yr"
      },
      {
        "label": "Renewal in",
        "value": "45 days"
      },
      {
        "label": "Liability floor",
        "value": "12 months' fees"
      },
      {
        "label": "Switching cost",
        "value": "$220,000"
      }
    ],
    "clause_comparison": [
      {
        "clause": "Limitation of Liability",
        "current_term": "Vendor's total liability shall not exceed the fees paid by Customer in the twelve (12) months preceding the claim.",
        "proposed_term": "Vendor's total liability shall not exceed the fees paid by Customer in the three (3) months preceding the claim."
      },
      {
        "clause": "Data Loss Exclusion (new)",
        "current_term": "No equivalent clause in the current agreement.",
        "proposed_term": "Vendor shall not be liable for any data loss or corruption arising from Customer's own system integrations, API usage, or configuration changes."
      }
    ],
    "deal_notes": [
      {
        "from": "Procurement",
        "when": "3 days ago",
        "body": "Vantage Ops renewal due in 45 days. Price holding flat at $180,000/year for a second cycle \u2014 no increase, unusual in this market. Reads as a retention gesture; deal team wants a clean, quick renewal if possible."
      },
      {
        "from": "IT",
        "when": "8 months ago, relevant background",
        "body": "Our team built two custom API integrations into the Vantage Ops platform to sync inventory data. Five months ago, a bug in our own integration code caused a brief data sync issue that self-resolved within a day. Root cause was confirmed as our code, not the Vantage Ops platform."
      },
      {
        "from": "Finance",
        "when": "5 days ago",
        "body": "We used our negotiating capital last cycle to get NET-60 payment terms instead of NET-30. No internal appetite for a drawn-out renegotiation this cycle \u2014 switching vendors is estimated at $220,000 and six months of migration, so we're not walking away over this renewal."
      },
      {
        "from": "Legal (paralegal), flagging precedent",
        "when": "raised today, re: a dispute from 2 years ago",
        "body": "Worth flagging: our dispute with Cascade Metrics two years ago involved a liability cap set below our 12-month floor, and when their platform caused a data breach, we couldn't recover full damages. It's part of why we hold the line on the 12-month floor. Some on the team are citing it as a reason to push back on the new carve-out clause too."
      }
    ],
    "playbook_excerpt": [
      "Limitation of liability floor: Vendor's cap must be no lower than twelve (12) months of fees paid, unless VP Legal signs off on an exception. Every clause review must state clearly whether the proposed term meets, falls below, or exceeds this floor, and by how much.",
      "Carve-outs for customer-controlled systems (custom integrations, API usage, customer-side configuration) are standard and acceptable, provided the carve-out is scoped narrowly to failures caused by the customer's own systems and does not extend to defects in the vendor's own platform.",
      "Every clause review must end with one of three recommendations: Accept as drafted, Negotiate (stating the specific ask), or Escalate to VP Legal. A review without one of these three is incomplete."
    ],
    "risk_language_guide": {
      "do": [
        "State the specific gap between the floor and the proposed number, not just that it's \u2018too low\u2019",
        "Name whether a carve-out is scoped narrowly or broadly, quoting the specific phrase if it overreaches",
        "Weigh deal context (renewal timing, switching cost, negotiating capital already spent) when deciding how hard to push",
        "Check whether a past dispute shares the actual mechanism before citing it as precedent"
      ],
      "dont": [
        "Don't call a clause \u2018risky\u2019 without citing the specific playbook threshold it violates",
        "Don't let a precedent relevant to one clause bleed into the reasoning for an unrelated clause",
        "Don't recommend \u2018negotiate\u2019 without stating the specific number or wording being asked for"
      ]
    }
  },
  "presets": [
    {
      "id": "none",
      "label": "No curation",
      "summary": "The full clause comparison, deal notes, playbook excerpt and risk language guide, handed over as-is with no framing.",
      "brief": "No brief. The model was given the full clause comparison, the full deal history notes, the full playbook excerpt and the full risk language guide, unedited, with the instruction \u201cwrite the clause review.\u201d",
      "response": "The proposed Limitation of Liability clause lowers the cap from 12 months of fees to 3 months, which is a significant reduction and looks risky. The new Data Loss Exclusion clause is also concerning \u2014 letting the vendor off the hook for data loss is the kind of thing that got us burned with Cascade Metrics before, so we should be cautious about accepting either change. Recommendation: negotiate harder on both clauses before signing.",
      "critique": "Never cites the playbook's specific 12-month floor or the dollar gap it creates, just calls the cap change \u201crisky.\u201d Treats the Data Loss Exclusion as equally concerning, ignoring that IT already confirmed the matching real-world incident was customer-caused and that the playbook treats this kind of carve-out as standard. Applies the Cascade Metrics precedent to both clauses even though it only shares a mechanism with one of them. Closes with \u201cnegotiate harder on both clauses,\u201d which names no specific ask.",
      "annotations": [
        {
          "id": "n1",
          "type": "gap",
          "label": "The playbook sets a specific 12-month floor \u2014 \u201clooks risky\u201d doesn't cite it, and the response never states the $135,000 gap it creates.",
          "response_span": "which is a significant reduction and looks risky"
        },
        {
          "id": "n2",
          "type": "gap",
          "label": "IT already confirmed the matching real-world incident was caused by the company's own integration code \u2014 this carve-out matches that history and is standard under the playbook, not a red flag.",
          "response_span": "The new Data Loss Exclusion clause is also concerning"
        },
        {
          "id": "n3",
          "type": "gap",
          "label": "Cascade Metrics involved a vendor-caused breach paired with a low cap \u2014 a different mechanism from this customer-caused carve-out. It shouldn't be cited against this clause.",
          "response_span": "letting the vendor off the hook for data loss is the kind of thing that got us burned with Cascade Metrics before, so we should be cautious about accepting either change"
        },
        {
          "id": "n4",
          "type": "gap",
          "label": "\u201cNegotiate harder on both clauses\u201d doesn't say what's actually being asked for on either one.",
          "response_span": "negotiate harder on both clauses before signing"
        }
      ]
    },
    {
      "id": "partial",
      "label": "Partial curation",
      "summary": "The liability cap issue is resolved precisely, but the carve-out clause is still treated as an open question instead of a resolved one.",
      "brief": "Situation: The proposed Limitation of Liability clause lowers the cap from 12 months of fees to 3 months. Context: The playbook floor is 12 months' fees; anything lower needs VP Legal sign-off.",
      "response": "The proposed Limitation of Liability clause lowers the cap from 12 months of fees to 3 months, falling below the playbook's 12-month floor. This requires either negotiating the cap back up or getting VP Legal sign-off on the exception. The new Data Loss Exclusion clause also raises questions, and it's worth considering how it compares to the Cascade Metrics situation before we accept it. Recommendation: negotiate the liability cap; flag the exclusion clause for further discussion.",
      "critique": "Gets the liability cap right: cites the specific floor and gives a real two-path recommendation (negotiate or escalate). But the brief says nothing about the Data Loss Exclusion clause, so the response still treats it as an open question, still lets Cascade Metrics bleed into it, and \u201cflag for further discussion\u201d states no actual ask.",
      "annotations": [
        {
          "id": "p1",
          "type": "pair",
          "brief_line": "The proposed Limitation of Liability clause lowers the cap from 12 months of fees to 3 months.",
          "response_span": "The proposed Limitation of Liability clause lowers the cap from 12 months of fees to 3 months, falling below the playbook's 12-month floor."
        },
        {
          "id": "p2",
          "type": "pair",
          "brief_line": "The playbook floor is 12 months' fees; anything lower needs VP Legal sign-off.",
          "response_span": "This requires either negotiating the cap back up or getting VP Legal sign-off on the exception."
        },
        {
          "id": "p3",
          "type": "gap",
          "label": "The brief says nothing about the carve-out's actual scope or IT's confirmed root-cause history, so the response still treats it as unresolved.",
          "response_span": "The new Data Loss Exclusion clause also raises questions, and it's worth considering how it compares to the Cascade Metrics situation before we accept it."
        },
        {
          "id": "p4",
          "type": "gap",
          "label": "\u201cFlag \u2026 for further discussion\u201d doesn't say what would actually be discussed or resolved.",
          "response_span": "flag the exclusion clause for further discussion"
        }
      ]
    },
    {
      "id": "full",
      "label": "Full curation",
      "summary": "Both clauses get a specific playbook citation, a concrete recommendation, and the precedent is applied only where it actually fits.",
      "brief": "Situation: Two clauses under review for the Vantage Ops renewal ($180,000/year, 45 days to close). Clause 1 \u2014 Limitation of Liability: proposed term lowers the cap from 12 months' fees ($180,000) to 3 months' fees ($45,000), a $135,000 gap below the playbook's 12-month floor. Clause 2 \u2014 Data Loss Exclusion (new): the carve-out is scoped to \"Customer's own system integrations, API usage, or configuration changes\" \u2014 narrowly limited to customer-controlled systems, not the vendor's platform. What's confirmed: IT's own integration code caused a minor data sync issue 5 months ago, root cause confirmed as customer-side, not a Vantage Ops platform defect \u2014 this matches exactly the failure mode Clause 2 carves out, and the playbook treats narrowly-scoped customer-system carve-outs as standard and acceptable. Deal context: negotiating capital was already spent last cycle on payment terms, and switching vendors would cost $220,000 and six months, so push firmly only where the playbook is actually violated. Exclude: The Cascade Metrics precedent is real and relevant to Clause 1 \u2014 that dispute is the reason the 12-month floor exists \u2014 but it does not apply to Clause 2: Cascade Metrics involved a vendor-caused breach paired with a low cap, not a customer-caused failure carved out narrowly. Don't cite it against Clause 2. Recommended action: Clause 1 \u2014 Negotiate, specifically proposing reinstatement of the 12-month cap, with Cascade Metrics cited as the reason; if the vendor won't move, escalate to VP Legal per playbook. Clause 2 \u2014 Accept as drafted; it meets the playbook's carve-out standard and matches confirmed customer-side history. Tone: name the specific playbook threshold or scoping language for each clause, state the specific ask, and don't let the Clause 1 precedent bleed into Clause 2 reasoning.",
      "response": "Clause 1 \u2014 Limitation of Liability: the proposed term lowers the cap from 12 months' fees ($180,000) to 3 months' fees ($45,000), a $135,000 gap below the playbook's 12-month floor. This is the same fact pattern that cost us with Cascade Metrics \u2014 a below-floor cap ahead of a vendor-caused incident \u2014 so it's worth pushing on; recommendation is to negotiate for reinstatement of the 12-month cap, escalating to VP Legal per playbook if the vendor won't move. Clause 2 \u2014 Data Loss Exclusion: the carve-out is scoped to \"Customer's own system integrations, API usage, or configuration changes\" \u2014 narrowly limited to customer-controlled systems, matching the playbook's standard for acceptable carve-outs, and matching our own history, since IT confirmed the sync issue five months ago was caused by our own integration code, not the Vantage Ops platform. Cascade Metrics doesn't apply here \u2014 that case was a vendor-caused breach paired with a low cap, a different mechanism entirely \u2014 so recommendation is to accept Clause 2 as drafted. Given negotiating capital was already spent on payment terms last cycle and switching vendors would cost $220,000 and six months, this focuses the pushback on the clause that actually violates the playbook rather than re-litigating one that already meets standard.",
      "critique": "Cites the specific playbook threshold and dollar gap for Clause 1, and the specific scoping language for Clause 2, rather than calling either \u201crisky\u201d or \u201cconcerning.\u201d Applies Cascade Metrics only to Clause 1, where the mechanism actually matches (vendor-caused breach, low cap), and explicitly rules it out for Clause 2, where the carve-out is customer-caused and already meets standard. Gives a concrete ask for Clause 1 (reinstate the 12-month cap, escalate if refused) and a clear accept for Clause 2, then uses the deal context \u2014 spent negotiating capital, high switching cost \u2014 to justify pushing hard on one clause and not re-litigating the other.",
      "annotations": [
        {
          "id": "f1",
          "type": "pair",
          "brief_line": "proposed term lowers the cap from 12 months' fees ($180,000) to 3 months' fees ($45,000), a $135,000 gap below the playbook's 12-month floor",
          "response_span": "the proposed term lowers the cap from 12 months' fees ($180,000) to 3 months' fees ($45,000), a $135,000 gap below the playbook's 12-month floor"
        },
        {
          "id": "f2",
          "type": "pair",
          "brief_line": "The Cascade Metrics precedent is real and relevant to Clause 1 \u2014 that dispute is the reason the 12-month floor exists \u2014 but it does not apply to Clause 2: Cascade Metrics involved a vendor-caused breach paired with a low cap, not a customer-caused failure carved out narrowly.",
          "response_span": "Cascade Metrics doesn't apply here \u2014 that case was a vendor-caused breach paired with a low cap, a different mechanism entirely"
        },
        {
          "id": "f3",
          "type": "pair",
          "brief_line": "IT's own integration code caused a minor data sync issue 5 months ago, root cause confirmed as customer-side, not a Vantage Ops platform defect",
          "response_span": "IT confirmed the sync issue five months ago was caused by our own integration code, not the Vantage Ops platform"
        },
        {
          "id": "f4",
          "type": "pair",
          "brief_line": "Clause 2 \u2014 Data Loss Exclusion (new): the carve-out is scoped to \"Customer's own system integrations, API usage, or configuration changes\" \u2014 narrowly limited to customer-controlled systems, not the vendor's platform.",
          "response_span": "Clause 2 \u2014 Data Loss Exclusion: the carve-out is scoped to \"Customer's own system integrations, API usage, or configuration changes\" \u2014 narrowly limited to customer-controlled systems, matching the playbook's standard for acceptable carve-outs"
        },
        {
          "id": "f5",
          "type": "pair",
          "brief_line": "Recommended action: Clause 1 \u2014 Negotiate, specifically proposing reinstatement of the 12-month cap, with Cascade Metrics cited as the reason; if the vendor won't move, escalate to VP Legal per playbook.",
          "response_span": "recommendation is to negotiate for reinstatement of the 12-month cap, escalating to VP Legal per playbook if the vendor won't move"
        },
        {
          "id": "f6",
          "type": "pair",
          "brief_line": "Deal context: negotiating capital was already spent last cycle on payment terms, and switching vendors would cost $220,000 and six months, so push firmly only where the playbook is actually violated.",
          "response_span": "Given negotiating capital was already spent on payment terms last cycle and switching vendors would cost $220,000 and six months, this focuses the pushback on the clause that actually violates the playbook rather than re-litigating one that already meets standard."
        }
      ]
    }
  ]
}