How to stop contract exceptions from becoming precedent

Somebody on your team approved a one-off exception to the playbook last quarter. Maybe it was a liability cap that went higher than standard for a strategic account, or a payment term that stretched past your normal ceiling because sales needed the deal closed by month end. Nobody wrote it down anywhere a future reviewer would find it. Three months later, a different reviewer sees a similar request, remembers “we did this before,” and approves it again. Now it's happened twice. By the fourth time, it's not an exception anymore. It's just what your team does, except nobody voted on that, and nobody updated the actual playbook to say so.

That's how a playbook drifts out from under itself. Not through one bad decision, but through a string of reasonable ones that never got logged as a group.

Why this is worse than it looks

An exception that gets approved and forgotten does two kinds of damage. First, the next reviewer who hits the same clause has no record of why the last exception was granted, so they're guessing at precedent instead of applying a rule. Second, if the exception keeps recurring and nobody notices the pattern, your playbook is quietly wrong about what your business will actually accept, and the document stops matching reality. A breakdown of contract exception approval workflows from Moxo names this directly as a common failure point: lost precedent value, where approved exceptions never get tracked in a way that informs future decisions or policy updates. The approval happened. The learning from it didn't.

The fix isn't to stop granting exceptions. Sometimes the standard position genuinely doesn't fit a deal, and forcing every contract through the same mold slows the business down for no good reason. The fix is to write down every approved exception instead of counting on someone to remember it correctly.

What the record needs

Keep it simple enough that reviewers will actually fill it out. For every approved deviation from the playbook, log four things: the clause, the reason code for why this deal justified a departure, who approved it, and an expiry or review date. That last field matters most and gets skipped most often. An exception granted for one strategic renewal shouldn't quietly become available to the next twenty deals just because someone can point to it in a file.

That distinction shows up in a recent breakdown of AI-assisted playbook workflows from Glean, which treats exception notes and approvals as their own category of information, separate from the playbook rule itself and separate from ordinary negotiation history, precisely because the reason a deviation passed often matters more than the text of the deviation. Mixing exception history into the general pool of “language we've used before” is exactly how a one-time concession starts reading like settled policy. The same piece is direct about the goal of keeping the two apart: exceptions should inform review, but they shouldn't silently become new policy on their own.

Set a trigger, not just a log

A log nobody reads is just a longer version of the problem. Set a number. If the same clause gets an exception three times in a quarter, that's not three exceptions anymore, it's a signal the standard position needs a second look. Send that pattern to whoever owns the playbook and make them decide, on purpose, whether to fold the exception into an approved fallback position or reaffirm the original standard. Either answer is fine. What's not fine is the standard staying on paper while the real practice moves somewhere else without anyone deciding to move it.

This is a different problem from routing, which we've covered in how to set escalation rules that don't get ignored. Escalation rules decide who gets to approve a deviation in the moment. Exception tracking decides what happens to that approval after the deal closes. You need both, and they're easy to conflate because they sit in the same part of the workflow.

Where AI actually helps here

An AI first pass can flag when a contract's terms fall outside the standard playbook position, which is useful on its own, but it can also check whether an incoming term matches a previously approved exception rather than a brand-new deviation, and surface that history to the reviewer instead of leaving them to remember it from a hallway conversation. That's a reasonable ask of any AI contract review tool, including this one: can it tell you not just that a clause is nonstandard, but that your team granted the same exception twice before and never revisited the rule. The judgment about whether to keep granting it still belongs to a person.

Try goHeather free and see whether it can surface the exception pattern already sitting in your own contract file, then decide for yourself whether your playbook still matches what your team actually approves.

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