Skip to main content

Playbooks

W
Written by Wilhelm Bolin
Updated over 2 months ago

1 | What is a Playbook?

A Playbook is a set of rules that automates the legal review of a specific contract type (e.g., an NDA).

When you run a Playbook, Legora scans the entire document, flags language that departs from your standards, and proposes edits that bring it back in line.


2 | How Does a Playbook Work?

  1. Review – Each rule in the playbook is evaluated independently and in parallel against the document. Deviations and potential risks are highlighted.

  2. Suggested Edits – Legora suggests text updates to align the document with your rules, which you can apply in a single click.


3 | Anatomy of a Rule

Each rule focuses on one clause or topic and contains up to four elements:

Element

Usage

Purpose

Starting Position

Review

The Starting Position refers to the the initial position that you would take if your party would draft this agreement. It represents your ideal terms and conditions.

Fallbacks

Review

(Optional, up to 3) Fallbacks are alternative contract provisions that you might be willing to accept if your Starting Position cannot be agreed upon during negotiations. They are ordered in descending order of preference (1-3), with Fallback 1 being most favorable.

Not Acceptable

Review

Language or omissions you will never accept. This is usually defined as failure to meet the conditions of the starting position or any of the fallbacks.

Example language

Suggested Edits

(Optional): If no example language is provided, Legora will suggest edits to bring the reviewed document in line with material meaning of either the Starting Position or one of the Fallback - depending on your selection.

For clauses where exact phrasing is important, Example Language lets you specify the precise wording for Legora to use in its suggested edits. This can include language from your existing templates or other ideal phrasing you want to see in your contracts. |


4 | Example rules

Simple Example – Rule: Term and Termination

  • Starting Position: The agreement shall have at least a 5-year term.

  • Fallback 1: At least a 4-year term.

  • Fallback 2: At least a 3-year term.

  • Not Acceptable: Any term shorter than 3 years.

A more sophisticated example - Rule: Duration of Confidentiality Obligations

Starting Position

The agreement must comply with the following:

  • confidentiality obligations last for at least five (5) years following termination of the agreement

  • trade secrets are protected indefinitely for so long as they qualify as trade secrets under applicable law

Example Language

Each party shall maintain the confidentiality of the Confidential Information for a period of five (5) years from the date of termination of this Agreement. Notwithstanding the foregoing, trade secrets shall be protected indefinitely, for so long as they qualify as trade secrets under applicable law.

Fallback 1

The agreement complies with the Starting Position, except that:

  • confidentiality obligations may last for three (3) years following termination of the agreement instead of five years

Fallback 2

The agreement complies with Fallback 1, with any of the following exceptions:

  • confidentiality obligations may last for two (2) years following termination of the agreement instead of three years

  • trade secrets are protected for a finite term of at least 1 year provided they qualify as trade secrets under applicable law when the agreement is signed

Not Acceptable

The agreement is not aligned with the Starting Position or any Fallback.


5 | Best Practices for Rule Drafting

5.1 Write clearly and avoid ambiguity

  • Use plain, declarative language. Complex syntax can confuse both humans and AI.

  • Never hedge. Words like “preferably,” “generally,” “where appropriate,” or “reasonable efforts” weaken the rule and cause mis‑classification.

5.2 Use bullet points to express conditions

Break multi‑part requirements into discrete bullets so each condition is evaluated independently.

Poor

  • The agreement must clearly state that neither party is legally bound to proceed with the transaction unless a definitive agreement is signed, and that either party may terminate discussions at any time and conduct business with third parties without liability.

Better

  • The agreement must state that:

    • neither party is legally bound to proceed unless a definitive agreement is signed;

    • either party may terminate discussions at any time; and

    • either party may conduct business with third parties without liability.

Tip: If a single condition contains "either/or" logic, keep the alternatives inside the same bullet.

5.3 Define Not Acceptable as failure to meet higher positions

To maximize clarity, keep the Not Acceptable section concise and definitive:

The agreement does not meet the conditions of the Starting Position or any Fallback.

This approach ensures that rules are mutually exclusive and collectively exhaustive, reducing ambiguity in classification.

5.4 Make relationships between positions explicit

A Fallback is typically relative to the Starting Position. State that relationship openly so Legora understands the baseline.

  • Ambiguous – “The agreement does not permit either party to conduct business with third parties without liability.”

  • Clear – “The agreement complies with the Starting Position, except that it does not permit either party to conduct business with third parties without liability.”

You can reference earlier fallbacks in the same way: “The agreement complies with Fallback 1, except that…”

5.5 Specify when exact wording is required

By default, Legora checks for substantially similar language—different words that preserve the same material meaning. If specific phrasing matters (e.g., regulatory terms), say so:

“The phrase “Material Adverse Change” must be included…”


6 | Rule Precedence

If a rule is formulated such that multiple positions can be true simultaneously, Legora will classify the rule based on the least favorable position that is met. For example, if the conditions for both the Starting Position and Not Acceptable are met, the rule will be classified as unacceptable.


7 | Creating and Publishing a Playbook

  1. Open Legora.

  2. Click the Legora logo in the top-left corner to go to the home screen.

  3. Navigate to Playbooks via the side-bar.

  4. In the top-right, click New Playbook

  5. Add rules to your Playbook:

    • Fill in the Starting Position (and Example Language, if helpful).

    • Define up to three Fallbacks.

    • Specify what is Not Acceptable.

  6. Your work is automatically saved as a private draft.

  7. Sharing with others:

    • You can share your Playbook with teammates or groups to keep everyone aligned.

    • However, a Playbook must be published before others can see it — shared drafts that have never been published remain visible to you only.

  8. Publishing:

    • When ready, click Publish (top-right) to:

      1. Save a new version.

      2. Make it visible in the Word Add-in for all authorized users.

      3. Ensure this version is displayed and used in the app.

    • To allow you to draft in private only published versions are visible to others — edits made to a published Playbook remain private until you click Publish Changes.


8 | Locating Playbooks (Word Add-in)

  1. Launch the Word Add-in.

  2. In the bottom-left panel, select Playbook.

  3. Browse, select and run any Playbook you have access to.

  4. Select the party you represent.

  5. Click Run Playbook.

Note: The team at Legora have created example playbooks available to all users you can use or reference as a base for further customization.


9 | Reviewing & Accepting Suggestions

If you…

Do this…

Agree with an individual suggestion

Click Suggest Edits to apply.

Want to generate suggested edits for all rules

Click Suggest all edits at the bottom of the Playbook

Prefer visible markup

Choose Redlines and Comments when

Accept everything

Click Accept All.


10 | Tips & Best Practices

  • Version Notes – Add brief notes to each version to remind the team what changed and why.

  • Publish Early & Often – After significant changes, publish so others don’t rely on outdated rules.

Did this answer your question?