Setting up AI Review playbooks

On your own paper (first-party), the review runs natively in Juro. You've sent out a document built from your own template and the counterparty has redlined it, so the Agent reviews only those redlines — the changes they've suggested — against your playbook, and tells you which are acceptable and which aren't. It doesn't touch the rest of the document, because there's no reason to redline your own template against yourself. You run it from the External Comments tab once their suggestions come back.

On a counterparty's paper (third-party), the review runs in Word through Juro's Word plug-in. The document is someone else's, so there's no template of yours to compare against — the Agent reviews the whole document against your playbook and generates suggested redlines wherever the terms don't match your positions, broken out by priority. You then approve or reject each suggestion in Word before sending the document back.

Rule name — what the Agent uses to match the rule to the right part of the document.

Priority ranking — a slider (low / medium / high) that groups results for triage.

Acceptable position — what you're happy to see.

Unacceptable position — what you're not.

Be descriptive, but broad. A good test: someone who knew nothing about the contract should be able to tell, from the name alone, which part of the document the rule applies to.

Avoid niche, single-term names. If a concept can be expressed several ways, list the alternatives rather than betting on one — for example Assignment / novation / transfer rather than just Novation. Broadening the name broadens what the rule catches.

Keep instructions out of the name. It's used only for matching, never to shape the redline itself, so there's no value in phrasing it as an instruction.

Don't go too broad, either. A sweeping name — something like "Obligations" — can cause the rule to fire in places you didn't intend. Aim for a name that's broad enough to catch the concept however it's worded, but specific enough to point at one part of the document.

'Limitation of liability / liability cap'

'Auto-renewal / automatic extension'

'Indemnification / hold harmless'

Define both positions. A rule works best when it knows what's acceptable and what isn't. You can leave the unacceptable position empty, but if something falls outside everything you've described, the rule may simply not react. (For a PHI rule, for instance: acceptable = "no mention of protected health information"; unacceptable = "protected health information is included".)

Cover the range, not just a point. Don't write "12 months" — write "12 months or longer", and mark "anything shorter than 12 months" as unacceptable, so the edge cases are handled.

Keep it black and white. Avoid soft qualifiers like "especially" or "conditional upon". Clear-cut positions produce far more predictable results.

Use plain, natural language. Write the positions as you'd brief a colleague who isn't familiar with your review process. Don't pack them with justification or step-by-step instructions — that tends to degrade how accurately the Agent assesses the position.

Describe the position, not the edit. State what a good clause looks like, not the redline you'd make. Write acceptable = "a clear disclaimer of warranty is present" rather than "remove the warranty disclaimer" — instruction-style wording confuses the assessment.

For verbatim wording, say so explicitly. This is one of the few times it's right to be prescriptive. If a clause must contain exact language — for a regulatory requirement, or a clause counterparties often leave out (a no-warranty section, say) — put the wording in quotation marks and state that it must match exactly. Otherwise the Agent uses its own discretion on the phrasing.

Mind differently-worded terms. If your rule describes, say, "presumed confidentiality, no marking required" but the document expresses the same idea in different words, it can be missed. Broaden the name (for example Confidentiality scope) and describe the position in natural language so the concept is recognised however it's written.

First-party vs third-party matching. A single playbook can be pointed at both workflows, but what you'd redline on your own template differs from what you'd flag on someone else's document, so the positions usually diverge enough that separate playbooks work better.

No conditional rules yet. Because rules can't be made conditional, materially different document types generally need their own playbooks — a client NDA versus an M&A NDA, for example, or a short facility-visit NDA versus a customer or vendor one. Commercial agreements are more likely to need distinct playbooks than NDAs.

Coverage strategy differs by direction. On your own paper, teams tend to build broader playbooks before going live, especially where a frontline sales team will run reviews — you don't want a rep to run it, hit a gap, and have a change wave through unflagged. On counterparty paper, it's usually better to start with just a few rules and grow: AI Review runs alongside your manual review and takes nothing away, so even a couple of rules already saves time.

Publish and unpublish. A published playbook can be used in reviews; unpublish it to make changes, then republish. You can open a playbook from the Playbook hub, or from within a review (via the playbook link when you reopen the previous review cycle) to tweak it in context.

Copying between playbooks. You can't copy rules from one playbook into another yet, so you'll need to recreate them. Uploading an existing playbook document is the fastest way to seed a new one.

A rule isn't firing — the name is probably too narrow. Broaden it and add alternative terms.

A rule fires where it shouldn't — the name is too broad. Tighten it toward the specific part of the document.

A differently-worded term is missed — broaden the name and describe the positions in natural language rather than exact phrasing.

A document-wide characteristic is missed — traits that run through the whole document (whether an NDA is mutual, for instance) are harder to catch than a single clause. Describe them in the rule as best you can, and always human-check these points.