TL;DR
Review against your own rules instead of general legal knowledge. The playbook is the standard, so its structure decides the quality of every answer.
Structure, mostly. A playbook that already lives in a spreadsheet can be imported as rules. One written as prose has to be interpreted first — and every ambiguity in the prose becomes an ambiguity in every review that follows.
This is the least glamorous part of a contract-review project and the part that decides whether it works.
Why does the playbook decide the quality of the review?
Because it is the standard the contract is measured against. Not general legal knowledge — yours.
A model that has read a great deal of contract law can tell you a liability cap is unusual. It cannot tell you it breaches your policy, because it has never seen your policy. The playbook is what converts a general capability into a judgement about your organisation.
So the causal chain is short and unforgiving:
Vague rule → vague finding → a reviewer who stops trusting the flags → a system nobody uses.
The failure mode is not a wrong answer. It is an unusable one. A flag that says "this clause may present risk" costs a reviewer the same time as reading the clause themselves, which means it has achieved nothing.
What does a usable rule actually contain?
Four parts. A rule missing any of them produces weaker output, and the fourth is the one most playbooks leave implicit:
| Part | Why it matters |
|---|---|
| The position we want | The standard ask, stated as a term rather than a principle |
| What we will accept | The fallback. Without it, every deviation looks equally bad |
| The red line | What we will not sign. This is what makes a finding actionable rather than informational |
| Why | The reason behind the rule |
That fourth column is the one worth arguing for. A rule with a reason attached lets the review explain why a clause is a problem, and an explanation is what a counterparty can negotiate against. A rule without one produces a finding that says no and cannot say because.
Paralegent AI — our contract-review app in Cognilium's family of AI optimization apps for Microsoft Dynamics 365 — extracts these into structured terms and those terms become what every contract is scored against. The extraction is only as good as what is there to extract. We build these against a customer's own playbook, which is why this article is about yours rather than our model.
Does it matter whether the playbook is a spreadsheet or a document?
Yes, and more than people expect.
A playbook that is already a table — one row per rule, columns for position, fallback and red line — is already structured. It imports as rules directly. Nothing has to be inferred, so nothing can be inferred wrongly.
A playbook in prose is a different job. It has to be read, chunked, and interpreted into rules before any contract is reviewed at all. That step is reliable but it is not free, and it inherits every imprecision in the original: a paragraph that says "we generally seek to limit liability where commercially reasonable" becomes a rule that says approximately that, which is not a rule.
The practical advice, and it costs nothing to follow: before evaluating any product in this category, put your playbook in a spreadsheet. Not because software demands it — because the act of writing one rule per row forces you to discover which of your rules are actually rules and which are habits.
Teams routinely find, doing this, that two people have been applying different fallbacks for years. That discovery is worth more than the review system.
What if we don't have a playbook at all?
Then the honest answer is that you have one — it is just undocumented, living in the heads of two or three people who have reviewed the most contracts.
Building it is not a legal project so much as a transcription one. Take the last twenty agreements you negotiated, look at what actually changed between the first draft and the signed version, and the pattern in those edits is your playbook. You have been applying it. It has simply never been written down.
Do not start this by buying software. A documented playbook makes every future system better — review, training, onboarding, audit — and it is the one investment that is not wasted if you never build anything.
How often does it change once it exists?
Less than people fear, and the changes cluster. Rules move when a regulation moves, when an incident happens, or when a negotiation sets a precedent someone decides to keep.
What matters is that a change is a change to the rule, not to a review. If updating a position means editing one row and re-running, the playbook is a living document. If it means asking someone to remember a new exception, it is decoration.
Version it like configuration, because that is what it is — and because when a term is challenged in eighteen months, the useful question is which version of our policy was in force when we signed.
That question has an answer on the ERP side too. Confirming a purchase agreement in Dynamics 365 stores "the current version of the purchase agreement… in a history table", and every version can be printed. Your playbook deserves the same treatment as the agreement it produces — one is the rule, the other is the outcome, and neither is much use without a date attached.
About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/
Legal AI Ops. We transform legal workflows with agentic AI, copilots, agentic workflows and decision intelligence — built into core workflows rather than beside them, to raise productivity and cut operational overhead. Contract Review Copilot is the contract-review app in that family. It ships as Paralegent AI, in production today. How we build Legal AI Ops — custom AI capabilities on top of legal work, against your playbook and your Dynamics 365.
Want a second opinion on whether your playbook is ready to be used this way? Bring it to a 15-minute call — that conversation is useful whether or not you build anything.
Sources
Sources and fact-check
| # | § | Claim | Tier | Source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | The playbook is the standard the contract is measured against | T2 — capability, describing our own product's design | Paralegant_TECHNICAL_PROFILE.md §1, §4.1 | PASS |
| 2 | 1 | A general model cannot judge against your policy without it | T2 — ours, an argument | Internal definition | PASS |
| 3 | 2 | The four parts of a usable rule | T2 — ours. Stated as our position on rule design, not as a standard anyone else publishes | Internal definition | PASS |
| 4 | 2 | Paralegent AI extracts rules into structured terms | T2 — capability | Same profile, §4.1 | PASS |
| 5 | 3 | A structured playbook imports without interpretation; prose must be interpreted first | T2 — capability, and it is architectural: the profile documents deterministic parsing for structured input and a model-driven path for documents | Same profile, §4.1 | PASS |
| 6 | 3 | Teams discover reviewers applying different fallbacks | T2 — ours, and deliberately unquantified. No count, no client, no measured claim | Internal definition | PASS |
| 7 | 4 | An undocumented playbook is visible in the edits between draft and signed versions | T2 — ours, advice | Internal definition | PASS |
| 8 | 5 | Version the playbook like configuration | T2 — ours | Same profile, §5.9 dynamic playbook configuration | PASS |
| 9 | 5 | Confirming a purchase agreement stores a version in a history table | T1 — verbatim | purchase-agreements, Confirmations and version history, fetched 2026-09-10 | PASS |
Tier summary: 1 × T1 (verbatim), 8 × T2 — 0 × T4.
This article is entirely T2 by design, and that is correct for its subject. It is advice about the reader's own preparation, not a claim about a vendor's product behaviour. Where it describes Paralegent AI it describes design, not results — no throughput, no accuracy, no time saved, no customer.
Figures deliberately absent. The technical profile records call counts per stage and a routing reduction. None appears here. They are our own performance numbers and §1 of the publishing contract governs them.
