Overview
This article walks you through how to turn legal guidance into a Jurist-ready playbook, validate it against sample contracts, and refine it until the results are reliable.
Jurist works best when the playbook is written in plain text, uses objective rules, and includes preferred language, acceptable variants, fallbacks, and silence instructions where applicable.
Use Case
Classics Inc. wants to speed up review of incoming vendor MSAs without requiring legal to rewrite the same clauses each time. Their legal team creates a Jurist playbook that defines their preferred positions for liability, confidentiality, governing law, and termination, along with fallback language for common negotiation scenarios. They then test the playbook against sample third-party agreements, compare Jurist’s redlines to the team’s expected edits, and refine unclear or missing rules until the output consistently reflects Classics Inc.’s standards.
What You'll Need
| Features | Jurist |
| Permissions | Group Level Permission: Jurist = Yes |
Before You Begin
We recommend gathering the source materials you want to convert into a playbook, such as existing playbooks, clause libraries, templates, and previously-negotiated agreements.
Prioritize agreement types where automation has the highest return, especially high-volume, high-risk, or shared-responsibility agreements such as NDAs, MSAs, and SOWs.
Part 1: Understand ‘AI-Ready’ Rules
Jurist requires objective, measurable commands to act as an effective thought partner. When creating your playbook, keep the following best practices in mind:
Be Specific
Be specific and avoid vague instructions such as “narrow this” or “resist that.”
- Vague: "Narrow the non-solicit."
- AI-Ready: "Narrow the non-solicitation clause to apply only to current employees engaged in the project."
Use If/Then Logic
Use If/Then logic for rules that change based on deal context (financial value, vendor type, etc.).
- Vague: “For critical suppliers, use the ‘Key Supplier’ liability cap.”
- AI-Ready: "If Supplier revenue > $10M, then use the 'Key Supplier' liability cap; otherwise, use the standard liability cap."
Absence of a Clause
If a required clause could potentially be absent, include a Silence Instruction that tells Jurist whether to insert the clause and exactly where to place it:
- Silence Example: "If no Governing Law section is present, insert the Preferred Language at the end of the 'Miscellaneous' section."
Break Complex Rules into Separate Concepts
Break complex clauses into separate concepts so Jurist can find and evaluate each one reliably, regardless of whether they appear together or in different parts of the contract.
- Example: Governing Law Breakdown
- Concept 1 (Law): State of Delaware.
- Concept 2 (Venue): Exclusive jurisdiction of federal/state courts in Delaware.
- Concept 3 (Exclusions): Exclude CISG and UCITA.
- Concept 4 (Waiver): Waiver of jury trial.
- Concept 5 (Alternative Dispute Resolution): Arbitration or other ADR.
Part 2: Create the Playbook
Note: We don’t recommend using a table format when creating your AI-ready playbook. Tables are used for illustrative purposes only.
2.1: Define the playbook’s context
Each playbook should contain an introductory section that identifies the type of agreement(s) the playbook applies to, as well as any relevant business or industry context.
Click to see an example of a playbook’s context.
MSA Playbook Sample
Agreement Type: Master Services Agreement
Applicable Product/Service: Professional and Managed Services
Industry: SaaS / Technology / Professional Services
Start the document with a short context section that tells Jurist where the playbook should be used. Include:
| Component | Required / Optional | Description | Purpose |
|---|---|---|---|
| Agreement Type | Required | Title of the agreement type the playbook applies to, along with a list of common variations (e.g. Confidentiality Agreement, NDA). | Matches the playbook to the agreement being reviewed and calibrates agreement-level expectations. |
| Applicable Product(s) or Service(s) | Optional | Brief description of the product(s) or service(s) the agreement type covers. | Provides business context that can disambiguate clauses and influence which fallbacks apply. May be inserted into placeholders regarding product/service descriptions, if applicable. |
| Industry | Optional | Brief description of the industry in which the agreement type is being used. | Provides context when interpreting ambiguous language, applying industry-specific norms, and identifying industry-specific legal risks. |
2.2: Draft each rule using the required components
Each rule in your playbook should contain all of the required components below, with as many optional components as possible.
Click to see an example of a rule.
1. Rule Name: Intellectual Property Ownership & Use of Deliverables
Priority: High
Rule Criteria: Ensure the Client owns bespoke deliverables only upon full payment, while the Company retains all rights to its pre-existing tools and methodologies.
- Ownership transfer is explicitly conditioned upon full and final payment.
- Background IP (tools/methodologies) is clearly carved out and retained by the Company.
- Use of deliverables is restricted to the Client's internal purposes only.
- Third-party distribution is prohibited without prior written consent and a non-reliance letter.
Preferred Language: “Upon Client's full and final payment, all right, title, and interest in the Deliverables shall be the exclusive property of Client and deemed a 'work made for hire.' Company retains all rights to its pre-existing intellectual property ('Company Materials'). Client agrees that Deliverables are for its internal use only and may not be publicly attributed to Company without prior written consent.”
Other Acceptable Examples:
- Example 1: "Customer shall exclusively own all right, title and interest in and to the Deliverables upon full payment of the fees and expenses. Customer agrees that the Deliverables shall only be used by Customer internally solely for its own benefit."
- Example 2: "Customer may distribute the Deliverables on a strictly confidential and non-reliance basis to their auditors, accountants, and legal advisors. Consultant does not accept any liability to any of the Authorized Recipients."
Unacceptable Examples:
- Example 1: "All deliverables and work product created under this Agreement shall be considered 'work made for hire' and shall become the sole and exclusive property of the Client from the moment of inception, including all intellectual property rights therein, and the Company hereby waives any and all claims to such work product."
- Reasoning: Transfers ownership immediately upon creation rather than conditioning it on full payment. Lacks a mandatory carve-out to protect the Company's pre-existing tools and methodologies.
Fallback 1:
- When/Why: Use when counterparty is purchasing Enterprise Solutions and requests ownership transfer without full and final payment.
- Text: “Company agrees that ownership of a specific, finalized Deliverable shall transfer to Client upon Company’s receipt of at least seventy-five percent (75%) of the total fees attributable to that specific Deliverable, as defined in the applicable Statement of Work. Notwithstanding such transfer, (i) Company retains all right, title, and interest in its Background IP; (ii) Client’s use of such Deliverables remains restricted to internal purposes only; and (iii) Client remains prohibited from third-party distribution until the total Agreement fee is paid in full.”
External Comment: "We condition ownership transfer on final payment to ensure a fair exchange of value, while the distribution restrictions are designed to protect both parties from the legal and professional risks associated with unintended third-party reliance. This approach allows us to deliver our highest-quality work product while maintaining the integrity of our proprietary background tools used across our client base."
Silence Instruction: If no Intellectual Property Ownership clause exists, insert the Preferred Language as a standalone clause after an IP-related or payment-related clause.
For each clause or issue you want Jurist to evaluate, add a rule with:
| Component | Required / Optional | Description | Purpose |
|---|---|---|---|
| Rule Name | Required | Short, high-level description of the clause concept. | Identifies which clause(s) to search for, analyze, and report on. |
| Priority | Required | Importance of the rule (e.g. High, Medium, Low). | Informs strictness of enforcement behavior (e.g. verbatim text replacement vs conceptual editing vs commenting). |
| Rule Criteria | Required | Tell Jurist “what good looks like” using 3–5 bullets. Jurist will use this list, along with the rule guidance and context. | Identifies specific components Jurist should look for and confirm are present/absent. Creates a benchmark for evaluating a clause and deciding whether/how to redline it. |
| Preferred Language | Required | The exact text of your preferred clause, verbatim. | Used as the primary insertion/replacement language when a clause deviates from your preferred position, or is missing entirely. |
| Other Acceptable Example(s) | Optional | Example(s) of other acceptable variants of your preferred language (often from previously-negotiated contracts). May contain reasoning to explain why the example(s) are acceptable. | Helps Jurist to recognize compliant language even if it differs from your preferred text, and to draft edits that match your historical tone/patterns. |
| Unacceptable Example(s) | Optional | Example(s) of language that must be rejected. May contain reasoning to explain why the example(s) are unacceptable. | Improves rejection precision by helping Jurist avoid “settling” for superficially similar but noncompliant language. |
| Fallback(s) | Required | Alternative(s) to your preferred position that may be acceptable in a specific context or permissible as a negotiation concession. Must include when/why the fallback can be offered. Add a minimum of 1-2 fallbacks. | When the preferred position is not accepted by the counterparty, or conditions indicate that a different standard should apply, Jurist selects the best alternative (based on your when/why triggers). |
| External Comment | Optional | Brief explanation to the counterparty to provide the rationale behind your preferred position. | Coming Soon: Generates a professional comment alongside the proposed redline to improve counterparty acceptance and reduce back-and-forth. |
| Silence Instruction | Optional (Highly Recommended for High-Priority Rules) | Instruction on what to do if the clause is missing entirely. | Guides Jurist to insert missing clauses (and where/when to insert them) rather than only editing existing text. |
2.3: Add fallback guidance
Fallbacks matter most when redlining third-party paper. If no fallback exists, Jurist may default to the preferred position; for first-party paper, Jurist may not apply anything or may revert to the preferred language.
In practice, it is best to include fallback language and clearly state when it should be used.
Click to see example fallback language.
”Fallback 1
- When & Why to Use: Use when the counterparty is US-based but refuses Delaware.
- Fallback Text:
- “This Agreement shall be governed by and construed in accordance with the laws of the State of New York, without regard to its conflict of law principles. The parties hereby irrevocably submit to the exclusive jurisdiction of the state and federal courts located in New York, New York.”
2.4: Format the file for Jurist
Before you upload your playbook, format your playbook using the following guidance:
- Keep the playbook in plain text format and avoid complex layouts or tables.
- Include formatting structure to indicate the start of a new section by using lists, bullet points, bold, italics, or underline.
- Spell labels consistently (e.g., Rule Name, Preferred Language).
- Replace any external links with the actual text Jurist should use.
- Make each rule self-contained rather than cross-referencing other rules or outside documents (e.g. no “See Data Policy” or hyperlinks; instead, relevant text is pasted directly into the playbook)
- Verify each high priority rule has a silence instruction.
- Export the playbook as a .docx or .pdf.
To see an example of a fully formatted playbook, refer to the attached example document located at the bottom of this article.
Warning: : Ironclad is not a law firm, and the information in this article does not constitute or contain legal advice. To evaluate the accuracy, sufficiency, or enforceability of specific contract terms, or the applicability of these materials to your business, you should consult with a licensed attorney. Use of, and access to, any of the resources contained within this site does not create an attorney–client relationship between you and Ironclad.
Part 3: Upload the Playbook
To upload your playbook:
- Open Jurist and click the Playbooks icon on the left sidebar.
- Click Add a Playbook.
- Enter a Name and Description.
- Attach the playbook. It must be in .pdf or .docx form.
- Click Add Playbook.
The playbook is added to your playbook library.
Part 4: Redline a Contract Using the Playbook
To redline a contract using the playbook you uploaded:
- In Jurist, click Redline with Playbook.
- In Jurist, click the Add files icon (+) beneath the prompt box.
- Click Playbook Files, and then click Add from Playbooks to choose the playbook you uploaded.
- Click Continue.
- Fill out the field under My party, and Contract type.
- Select your Paper source:
- Third-party: Your counterparty’s paper.
- First-party: Your organization’s standard paper.
- Click Continue.
- Select your Negotiation Stance:
- Light: Focuses on high-importance issues and makes minimal edits.
- Balanced: Default stance; enforces must-haves and key negotiables with a moderate level of redlining.
- Firm: Hard-line; redlines aggressively, often inserting preferred or fallback language verbatim and catching more deviations.
- (Optional) Click the plus icon (+) next to Additional comments to include any other notes you want the AI to know.
- (Optional) Select the option to Run Ironclad risk assessment. This will scan for risks that may be missing from your playbook.
- (Optional) Select one of two options under Prepare accompanying documents to generate alongside your contract:
- Summary of redlines
- Extracted rules from playbook
- Click Redline document. Click Playbook Files to attach your Jurist-ready playbook.
- Note: You can choose to click Add from Playbooks to reuse a playbook from your Playbook Library.
- Click Continue.
- Fill out the field under My party, and Contract type.
- Select your Paper source:
- Third-party: Your counterparty’s paper.
- First-party: Your organization’s standard paper.
- Click Continue.
- Select your Negotiation Stance:
- Light: Focuses on high-importance issues and makes minimal edits.
- Balanced: Default stance; enforces must-haves and key negotiables with a moderate level of redlining.
- Firm: Hard-line; redlines aggressively, often inserting preferred or fallback language verbatim and catching more deviations.
- (Optional) Click the plus icon (+) next to Additional comments to include any other notes you want the AI to know.
- (Optional) Select the option to Run Ironclad risk assessment. This will scan for risks that may be missing from your playbook.
- (Optional) Select one of two options under Prepare accompanying documents to generate alongside your contract:
- Summary of redlines
- Extracted rules from playbook
- Click Redline document.
Part 5: Test the Playbook
Use the following test process to validate if your playbook is functioning correctly:
Round 1: Initial verification
- Review the generated redlines and identify gaps.
- Check whether each expected issue is actually represented in the playbook.
If Jurist missed something because the rule is missing or unclear, update the playbook.
Troubleshooting: If testing results are weak, check for these common problems:
- Rules are not action-oriented enough.
- Context-dependent rules are missing clear if/then logic.
- The playbook tells a human to “accept” or “reject” instead of telling Jurist how to redline.
- Rules depend on external links, external documents, or cross-references.
- Rules are ambiguous and still require human interpretation. </aside>
Round 2: Retest and iterate
- Re-run the same contract after updates.
- Continue iterating until each actionable issue is resolved through playbook changes.
Round 3: Benchmark against a sample redline
- Ask for a customer or legal-team sample redline and compare Jurist’s output against it to assess readiness.
Round 4: Sign-off and escalate
- Once all actionable redline issues are resolved, treat the playbook as ready for sign-off.
- If the issue is already in the playbook and Jurist still misses it, log it as a technical issue for Ironclad to investigate.
Part 6: Maintain the Playbook
Continual maintenance of your playbooks ensures Jurist selects the best next step in negotiations, helping to increase deal velocity. Consider the example scenarios below:
- Scenario: You notice that your Fallback 2 for Governing Law (Texas) was accepted in 85% of last quarter's deals without a second round of redlines.
- Action: Promote Fallback 2 to Fallback 1 to reduce negotiation friction.
Result
A Jurist playbook is ready when:
- The agreement context and rules are complete.
- Rules are specific, self-contained, and formatted for plain-text processing.
- Fallbacks and silence instructions are included where needed.
- Testing shows that all actionable redline issues are resolved.
- Any remaining misses have been documented as technical issues rather than playbook gaps.