How to review a contract type you don't have a playbook for

A new contract type shows up in the queue eventually, no matter how mature your playbook is. Procurement starts buying a category of service you've never contracted for. An acquisition brings in a batch of vendor agreements written on someone else's paper. Sales closes into a new vertical with a document structure nobody on your team has opened before. Whatever the trigger, the review can't stop for the two or three weeks it would take to build a proper playbook for it. Contracts still need to move, and somebody still has to decide what's acceptable, today, with nothing written down yet.

Why guessing the positions up front doesn't work

The instinct is to sit down and draft playbook entries before the first real contract of the new type lands, based on what seems reasonable. That's usually a waste of the afternoon. Nobody knows which clauses in an unfamiliar contract type actually get negotiated until they've seen a handful of real ones come through. Ironclad's guide to building a playbook makes this point about methodology in general, and it applies twice as hard to a contract type you've never reviewed: pull data from your actual contract process, since looking at which clauses get redlined most, where review time actually goes, and which concessions worked grounds a playbook in real behavior instead of theory. You don't have that data yet for a brand-new contract type. The first several contracts you review are how you get it.

Send the first batch to one person, not the team

The mistake that costs the most later is spreading the first handful of unfamiliar contracts across whoever is free that week. Five reviewers making five independent judgment calls on a clause type nobody has seen before produces five different informal positions, and there's no playbook yet to catch the drift because the playbook doesn't exist. Route the first five to ten contracts of a new type to one senior reviewer, the person who'd own the eventual playbook anyway. Consistency in the first batch matters more than speed, because whatever that person decides becomes the template the rest of the team copies once the type becomes routine.

Capture the reasoning, not just the call

A decision log for this stage needs one more column than most people think to add. Not just the clause and what got decided, but why. "Accepted the vendor's 45-day cure period" tells the next reviewer what happened. "Accepted 45 days because the service isn't customer-facing and a longer cure period doesn't create real exposure" tells them when to make the same call again and when not to. Common Paper's framing of what a playbook actually is fits here directly: it's the rule book for exceptions, documenting the redlines you accept, what you counter with, and who decides when a request goes beyond both. A reasoning column is what turns five one-off decisions into that rule book instead of five disconnected notes nobody can reuse.

Know when to stop treating it as new

There's no universal number, but a rough signal works: once a clause type has repeated across three or four contracts with the same call each time, it's not an exception anymore, it's a position. That's the moment to pull it out of the decision log and turn it into an entry your team can actually apply, with the reasoning attached so whoever reviews the tenth contract of that type isn't re-deriving a judgment call your senior reviewer already made on the second one.

Watch what an AI first pass does with the gap

If you're running an AI first pass against a playbook, a brand-new contract type creates a specific failure mode worth checking for before it happens quietly. Without a playbook entry for the type, the tool either flags nothing, because it has no standard to compare against, or worse, it matches the new contract to the closest existing playbook and applies rules that were never written for it. Neither looks obviously wrong on a dashboard. Confirm which one your setup does before you trust its output on a contract type you haven't fed it before, and treat that early output as a second opinion for your senior reviewer to check, not a finished review.

None of this is a reason to slow down. It's a reason to be deliberate about who makes the first calls and how they get written down, so the fifth contract of a new type benefits from what the first one taught you instead of repeating its guesswork.

Try goHeather free and see how it handles a contract type you haven't built a playbook for yet, then decide for yourself whether its first pass flags the gap or quietly guesses.

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