Building Playbooks in PlaybookOS | The Self-Service Guide (3rd Party Paper)

Navigation

From the DocJuris dashboard, click the orange + Create a Playbook button.

Fill in Playbook Details

You'll need to give it a title (required), optionally add a description, and specify the contract type. For training or demos, include your name in the title so the playbook is easy to identify later.

• Title: Give your playbook a clear, descriptive name. For testing, use something unique (e.g., Josh – DIY Lab Services Agreement) so it's easy to find later.
• Description: (Optional) Briefly explain the purpose of this playbook.
• Contract Type: Select the contract type this playbook will be used for (e.g., MSA, NDA, Software License).

Click Create to open the playbook editor. You will now see an empty playbook ready for topics.

Within the Topics tab, click "Add Topic" to start building.

Complete Topic Details

Each topic represents a contract provision you want to monitor, like Client Payment or Trademarks. You'll enter a title (specific provision name) and a description (business rationale or reference to the template clause).

• Title: Choose a clear, actionable name (e.g., "Client Payment Terms").
• Description: 2–4 sentences on why this topic matters. (e.g., "Ensures timely payment of invoices and survival of payment obligations post-termination.")

Organize with Categories

Categories let you group related topics (e.g., Finance, Risk, Termination) so reviewers can navigate the task list more efficiently. To assign a category, select one from the dropdown — or click Create Category if the one you need doesn't exist yet.

Click the orange Save Changes to create the topic.

Scroll down to Search Criteria and click + Add Search Criteria.

Choose Your Criteria Type:

Select PROMPT as your criteria type. This lets you write a natural language instruction to teach AI what to look for — it's the recommended approach for building playbooks.

You may also see Terms & Connectors in the criteria type dropdown. This is a legacy search method carried over from v1 playbooks. If you're already familiar with boolean/proximity search and prefer that approach, see Terms & Connectors in PbOS.

MUST, MAY, and MUST NOT

Every criterion is wrapped in an operation that defines how it influences the search. Your first criterion should always be a MUST — this is the foundation that tells the AI what to look for. Without it, the search has nothing to anchor to.

MUST (Required) — The clause must satisfy this criterion to be considered relevant. Always start here.

Once you have a MUST in place, you can layer on supplemental operations to fine-tune your results:

MAY (Supplemental) — The clause may meet one or more optional criteria. Use this to broaden your search without making additional conditions mandatory.

MUST NOT (Supplemental) — Excludes clauses you don't want flagged, even if they match other criteria. Use this to filter out false positives.

Analyze Clauses

Before writing your prompt, you'll also see an Analyze Clauses dropdown. This controls how the AI reads the contract text when evaluating your search criteria. The two options are:

• As marked up (i.e., track changes accepted) — The AI reads the contract with all redlines accepted, seeing only the latest version of each clause.
• Before any markups (i.e., track changes rejected) — The AI reads the original contract text, ignoring any redlines or edits.

Generally, "Before any markups" should be selected for topic prompts in third-party paper playbooks. Otherwise, on later review rounds the prompt may match the parties' subsequent markups rather than the original contract language.

Example: AI Search Prompt

Below is what a prompt looks like inside the AI search criteria box. Write your prompt as a complete instruction — the AI needs to know what to look for and where to look.

Notice the prompt reads as a single, natural instruction — not a list of keywords. The AI performs best when you describe what you're looking for in plain language, the same way you'd explain it to a colleague.

Click Save Changes to store your criteria.

Basic Topic Structure: Found / Not Found

Every topic has two core outcomes: what happens when the AI finds relevant language in the contract (When Topic is Found), and what happens when it doesn't (When Topic is Not Found). This simple binary structure is the foundation of every playbook topic and is all most users need to get started.

For example, consider an Indemnification topic:

• Found → Review: The contract contains indemnification language. Assign a Review action with commentary guiding the reviewer on what to check for (e.g., "Confirm mutual indemnification and verify carve-outs align with policy.").
• Not Found → Add: The contract is missing an indemnification clause entirely. Assign an Add action that instructs the reviewer to insert a satisfactory indemnification clause.

Click When Topic is Found to open the outcome editor.

• Action: Select what to do if the topic is found (Accept, Review, Edit, Escalate, Proceed, etc.). For a full breakdown of each action type, see Understanding Tasks in DocJuris.

  

• Explanation: Briefly state why this action matters (e.g., "All required payment terms found — confirm alignment with policy.").

  

• Scenarios (Optional): The system defaults to create a single "base" scenario to reflect the position, with no action required by the user to create the first scenario with all fields shown. Optionally, you can add additional scenarios to handle different variations of a clause within the same found or not-found outcome. Each scenario can include its own clause examples, markup instructions, and commentary — giving you the depth to cover multiple negotiation paths without adding complexity to your playbook structure.

  

• Commentary: Add internal commentary (guidance for your team). Internal commentary can be as brief or as detailed as your team prefers — the commentary may elaborate on your legal positions, offer relevant citations, provide escalation instructions, or advise on negotiating tactics.

Writing AI Drafting Instructions

In addition to telling the AI what to search for, you can also tell it how to redline the clause it finds. This is done through AI Instructions inside your outcome — and it's one of the most powerful parts of a playbook.

Think of AI drafting instructions the way you'd explain a redline to someone who will follow your directions exactly — and only your directions. If you tell the system to "replace with 60 days" but don't tell it to delete the existing number first, it may insert the new text alongside the old. Be specific about every step: what to find within the clause, what to remove, and what to insert in its place.

Notice how the instruction breaks the redline into discrete steps — what to look for, what to delete, what to replace, and what to add. The more granular your instructions, the more reliable the AI's markup will be. Avoid dropping in an entire clause and expecting the system to figure out what changed — instead, describe the edits the same way you'd narrate them to a colleague who has never seen the contract before.

