How to set rule priority in a contract review playbook

A playbook with a dozen rules works fine on its own. A playbook with eighty rules will eventually produce two rules that both fire on the same clause and point the reviewer in opposite directions. If nobody has decided in advance which one wins, every reviewer decides it differently, which is exactly the inconsistency the playbook was supposed to get rid of.

Where the collisions actually come from

These collisions usually aren't drafting mistakes. They show up because a playbook grows the same way any other set of business rules grows: someone adds a general rule, then adds a second rule to cover a specific exception, and nobody goes back to check whether the two now overlap.

Say your standard rule flags any auto-renewal notice period under 30 days. Later, someone adds a second rule for enterprise accounts: a 15-day notice period is fine above a certain contract value. Both rules are correct on their own. Put a large enterprise deal with a 15-day notice clause in front of a reviewer, or in front of an AI running a first pass, and you now have two valid instructions aimed at the same clause telling it to do opposite things. A third common version: a rule gets replaced after a policy change, but the old rule never gets removed, so both the old and new positions are still live in the same playbook.

Nest the exception instead of stacking a second rule

The cleanest fix is structural. Instead of writing a general rule and a competing standalone rule for the exception, attach the exception as a condition on the original rule: "flag notice under 30 days, except for enterprise accounts over $X, where 15 days is acceptable." One rule, one owner, no second rule floating around waiting to collide with it later. This kind of clutter builds up fast in a growing playbook, and it matters beyond tidiness: the playbook is what decides what an AI review actually flags, so a rule that quietly contradicts another one doesn't just create confusion on paper, it changes what gets caught on the next hundred contracts that run through it.

Retire what you replace

When a position changes, the old rule needs to come out, not just get outranked. Outside of contracts, software teams that build rule engines document the same failure mode: nobody writes conflicting rules on purpose, they just pile up as a system scales and different people add requirements without checking what's already there. Contract playbooks fail the same way, just with people instead of code shipping the changes. If your last liability cap position was "1x fees" and the new one is "1.5x fees for renewals," delete the old rule. Don't leave it sitting in the document as a second, quieter vote.

Set the tiebreak before you need it

For the conflicts you can't design away, decide the tiebreak in writing ahead of time instead of live, mid-review. Microsoft's documentation for its own rules engine describes the standard fix: give rules an explicit priority number, so when two conditions are both true at once, the engine always runs the higher-priority rule's action first instead of the order coming down to whichever rule it happens to check first. A playbook needs the same explicit call, just written in plain language: "the enterprise fallback overrides the general renewal rule when both apply," or "the newer indemnity position controls over the legacy one." Write it as its own line item, not as a note in someone's head about which rule they personally trust more.

Where AI actually helps here

This is a reasonable place to lean on a tool, with the usual limits. Something like goHeather's AI contract review workflow can run a contract against your full playbook on a first pass and flag the clauses that match your rules, which puts a possible conflict in front of a person before it turns into an inconsistent decision buried in a signed contract. It won't tell you which position should win. That call belongs to whoever owns the playbook, and it should get made once, on paper, not contract by contract.

A playbook exists to take the same judgment call off the table for every contract that touches it. Leave two rules in open conflict and the judgment call just moves from the playbook to whoever happens to be reviewing the contract that week, and the outcome starts depending on who's on shift when it lands. Find the rule that already contradicts another one in your playbook and write down which one wins before the next contract that triggers both shows up in the queue.

This is legal information, not legal advice; consult a lawyer for legal advice.