Creating a playbook

A playbook is your team’s reusable review template. It’s a set of plain-English instructions that tell Clment AI:

• Which clauses to look for in a contract.
• What your standard / desired position is for each.
• What language to recommend when a clause falls short.

Once a playbook is published you can run it against any uploaded contract — the AI uses it as the reference standard during review.

Creating one

1. Playbooks in the sidebar → + New playbook.
2. Name + description — the description matters for picking the right playbook later, especially when your team has several.
3. Instructions — the body of the playbook. Plain English; structure it however helps you (we’d suggest grouping by clause type).
4. Save as draft to iterate, or Publish when you’re ready to use it on real reviews.

Drafts can be edited freely; only published playbooks appear in the Review with playbook picker.

Versioning

Publishing a playbook creates v1. Edits to a published playbook create a new draft revision; publishing again becomes v2. Existing reviews stay locked to the version they were started against — a review started yesterday with v1 still uses v1’s instructions even after you publish v2.

This is important: editing a playbook NEVER changes the findings of an already-run review. To re-review with the new version, start a fresh review on the same contract.

What good instructions look like

The AI is a strong reader. You don’t need a structured schema, XML tags, or rigid clause-by-clause headings — write the way you’d brief a new junior reviewer who’s smart but doesn’t know your house preferences yet.

What works well:

• Specifics over generalities. “Limit of liability should be capped at 12 months’ fees, 24 months preferred. Carve-outs for breach of confidentiality, IP infringement, gross negligence — uncapped.” is much more useful than “liability should be reasonable.”
• House language verbatim. If you have standard wording you want suggested in redlines, include it. The AI will use it verbatim when it recommends a change.
• What to ignore. Saying “30-day, 60-day, 90-day notice periods are all fine — only flag if no notice mechanism” stops the AI flagging variations you don’t care about.
• The reasoning, not just the rule. “We push back on auto-renewal because finance hates surprise renewals” gives the AI context to apply the rule sensibly in cases you didn’t anticipate.

What works less well:

• Vague positions. “Indemnity should be reasonable and customary” tells the AI to guess what you mean. Findings get vague to match.
• Very legalistic phrasing. “A Material Adverse Effect within the meaning of …” sometimes confuses the AI. Plain English does better.
• Placeholders in suggested wording. If you include a draft clause with “[X] months”, the AI may leave the placeholder in. Use a real default and a note about how to vary it.

Iterating

You’ll get the most out of a playbook by editing it after running a few reviews:

• A finding that wasn’t really an issue? Add a line to the playbook telling the AI to accept that variant.
• A clause the AI missed? Be more explicit about what to look for.
• A redline that didn’t match your house style? Include the preferred wording in the playbook.

A playbook gets sharper over the first 5–10 reviews. After that it tends to stabilise.

One playbook per family

Most teams end up with one playbook per contract family — vendor, customer, NDA, employment, distribution, etc. Trying to make one playbook handle every contract type makes the instructions long and unfocused; small, specific playbooks produce more useful findings.

See also

• Reviewing contracts
• Understanding finding verdicts
• Generating redlines