The AI drafts a services agreement. The indemnification clause looks right — well-structured, professional, indistinguishable from a document a senior associate would produce at two in the morning. The associate reviewing it skims it, finds nothing alarming, and sends it to the counterparty.
Two days later, opposing counsel redlines it. The clause, as drafted, granted the other side indemnification for their own gross negligence. It was within the four corners of the standard template language the AI had seen in training. It was not within the company’s approved positions. It was not flagged. It just read authoritative — and that is the failure mode that makes AI in legal uniquely dangerous.
This is Part 11 of ADD Beyond Code. The software-native version of this method established the pattern: constrain the what, free the how, verify by evidence. Legal is where that pattern maps almost literally, because legal work already organizes itself around a concept that is structurally identical to ADD’s frozen contract — the negotiation playbook. The translation requires less stretching than almost any other domain.
The four failures, in legal
Fast waste, legal edition: a plausible clause or redline that reads finished but misses a material risk, contradicts the approved playbook, or quietly grants a concession the team has never authorized. The output looks authoritative. That is what makes it dangerous — legal prose signals confidence in a way that vague marketing copy does not.
Context rot: the negotiation playbook, the fallback positions, the approved carve-outs — these live in a senior lawyer’s head or in a binder that was last updated when someone remembered to. Every new AI session re-derives the positions from scratch, or worse, from whatever prior agreement the model was trained on that may not reflect this company’s risk tolerance at all.
Trust-by-inspection breaks down: an AI-drafted clause looks the same whether it is on-playbook or subtly off it. Reading it feels like reviewing it. It is not. A reasonable-sounding limitation of liability cap could be half the approved floor. The only way to know is to check it against the playbook — not to read it and find it reasonable.
Verification ceiling: if AI can draft a full agreement in minutes, a legal team can receive more paper than they can carefully review. The excess is not throughput. It is unreviewed risk that accumulates until a deal closes on terms no one intended to grant.
The loop, translated
The ADD loop runs eight steps. In legal, each step has a direct domain equivalent — and some map so cleanly the language barely changes.
Step 0: Ground — load the playbook
Before drafting or redlining anything, the AI reads the ground state of the deal: the negotiation playbook (approved positions and fallbacks), relevant precedents from the executed-agreement library, the governing law, and any deal-specific carve-outs already agreed. This is not a warm-up — it is what makes everything downstream meaningful. An AI drafting against the wrong playbook version produces fast waste at speed.
Step 1: Specify — approved positions with refusal codes
The brief tells the AI what the output must do, what it must not do (each refusal paired with a named code), and what the after-state looks like when it succeeds.
# POSITION-SPEC — Standard SaaS Services Agreement# Playbook: v4.2 | Deal type: inbound vendor | Governing law: [jurisdiction]
MUST: - Include a limitation of liability cap at [approved floor], mutual - Include IP ownership clause assigning all work product to Company - Include data processing terms consistent with the Data Addendum template - Include termination for convenience, minimum 30-day notice - Represent the Company's approved fallback positions, not opening demands, where the counterparty has already pushed back on an item
MUST NOT: OFF-PLAYBOOK-CONCESSION — grant any position outside the approved fallback range without escalating to GC MISSING-MATERIAL-TERM — omit any term listed in the required-clause checklist for this deal type UNREVIEWED-PRECEDENT — incorporate language from a prior agreement not in the approved precedent library CONFLICTING-CLAUSE — use defined terms inconsistently within the same document or create cross-reference loops
AFTER-STATE: A draft agreement that reflects approved positions, contains all required terms, uses consistent defined terms, and has clean cross-references — ready for a human lawyer's substantive review and counterparty transmission.
ASSUMPTIONS (lowest-confidence first): ⚠ Indemnification scope: the playbook v4.2 carves out gross negligence explicitly; confirm this carve-out applies to inbound vendor deals before drafting the mutual indemnification clause. ⚠ Limitation of liability: the approved floor differs for data-breach claims; confirm whether the Data Addendum or the master agreement governs where they conflict.The human reads the flagged assumptions first. That is where the expensive misses live — not in the routine clauses but in the intersections the playbook does not fully resolve. Surfacing them before drafting costs nothing; discovering them after signing costs significantly more.
Step 2: Scenarios — the model deal, the edge, the failure
The standard deal: a routine inbound vendor agreement; the counterparty accepts standard terms with minor comments on the payment clause. The AI redlines within the approved range and leaves everything else intact — nearly automatic once the playbook is loaded.
The edge case — approved fallback: the counterparty pushes back on the limitation of liability cap. The playbook’s fallback table includes an approved band above the floor for deals above a certain contract value. This deal qualifies. The AI redlines to the approved fallback, notes the fallback in the output, and flags it for the reviewer. No escalation required.
The failure case — off-playbook escalation: the counterparty requests unlimited liability for data breaches. The playbook has no approved position for that. The AI does not draft a response. It raises OFF-PLAYBOOK-CONCESSION and escalates to counsel with a summary of what was asked, what the playbook permits, and the gap. That concession is not the AI’s to grant — and not counsel’s to grant unilaterally either.
Step 3: The frozen contract — the playbook IS the contract
In software ADD, the frozen contract is the interface definition the human approves once and the agent builds against. In legal, the negotiation playbook and its fallback table are structurally identical: a locked definition of acceptable outcomes approved by human authority before any specific deal was in play.
The playbook is the frozen contract. One gate — GC or senior counsel sign-off on positions — governs everything downstream. Any deviation from the approved range is a HARD-STOP, not a judgment call.
Revising a position follows a change-request process: business rationale, risk analysis, legal review, approval. Once approved, the new playbook version is the new frozen contract. The AI never revises the playbook on its own initiative.
Step 4: Acceptance checks — the red tests
Before the AI drafts anything, the acceptance criteria exist and are written down. A draft that does not pass all of them is not done, regardless of how polished it reads.
# CLAUSE-CHECKLIST — Standard SaaS Services Agreement (inbound vendor)# All items must pass before the draft is considered complete
REQUIRED TERMS [ ] Limitation of liability — mutual cap present, amount within approved range [ ] IP assignment — all work product assigned to Company, no carve-outs beyond the approved carve-out list [ ] Indemnification — gross negligence carve-out present per playbook v4.2 [ ] Data processing terms — Data Addendum incorporated by reference [ ] Termination for convenience — 30-day minimum notice on both sides [ ] Governing law and jurisdiction — correct for deal type
PLAYBOOK CONFORMANCE [ ] Every negotiated position traceable to playbook v4.2 or an approved fallback [ ] No OFF-PLAYBOOK-CONCESSION in the draft [ ] Fallback positions, if used, noted in the cover memo
DEFINED-TERM CONSISTENCY [ ] "Company" defined once and used consistently throughout [ ] "Services" defined once and used consistently throughout [ ] "Confidential Information" definition consistent with Data Addendum definition [ ] No term defined more than once with different meaning
CROSS-REFERENCE INTEGRITY [ ] All section references resolve to existing sections [ ] No circular dependency (Section A governs Section B which governs Section A) [ ] Data Addendum cross-references consistent with master agreement numberingA draft that fails the playbook-conformance block is not a completed draft pending review — it is an incomplete output. The checklist runs before the draft leaves the AI’s hands.
Step 5: Produce — draft and redline within the playbook
Draft the agreement so that every item on the clause checklist passes. - Do NOT grant any position outside the approved fallback range. - Do NOT omit a required term. - Do NOT introduce a defined term inconsistency. - Flag any playbook ambiguity — do not guess, escalate.The how is unconstrained: phrasing, section order, choice among approved precedent variants. The boundaries of that freedom are the playbook.
Step 6: Verify by evidence — the adversarial redline
“Reads fine” is not evidence. Verification has two parts.
Adversarial redline. The reviewer reads the draft as opposing counsel would — hunting for every concession it could argue for, every ambiguity it could exploit. This is a structured attack, not a proofread. The goal is to surface what fast-reading will not catch.
Precedent and term audit. Every clause sourced from a prior agreement gets traced to the approved precedent library. Every defined term is checked for consistency across the document, the Data Addendum, and any incorporated schedules. Cross-references are resolved mechanically.
| Ungoverned AI redline | ADD-governed redline | |
|---|---|---|
| Starting context | The AI's training data and whatever is pasted into the session | Playbook v4.2, deal-specific carve-outs, approved precedent library loaded at step 0 |
| Position authority | Whatever reads like standard market practice | Approved positions and fallback table only; off-playbook escalates |
| Definition of done | The draft looks complete and professional | Every item on the clause checklist passes |
| Verification method | Reviewer reads it and finds it reasonable | Adversarial redline + precedent trace + defined-term audit |
| Off-playbook concession | May appear; hard to detect without systematic check | Hard stop — flagged by refusal code before it enters the draft |
| Knowledge retention | Lost when the session closes | Disputes and outcomes fold into the next playbook revision |
Step 7: Observe and fold — the living playbook
Every deal produces signal. A counterparty pushes back on a clause the playbook treats as non-negotiable. A dispute surfaces a term the playbook left ambiguous. A new deal type reveals a gap in the required-clause checklist.
None of this evaporates when the deal closes. It folds into the next playbook version: the fallback table grows, the clause checklist gains a required term, the defined-term library adds an approved variant. The playbook stays living — and every AI session that loads it benefits from what the previous deal taught.
Constrain the what, free the how
The approved positions are the what: the cap range, the indemnification carve-outs, the required terms, the escalation triggers. These are clamped — the AI may not move outside them without a hard stop.
The how is wide open: phrasing, section order, choice among approved precedent variants. This is where AI drafting genuinely helps — producing clean, consistent agreements faster than a junior associate working from scratch, without the fatigue that produces subtle errors on routine work.
Clamp the outcome to the approved positions; leave the execution to the AI. Verify the result by evidence — adversarial redline plus precedent and term audit — not by reading the draft and finding it professional.
The wordplay in this series title is not accidental. ADD is contract-first as a method: it freezes the contract before building. Legal is contract-first as a subject: the contract is the deliverable. The playbook is the thing that must be right before production starts. The alignment is almost complete.
What does not transfer
The analogy is tight, but it has edges.
Legal judgment is not a checklist item. A clause can pass every conformance check and still be the wrong clause for this deal, this counterparty, and this moment. Whether to use the fallback position or to push back harder; whether an unusual term represents a red flag or routine counterparty boilerplate; whether the risk profile of this deal justifies a deviation from the playbook — these are judgments that belong to a lawyer. The checklist verifies conformance to approved positions. It does not substitute for the assessment of whether the approved positions are right for this specific situation.
Privilege does not extend to the AI. Attorney-client privilege and work-product protection attach to the lawyer’s analysis and judgment, not to AI output. Teams on matters where privilege is commercially significant need to think carefully about what they share with AI systems and where that output lives.
The playbook cannot anticipate everything. When the AI encounters a novel structure the playbook does not address, the right response is to escalate — not improvise. The value of the system is that the boundary is visible and the escalation is automatic, rather than invisible and skipped.
Over-proceduralization has costs. A playbook that requires escalation for minor variations a competent lawyer would handle without a second thought creates friction without reducing risk. The goal is to capture decisions that belong at the institutional level and leave the rest to lawyer judgment — calibrated by iterating on what actually surfaces as problems.
Next in the series
Legal is the domain where the playbook-as-contract analogy is most literal. Part 12: ADD for Compliance is where the rules are not internal positions but external mandates — and where “off-playbook” means regulatory non-compliance. The verification method changes; the loop structure does not.