> For the complete documentation index, see [llms.txt](https://help.jurisphere.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.jurisphere.ai/jurisphere-word-add-in/core-features/review-playbook/building-review-playbooks.md).
# Building Review Playbooks
The full rule anatomy behind a Review Playbook - starting positions, fallbacks, dealbreakers and example language.
## Overview
Creating a Review Playbook will let you turn your team's actual negotiated standard for a contract type into the structured set of rules Jurisphere evaluates a document against.
Building happens on the **Jurisphere web platform**, not inside Word. Once built, a Playbook simply becomes available to run in the Word Add-In, which is covered separately in [Running Review Playbooks](/jurisphere-word-add-in/core-features/review-playbook/running-review-playbooks.md).
***
## Review Playbooks Section under Workflows
{% stepper %}
{% step %}
### Open Workflkows
From the sidebar on the Jurisphere web platform, select **Workflows**.
{% endstep %}
{% step %}
### Select Review Playbooks
Navigate to Review Playbooks from top left sections, next to Skills.
{% endstep %}
{% step %}
### Create a New Review Playbook
Click to build a new Review Playbook towards the top right and choose one of the two creation paths covered below.
{% endstep %}
{% endstepper %}
***
## Choosing how to create your Playbook
{% tabs %}
{% tab title="Import" %}
If you already have a precedent, policy document or standard form agreement your team relies upon, let Jurisphere use it to generate most of the Playbook for you rather than starting from a blank rule list.
For more instructions on how to proceed, see [extract of a review playbook from the document](#extract-a-review-playbook-from-a-document) below.
{% hint style="success" %}
Generating from a document is typically the more efficient starting point if your team already has a standard form agreement or negotiation playbook. It requires less effort to edit a reasonable first draft than to write every rule from scratch.
{% endhint %}
{% endtab %}
{% tab title="Start from Scratch" %}
Create each review rule yourself, one at a time. This is the right choice when you already know exactly what your team's positions are and want full control over how each one is phrased.
Start with the basics:
* **Name:** Give the Playbook a clear, descriptive name. For example: *Employment Agreement Review Playbook.*
* **Description:** A short explanation of what type of document the Playbook is designed to review.
* **Tags:** Optional labels that make the Playbook easier to find later, especially once your team has several.
* **Review Rules:** Review each rule one by one, select each rule to be between mandatory, recommended and nice to have. See [anatomy of a review rule](#anatomy-of-a-review-rule) below for what each rule may require.
{% endtab %}
{% endtabs %}
### Extract a Review Playbook from a Document
{% stepper %}
{% step %}
### Select Import from a File
You can choose this creation path when you have a precedent, policy document, standard draft, etc that the team refers to.
{% endstep %}
{% step %}
### Upload or select your source document
You can upload a new file or select one from your library using the “import from library” option. Then simply click on "proceed".
{% hint style="warning" %}
You can upload or select a PDF or DOCX file up to 50MB in size.
{% endhint %}
{% endstep %}
{% step %}
### Let Jurisphere analyze it
Jurisphere analyzes the document and generates a full first draft of suggested review rules, including:
* Rule names
* Applicability conditions
* Starting positions
* Fallback positions
* Dealbreaker positions
* Example language
* Other relevant review details
{% endstep %}
{% step %}
### Review and edit what was generated
Every generated rule is **fully editable.** Nothing here is final until you say so. Modify any rule, adjust wording, tighten or loosen a fallback, change a priority level or delete a rule that does not apply to how your team actually works.
Treat the generated draft the way you would treat a drafted memo from a junior, which would be a useful starting point, not a finished product to publish unread.
{% endstep %}
{% endstepper %}
***
## Anatomy of a review rule
Regardless of the creation path, every rule in a Review Playbook is constructed from the same set of fields. It is recommeded to review them prior to creating a Review Playbook.
| Fields | Description | Example |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
Rule Title
| A clear name describing what is being reviewed. | *Non-Compete Clause* |
|
Applicability Condition
(optional)
| Use this when a rule should only apply if a particular condition exists in the document. | *If the agreement contains a post termination non compete restriction.* |
|
Starting Position
| Your preferred, ideal position for the clause. What you would ask for if you could get exactly what you wanted. | *The employee should not engage in a competing business in India for 6 months after termination.* |
|
Fallback Positions
| If the starting position cannot be achieved, define one or more acceptable alternatives. You can add as many as you need, effectively creating a ranked hierarchy of acceptable outcomes. |
(First fallback): Limit the restriction to the company's key clients or core business activities.
(Additional fallback): A 3 month restriction may be acceptable where justified by the employee's role.
|
|
Dealbreaker Position
| Define outcomes that should always be flagged, regardless of context. This would outline your hard lines. | *A non-compete restriction of only 1 month is not acceptable.* |
|
Rule Priority
|
Finally, mark the rule as one of three levels:
Mandatory
Recommended
Nice to Have: Worth raising, but low stakes if it does not get resolved.
| |
Repeat this process to add as many rules as your Playbook needs. For example, a thorough Employment Agreement Playbook might reasonably include separate rules for non-compete restrictions, notice periods, confidentiality survival, leave entitlements, IP assignment and governing law, each with its own starting position, fallbacks and priority levels.
***
### Worked examples across contract types
{% tabs %}
{% tab title="NDA Playbook" %}
**Example Rule:** Confidentiality Survival Period
* **Starting Position:** *Confidentiality obligations survive for 5 years after termination, and indefinitely for trade secrets.*
* **Example Language**: *The obligations of confidentiality under this Agreement shall survive for a period of five (5) years from the date of termination or expiry of this Agreement, provided that with respect to Trade Secrets, such obligations shall survive for so long as the relevant information remains a trade secret under applicable law.*
* **Applicability Condition:** *If the agreement specifies a fixed survival period for confidentiality obligations after termination.*
* **Fallback Positions:** *A 3 year survival period is acceptable for non-trade-secret information.*
* **Dealbreaker Position:** *A survival period of less than 1 year, or no carve-out at all for trade secrets.*
* **Priority:** Mandatory
{% endtab %}
{% tab title="MSA Playbook" %}
**Example Rule:** Limitation of Liability Cap
* **Starting Position:** *Aggregate liability is capped at 12 months' fees paid under the agreement, with carve outs for fraud, gross negligence, willful misconduct and breach of confidentiality.*
* **Example Language**: *Except in respect of fraud, gross negligence, willful misconduct or breach of confidentiality, in no event shall either party's aggregate liability arising out of or in connection with this Agreement exceed the total fees paid or payable under this Agreement in the twelve (12) months preceding the claim.*
* **Fallback Positions:** *A cap of 24 months' fees is acceptable if the counterparty insists, provided the same carve outs remain in place.*
* **Dealbreaker Position:** *Uncapped liability, or a cap with no carve-outs for fraud or willful misconduct.*
* **Priority:** Mandatory
{% endtab %}
{% tab title="Lease Playbook" %}
**Example** **Rule:** Security Deposit
* **Starting Position:** *Security deposit equal to 3 months' rent, refundable within 30 days of lease expiry subject to deductions for damage beyond normal wear and tear.*
* **Example Language**: *Tenant shall deposit with Landlord a sum equal to two months' rent as security, which shall be refunded within thirty days of the expiry or termination of this Lease, less any deductions for damage beyond normal wear and tear.*
* **Fallback Positions:** *A deposit of up to 6 months' rent is acceptable for a longer lease term (5+ years); a 60-day refund window is acceptable if the landlord is a large institutional entity.*
* **Dealbreaker Position:** *A non-refundable deposit or no defined timeline for refund.*
* **Priority:** Mandatory
{% endtab %}
{% endtabs %}
***
Review Playbook
The conceptual overview on what a Playbook is and when to reach for one instead of a Skill.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://help.jurisphere.ai/jurisphere-word-add-in/core-features/review-playbook/building-review-playbooks.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
