An AI reviewer flags a liability clause as risky. Your lawyer reads it and asks a more useful question: risky compared with which approved position?
A contract playbook supplies that reference point. It explains what the business wants, what it can accept, and when someone with the right authority must decide.
Without those rules, a detailed review can still leave the team guessing. This guide shows how to turn negotiation policy into a practical playbook, with a reusable template and worked examples.
What Is a Contract Playbook for AI Review?
A contract playbook is an approved set of review instructions for a defined contract type and business role. It connects clause requirements, acceptable alternatives, evidence requirements, and escalation decisions.
For AI review, each instruction must be specific enough to evaluate against the agreement. “Check liability” names a topic. It does not explain what the reviewer should check.
Quick answer: Define the contract scope, write one testable rule per issue, attach approved positions and fallback language, require contract evidence, and route exceptions to named owners. Test the rules before wider use.
A Playbook, a Clause Library, and a Prompt Serve Different Purposes
| Resource | Main purpose | What it should contain |
|---|---|---|
| Clause library | Supply approved drafting language | Clause text, variants, ownership, and version |
| Contract playbook | Explain when a position applies | Conditions, preferred terms, fallbacks, and escalation |
| AI review prompt | Direct the review task | Applicable playbook, evidence format, and permitted actions |
A prompt can reference the playbook. A clause library can supply a proposed amendment. Neither replaces a decision rule explaining when that amendment is appropriate.
1. Define the Scope Before Writing Rules
Start with one repeatable workflow, such as buyer-side SaaS procurement. Record the represented party, contract family, relevant jurisdiction, transaction context, and documents included in review.
The buyer and supplier may evaluate the same clause differently. An NDA playbook also cannot answer every question in a software agreement.
Document the scope in a short header:
- Contract family: The agreement type covered by this playbook.
- Represented party: Buyer, supplier, licensor, licensee, or another defined role.
- Applicability: Relevant entities, jurisdictions, deal categories, and data use.
- Document set: Main agreement, order forms, schedules, amendments, and incorporated terms.
- Exclusions: Matters requiring a separate specialist workflow.
- Ownership: Legal owner, approver, effective date, and version.
If required context is missing, the system should ask for it or mark the review incomplete. It should not select a playbook based only on a familiar document title.
Public forms can help illustrate document structure. For example, the Common Paper Cloud Service Agreement combines a cover page with incorporated standard terms. Reviewing only one component can miss important variables.
2. Turn Negotiation Guidance Into Testable Rules
For each topic, describe the trigger, the test, and the next action. Avoid instructions such as “use reasonable terms” unless the playbook explains the relevant criteria.
Compare these two instructions:
- Too broad: “Flag unfavorable renewal terms.”
- Testable: “For this contract category, compare the renewal period and non-renewal notice window with the approved limits. Cite the source text and route deviations to procurement counsel.”
The second instruction identifies facts to extract and a decision path. Your approved limits still need to be supplied separately.
Also separate related questions. A liability rule may need distinct checks for the cap amount, fee basis, measurement period, excluded losses, exceptions, and interaction with indemnities.
One broad rule can conceal a partial result. Finding an acceptable general cap should not clear an unresolved exception elsewhere in the agreement.
3. Separate Preferred Terms, Fallbacks, and Exceptions
A useful playbook explains the negotiating range. It also identifies the point where the reviewer must stop making a recommendation within delegated authority.
| Position | Meaning | Review treatment |
|---|---|---|
| Preferred | The team's approved starting position | Identify alignment or propose approved wording |
| Permitted fallback | An alternative allowed under stated conditions | Check every condition before recommending it |
| Deviation requiring approval | Terms outside delegated authority | Explain the difference and route to the owner |
| Missing or conflicting context | Evidence is insufficient for a decision | Request documents or specialist review |
Attach conditions to fallbacks. A position allowed for a low-risk purchase may be inappropriate when the service handles sensitive information or supports a critical operation.
Keep contractual risk separate from workflow status. A finding can have a high business impact and already hold a documented exception approval. Those are different facts.
4. Require Evidence for Every Finding
Each finding should identify the applicable rule, the relevant contract text, and the reason for the classification. Reviewers need a direct path back to the source.
Require these details:
- Document name and reviewed version.
- Clause heading, section, and stable text location.
- Page number where available, plus a short exact excerpt.
- Relevant definitions and cross-references.
- Playbook rule ID and version.
- Extracted facts, classification, and recommended next action.
Keep “not found” separate from “does not exist.” A missing attachment, poor scan, or incomplete extraction can prevent the system from locating language that is present elsewhere.
Check document precedence before treating two clauses as a conflict. An amendment or order form may change the applicable position, depending on the agreement's actual wording.
For a concrete reference, Common Paper's versioned standard terms use cover-page variables and defined terms. This illustrates why isolated paragraph matching is insufficient.
5. Use This Contract Playbook Template
Create one record per review rule. Copy the fields below into your contract review system or internal spreadsheet, then replace the bracketed entries with approved instructions.
Playbook Header Template
| Field | Fill-in entry |
|---|---|
| Playbook identity | [Name, ID, version, effective date, and legal owner] |
| Contract scope | [Contract family, represented party, entities, jurisdictions, and applicable conditions] |
| Required materials | [Agreement, schedules, amendments, incorporated documents, and deal information] |
| Exclusions and authority | [Excluded matters, permitted reviewer actions, and required approval route] |
Reusable Rule Template
| Field | Fill-in entry |
|---|---|
| Rule identity | [Unique rule ID, topic, and active version] |
| Applicability trigger | [Facts that make this rule relevant; conditions that exclude it] |
| Review question | [One clearly answerable question] |
| Required facts | [Terms, numbers, definitions, and references to extract] |
| Preferred position | [Approved business position and clause-library reference] |
| Permitted fallback | [Alternative position and every condition required to use it] |
| Escalation trigger | [Deviation, missing evidence, conflict, or issue outside authority] |
| Evidence standard | [Document version, text location, excerpt, and supporting references] |
| Proposed action | [Comment, approved draft amendment, context request, or escalation] |
| Approval and exceptions | [Responsible role, required approvals, and exception record] |
| Test cases | [Examples that should pass, fail, or remain undecided] |
Store the rationale alongside the rule. A short explanation helps reviewers understand why a fallback exists and recognize situations the rule does not cover.
6. Add Worked Examples With Expected Results
The examples below use fictional buyer-side SaaS procurement rules. Their numbers and positions illustrate playbook design; they are not market benchmarks or default legal requirements.
Your legal team should set the positions for the relevant transaction and jurisdiction. The sample excerpts are original illustrations, not language taken from the linked forms.
Example 1: Provider Liability Cap
Rule ID: SAAS-LIAB-01
Review question: Does the provider's general cap meet the approved amount, fee basis, and measurement period?
Fictional policy: Prefer 24 months of fees paid or payable under the agreement. Permit 12 months only when both fallback conditions below are confirmed. Route lower caps or unclear wording to counsel.
Fallback conditions: The purchase is classified as standard-risk in the approved procurement record and processes no personal data. Missing eligibility evidence requires review.
Sample contract excerpt: “Provider's aggregate liability is limited to fees paid under the affected order during the preceding thirty days.”
Expected finding: Deviation requiring approval. The period, paid-only basis, and affected-order scope differ from the sample policy. Cite each difference rather than reporting only “low cap.”
Next action: Request the approved amendment or escalate. Assess exceptions, separate caps, and indemnities under their own rules before making an overall recommendation.
Example 2: Automatic Renewal
Rule ID: SAAS-RENEW-01
Fictional policy: Prefer renewal by agreement. A permitted fallback allows successive 12-month terms with a non-renewal notice requirement of no more than 30 days before renewal.
Sample contract excerpt: “The subscription renews for successive twelve-month terms unless Customer gives notice sixty days before renewal.”
Expected finding: Deviation requiring approval. The renewal term fits the sample fallback, but the 60-day notice requirement does not.
Next action: Propose the approved notice-period change. Check the notices clause and order form before concluding how notice must be delivered or when a deadline falls.
This example shows why passing one condition is insufficient. The fallback requires both an allowed renewal period and an allowed notice window.
Example 3: Customer Data and Model Training
Rule ID: SAAS-DATA-01
Fictional policy: Customer Content cannot be used for model training without express written authorization. Any permitted authorization follows a separately approved process involving legal and the data owner.
Sample contract excerpt: “Provider may use Service Data to improve its models.”
Expected finding: Needs context. The excerpt does not establish whether Service Data includes Customer Content, personal information, or only a narrower category of information.
Next action: Retrieve the definitions, data processing terms, relevant schedules, and precedence provisions. If the necessary documents are unavailable, keep the question unresolved and request them.
Do not invent a definition to produce a confident answer. Also distinguish using information to provide a service from permission to train a model; the applicable contract language controls the analysis.
7. Specify the AI Review Output and Human Decision
Use a consistent finding format so reviewers can compare results and understand what remains unresolved. The output should separate extracted facts, policy analysis, and proposed drafting.
Here is a compact example based on the fictional renewal clause:
| Finding field | Example output |
|---|---|
| Rule and scope | SAAS-RENEW-01; buyer-side SaaS playbook, version 1.0 |
| Evidence | Sample agreement, section 4.2; excerpt contains twelve-month renewal and sixty-day notice |
| Classification | Deviation requiring approval |
| Reason | The notice requirement exceeds the fictional 30-day fallback limit |
| Proposed action | Suggest approved notice wording after checking related provisions |
| Decision owner | Procurement counsel; final decision pending |
“Within position” should mean that the tested rule aligns with the approved playbook. It should not imply that the whole agreement is approved for signature.
Define who may approve exceptions, release redlines, and authorize execution. Keep one-deal exceptions tied to their agreement; do not automatically promote them into the general playbook.
For US legal practice, ABA Formal Opinion 512 addresses competence, confidentiality, verification, and professional judgment when using generative AI. Applicable professional duties must be assessed for the relevant jurisdiction.
Test the Playbook Before Scaling Review
Ask legal reviewers to label representative examples independently, then resolve disagreements. If reviewers interpret the same rule differently, clarify the rule before treating their decisions as an evaluation standard.
Include cases that challenge more than keyword recognition:
- Equivalent wording with different sentence structure.
- A preferred term weakened by a definition or exception.
- A missing schedule or unreadable page.
- A fallback where only some conditions are satisfied.
- Conflicting provisions with an unresolved precedence question.
- A contract outside the approved scope.
- An approved exception that applies only to one deal.
- Contract text that tries to instruct the AI reviewer.
Treat contract text as review material, not as authority to change system instructions. A sentence asking the reviewer to ignore policy should not override the playbook.
Measure missed material deviations, unsupported findings, incorrect evidence references, and reviewer corrections by clause category. Track incomplete reviews separately so they cannot inflate apparent success.
The NIST Generative AI Profile recommends evidence-based capability evaluation and verification of sources. Its guidance supports testing under conditions relevant to actual deployment rather than relying on a polished demonstration.
Keep the Playbook Current and Access Controlled
Version rules when approved positions change. Preserve the version used for each completed review, and rerun relevant evaluation cases after changes to the playbook, model, extraction process, or retrieval configuration.
Decide when an active negotiation must be rechecked under a newer policy. Document that decision instead of silently changing the basis of an earlier finding.
Restrict access to agreements and exception records. Confirm the review provider's handling of retention, training use, subprocessors, deletion, and permissions before uploading confidential material.
A lawyer's professional obligations remain relevant when a vendor supplies the tool. Tool selection and verification should reflect the task, information involved, and applicable duties.
Plan a Playbook-Based Legal Workflow With LuMay
Explore LuMay Legal Agents for governed legal workflows and document intelligence. Bring your approved positions, clause library, document types, and exception process to the design discussion.
LuMay engineering services can support a discussion about the workflow and its connected systems. Review security and governance capabilities against your access and approval requirements.
Contact LuMay to discuss a scoped pilot. Confirm the required playbook checks, evidence output, review controls, and integrations for the proposed implementation.
