> ## Documentation Index > Fetch the complete documentation index at: https://docs.loisforword.com/llms.txt > Use this file to discover all available pages before exploring further. # Playbook Prompting > How to build effective LOIS for Word playbook rules and prompts for consistent contract review, covering rule structure, fallbacks, and test prompts. Playbook prompting is different from ad-hoc prompting. When you write a playbook rule, you're creating a reusable instruction that needs to work across many different contracts. The prompt must be specific enough to catch real issues but flexible enough to handle variations. ## The three-part rule structure Every playbook rule has three components that work as a mini workflow: ### Part 1: The rule (issue spotting) This tells the AI what to look for. It filters which clauses get attention. ### Part 2: The action (redlining guidance) This tells the AI what changes to make when it finds an issue. ### Part 3: The comment (explanation) This tells the AI how to explain the change to the counterparty. Each part builds on the previous one, creating a complete review process. ## Writing effective rules ### Be specific about what to flag The rule acts as a filter. Too broad and it catches everything. Too narrow and it misses variations. **Too broad:** "Check for problematic payment terms" **Too narrow:** "Flag if payment terms exceed exactly 45 days" **Just right:** "Flag payment terms exceeding 30 days net, including any provisions that delay payment start date" ### Use keywords that appear in contracts Reference actual contract language rather than abstract concepts: ``` Look for: "audit rights" "right to audit" "inspection rights" "review of records" Not just: "oversight provisions" ``` ### Include placement hints If the AI adds clauses in wrong places, guide it: ``` This insurance requirement should follow other liability-related provisions like indemnification or limitation of liability ``` ### Use negative scoping Tell the AI what's out of scope for this specific rule: ``` This rule covers on-site audits only. Ignore remote audits, document reviews, and financial audits. ``` ## Writing redlining guidance ### Provide exact language when possible If you have standard fallback language, include it: ``` If missing, add: "Vendor's liability shall not exceed the fees paid in the twelve (12) months preceding the claim." ``` ### Describe the concept when flexibility is needed Sometimes you want the AI to adapt to context: ``` Limit audit rights to once per year during business hours with reasonable notice ``` ### Specify the style of edit Tell the AI how to make changes: ``` Add qualifiers like "commercially reasonable" rather than deleting Insert as a separate subsection, not inline Use strikethrough and brackets, not clean changes ``` ### Include conditional logic Use if-then patterns for different scenarios: ``` If customer is government entity: Accept standard federal audit rights If commercial customer: Limit to annual audits If startup: Push back entirely ``` ## Writing comment guidance ### Remember it's a prompt, not the comment Don't write the exact comment. Write instructions for creating comments: ``` Explain this protects confidential information while allowing reasonable oversight ``` ### Include tone instructions Specify how the comment should sound: ``` Professional but firm. Emphasize business rationale, not legal theory. ``` ### Add escalation language Include when something needs human review: ``` If this is rejected, add comment: "Please escalate to legal team for discussion" ``` ## Modular rule design ### Break complex issues into multiple rules Instead of one giant liability rule, create separate rules for: * Liability caps * Liability exclusions * Super caps for certain claims * Mutual vs one-sided limitations This makes rules reusable and easier to debug. ### Create building blocks Core concepts like confidentiality appear in many contracts. Write these rules once and reuse them: * NDA playbook → confidentiality rules * MSA playbook → includes same confidentiality rules * DPA playbook → includes same confidentiality rules ### Test individual rules When a rule isn't working, you can test and fix it without affecting others. ## Common playbook patterns ### The protective rule Prevents specific unfavorable terms: ``` Rule: Must not require us to audit our subcontractors Action: Delete or limit to providing existing documentation Comment: We manage our vendor relationships independently ``` ### The requirement rule Ensures something essential is included: ``` Rule: Must include data breach notification timeline Action: If missing, add "within 72 hours of discovery" Comment: Industry standard for breach notification ``` ### The threshold rule Triggers action at certain levels: ``` Rule: Insurance requirements exceeding $5M Action: Cap at $5M unless special circumstances Comment: Aligns with our current coverage levels ``` ## Testing and refinement ### Run rules against multiple contracts Test each rule on 5-10 different contracts to ensure it: * Catches what it should * Doesn't trigger false positives * Produces appropriate redlines * Generates useful comments ### Watch for drift Rules that work today might not work after model updates. If a rule starts failing consistently, it needs revision. ### Check rule interactions Sometimes rules conflict with each other. Test the full playbook, not just individual rules. ## When playbooks work best ### Ideal for: * Standardized agreements (NDAs, DPAs, BAAs) * Routine reviews with consistent positions * High-volume contract processing * Training consistency across team members ### Less suitable for: * Highly negotiated custom agreements * Novel deal structures * Agreements where every term is negotiable * One-off strategic partnerships ## The key insight Playbook rules are different from regular prompts because they need to work reliably across many scenarios. They're not just instructions – they're codified expertise that scales your legal knowledge across every review. Think of each rule as training a permanent team member who will handle this specific issue the same way every time, across hundreds of contracts. ## Remember The goal isn't to automate everything. It's to automate the routine stuff so you can focus on what requires real legal judgment. Good playbook rules handle the 80% of issues that have standard responses, freeing you to tackle the 20% that need creativity and strategy.