Repeat the process under When Topic is Not Found to define what should happen if no relevant language is found (e.g., Escalate, Add, Reject).

This is where AI really shines — use AI Instructions to pre-write redlines or insertions that the system can apply automatically.

Click "Add Clause Example" to insert sample language (preferred, fallback, or alternative) directly into the playbook. These examples come from your contract templates or import sheets and give reviewers ready-to-use, context-rich options during negotiations.

Click + Add Clause Example and insert sample language from your template or precedent.

Provide a title and select a classification (Favorable, Neutral, Fallback, etc.).

Clause examples serve as guidance for reviewers and training data for AI-generated markups.

Clause examples can also be inserted into the contract verbatim via the + Click and Drop feature — for example, when a concept is missing and a user wants to add a standard clause, or in a situation when it is preferable to counter-propose a standard clause in response to counterparty text.

Once your topic is saved, the real test begins. A playbook only proves its value when it can reliably detect the right language inside real contracts. That's why the next step is to run your topic against sample agreements.

When you test, you're looking for three things:

• Coverage – Does the topic consistently catch all of the relevant clauses, without overlooking important variations?
• Precision – Does it avoid surfacing irrelevant hits that would distract reviewers or slow them down?
• Clarity – Do the tasks generated from the outcomes give reviewers clear, actionable guidance on what to do next?

This stage is less about getting it perfect on the first try and more about shaping your topic until it reflects the reality of your deals. You might find that a search prompt is too narrow, missing language you expected. Or perhaps it's too broad, pulling in paragraphs that don't matter. Both are normal, and the fix is simple: iterate.

That means refining prompts, adjusting outcomes, and—where helpful—adding example clauses or alternative scenarios. Think of this step as sanding down the edges: you already have the framework in place, but now you're making sure it runs smoothly in practice. A few cycles of review and refinement will leave you with a topic that feels both sharp and practical—one that your reviewers can trust to surface the right issues and guide them toward the right decisions.

With one topic complete and validated, the process is the same for the rest of your playbook. Continue by applying the same structured approach to each area of risk or business concern you want covered.

A good way to proceed is to prioritize the essentials first — for example, provisions like governing law, indemnification, or limitation of liability that appear in almost every agreement. Once those are set, move on to more specialized areas such as insurance requirements, service levels, or data protection obligations that may only surface in certain types of contracts.

Each topic you add builds on the last, and as your playbook grows, the system will generate more tailored tasks and guidance for your team. By moving step by step through the most common to the more specific, you'll gradually create a complete negotiation framework that fits both your contracts and your organization's risk profile.

Once you've built several topics, it's time to validate the playbook as a whole by running it against a live contract in the Analyzer. This is where all of the pieces you've created — criteria, outcomes, positions, and scenarios — come together in practice.

When you load a contract into the Analyzer with your playbook applied, start by checking that the number of tasks generated matches the number of topics in your playbook. A missing task usually means a topic's search criteria didn't find a match — and unless you're counting, it's easy to overlook. Once you've confirmed full coverage, review carefully to ensure the AI is behaving as expected:

• Task Generation: Confirm that the AI surfaces tasks for each relevant provision and that no critical clauses are being missed.
• Color-Coded Actions: Check that the actions (Accept, Edit, Add, Reject, Escalate, etc.) are correctly labeled and easy for reviewers to interpret at a glance.
• Scenarios and Positions: Open tasks that use scenarios or positions to make sure the guidance and clause options provide enough context. Reviewers should feel equipped to either follow the playbook's instructions directly or make an informed decision when nuance is required.

Testing end-to-end helps you spot gaps — whether in overly broad search criteria, missing fallback language, or unclear explanations. Adjust and refine as needed, then re-run until the results consistently match your team's negotiation objectives.

Once your playbook is finalized, the final step is to make it available to your team and ensure that everyone who needs it can actually use it. Publishing a playbook turns it from a draft into a live resource in the Analyzer, allowing it to generate tasks, outcomes, and suggested redlines in real contract reviews.

But publishing alone isn't enough — you'll also want to confirm that Business and Legal users who rely on the playbook have access to it. This is managed in the Members & Privacy tab within each playbook. From here, playbook creators or admins can grant access to other team members, ensuring that the right people can apply the playbook during review. Without this step, the playbook may be live but unavailable to the reviewers who need it most.

After publishing and assigning access, it's time to train your reviewers. Training is critical because PlaybookOS introduces structured decision-making, contextual commentary, and AI support that may be new even to experienced attorneys or procurement professionals.

Key areas to cover in training include:

Interpreting Tasks

Reviewers should learn how tasks are generated and what the color-coded actions mean. Walk through how explanations and commentary provide reasoning for each action, helping reviewers make confident, consistent decisions.

Following Commentary

Clarify the difference between internal commentary (guidance only for your team) and external commentary (negotiation-ready language to share with counterparties). Reviewers should understand how to use each appropriately.

Using AI-Powered Markups

Show how to leverage Generate Markups to apply AI-driven edits that align with playbook guidance. Stress that while AI can accelerate redlines, reviewers remain the final decision-makers.

Using Clause Examples & Click-and-Drop

Walk reviewers through the clause library available within each task. If your playbook includes clause examples, reviewers can use the click-and-drop button to insert pre-approved language directly into the contract — no AI drafting required. This is especially important for Add tasks where the clause doesn't exist yet, and for any situation where the reviewer needs the exact language as drafted rather than an AI-generated version.

Finally, encourage reviewers to give feedback after their first few uses. These early insights can help refine prompts, outcomes, and clause examples to improve accuracy and usability over time.