TL;DR
Positions, not topics. A checklist listing what to look at gives a different answer every time; one stating what to accept is the only kind a system can act on.
Positions, not topics. A checklist that says "check the liability cap" produces a different answer from every reviewer. One that says "cap at 150% of annual fees; 12 months' fees is acceptable; unlimited is a red line" produces the same answer twice.
Only the second kind is a checklist. The first is a table of contents.
Why do most contract review checklists fail?
Because they list subjects to consider rather than decisions already made.
A topic checklist moves the work rather than reducing it. The reviewer still has to decide the position, which means the position gets decided fresh, differently, every time — by whoever is reading on a Thursday afternoon.
Three symptoms, and they are all the same cause:
- Two reviewers reach different conclusions on the same clause and both cite the checklist.
- Nobody can say what the company's position actually is without asking a specific person.
- A system cannot use it. This is the tell that matters now: "review the indemnity" gives a system nothing to compare against.
A checklist of topics can be followed by a human and cannot be followed by anything else. That distinction did not matter five years ago and decides everything now.
What belongs in a single checklist row?
Five columns. Fewer and the row is not actionable:
| Column | Why |
|---|---|
| Clause | What this row is about |
| Our position | The ask, as words we would put in the contract |
| Acceptable fallback | What we will settle for. Without it, every deviation looks equally serious |
| Red line | What we will not sign. This is what makes escalation automatic rather than a judgement |
| Why | The reason — so a negotiator can argue it and a reviewer can weigh it |
The "why" column is the one people cut, and it is the one that makes the checklist survive staff turnover. A rule whose reason is undocumented gets applied literally by newcomers and ignored by veterans.
And "our position as words" is what makes the row usable by a system — it is the difference between flagging and redlining. A position stated as a principle can generate a flag; only a position stated as words can generate a proposed edit.
Which clauses actually need a row?
Start with the ones that have cost you something. For most commercial agreements that is a short list:
- Liability — cap, exclusions, and whether it is mutual
- Indemnity — scope and who controls the defence
- Payment terms — the number of days, and what happens when they slip
- Term and termination — notice, convenience, and cause
- Data protection — processing, transfer, retention
- IP ownership — for anything created under the agreement
- Renewal — automatic or not, and the notice window
Then add rows from your own history, not from a template. The clause that cost you money last year deserves a row more than the one a generic checklist ranks first.
And mark which rows have money attached — payment terms, price, discounts and renewal dates end up in the ERP as live commitments, not just in the file. Those rows deserve a different level of care.
How long should it be?
Shorter than the one you will be tempted to write.
A forty-row checklist is not used. It gets skimmed, and skimming a long checklist is functionally the same as having none — except it produces a record suggesting a thorough review happened.
Twelve to twenty rows covers most commercial paper. If a clause has never once changed the outcome of a negotiation, it does not need a row; it needs a template that already contains your position.
The test: can a reviewer hold the whole thing in their head after using it three times? If not, it is documentation rather than a working tool.
When does a checklist become a playbook?
When every row has a fallback and a red line, and the whole thing is structured rather than prose.
That is not a rename. It is the point at which the rules become machine-usable — a structured playbook imports as rules and can be applied consistently at volume, which is what playbook-driven contract review means.
The upgrade path is short and it costs no software:
- Put the checklist in a spreadsheet — one row per clause, the five columns above.
- Fill in the fallbacks. This is the hard part, and it is a decision exercise rather than a drafting one.
- Mark the red lines. These become automatic escalations rather than judgement calls.
- Then, and only then, consider whether a system should apply it.
Steps 1 to 3 make your human reviews consistent whether or not a system ever applies them. That is why they are worth doing regardless.
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.
Bring your current checklist to a 15-minute call and we will mark which rows are positions and which are topics. It is usually a fast conversation and an uncomfortable one.
Sources
No external source is cited. Every claim is our own design position or a description of common practice, labelled as such.
Sources and fact-check
| # | § | Claim | Tier | Source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | Topic checklists move work rather than reducing it | T2 — ours, the central argument | Internal definition | PASS |
| 2 | 1 | A topic checklist is unusable by a system | T2 — ours | Profile §4.1 | PASS |
| 3 | 2 | The five columns | T2 — ours | Internal definition; profile §11 | PASS |
| 4 | 2 | A position as words enables an edit; a principle only a flag | T2 — ours, consistent with ch1 | Internal definition | PASS |
| 5 | 3 | The seven starting clauses | T2 — ours, a starting list, not presented as exhaustive or as a standard | Internal definition | PASS |
| 6 | 3 | Payment terms, price, discounts and renewal dates become ERP commitments | T1 | purchase-agreements, fetched 2026-09-10 — those terms are copied to the PO header | PASS |
| 7 | 4 | Twelve to twenty rows | T2 — ours, a recommendation. Not a benchmark, not measured | Internal definition | PASS |
| 8 | 5 | A checklist becomes a playbook when rows carry fallback and red line and the whole is structured | T2 — ours | Profile §4.1 | PASS |
Tier summary: 1 × T1, 7 × T2 — 0 × T4.
The one numeric range is labelled. "Twelve to twenty rows" in §4 is a stated recommendation, not a measurement, and row 7 says so. No performance figure, no client, no measured outcome.
Disclosure: §5 says the valuable steps need no software, which argues against a purchase.
