A generic contract reviewer knows what a limitation-of-liability clause is. It does not know that your firm caps at twelve months of fees, will climb down to twenty-four under protest, and walks away from anything uncapped. It does not know that your one non-negotiable on an NDA is the compelled-disclosure carve-out, or that a deviation on indemnity needs a partner's signature before it goes back to the other side. That knowledge is not in the model. It is in the heads of your senior lawyers, and it leaves the building when they do.
A negotiation playbook is where that knowledge gets written down in a form a reviewer can actually apply. This post is about the shape of that artifact: how a firm's standard positions, its fallback ladder, and its hard deal-breakers are encoded as data, how a structure linter catches a broken or half-finished playbook before it is ever pointed at a contract, and how a sign-off ladder turns a position from one person's opinion into an accountable requirement. There are two small, simplified illustrations, because the interesting part is the data you can inspect, not an adjective you have to trust. This is not about how the redline gets exported or how a single clause gets rewritten; it is about the standard those steps are measured against.
Here is the life of a playbook, from a blank page to a named approver on a live deal.
The top half is authoring and the linter; the bottom half is what happens at review time when the encoded standard meets a real contract. The rest of this post walks the fields that make each of those steps possible.
What a position actually encodes
The unit of a playbook is a position, and there is one per clause type. The clause types line up with a shared library, so a position for "limitation_of_liability" sits next to the library's entry for the same thing, and the whole set travels together for a contract type like NDA, MSA, or DPA.
A position is not a single sentence of preference. It is a structured record with distinct fields that each answer a different negotiation question. Simplified, one position looks like this:
// simplified: one PlaybookPosition
{
"standard_position": "Mutual cap at 12 months of fees, super-cap for data breach...",
"acceptable_range": "Cap at 6-24 months of fees; asymmetric carve-outs if proportional.",
"fallback_ladder": [
"12-month mutual cap, standard carve-outs intact.",
"18-month cap, data-breach super-cap preserved.",
"24-month cap, data-breach liability kept outside the general cap."
],
"deal_breaker": "Uncapped liability, or data-breach liability inside the general cap.",
"priority": "must_have",
"approval_level": "partner",
"escalation_conditions": [
{ "attribute": "contract_value", "operator": "gte", "value": "1000000", "escalate_to": "gc" }
],
"rationale": "An uncapped or mis-tiered cap is the single largest exposure in the paper.",
"library_clause_id": "..."
}
In plain English: standard_position is the stance you open with.
acceptable_range is the free-text zone you can live in.
fallback_ladder is the same idea made ordered and concrete: the specific rungs you step down through, best acceptable first, worst last, when the opening position is rejected.
deal_breaker is the floor you do not cross.
priority says how negotiable the whole thing is, from deal-critical down to a concession candidate.
approval_level and escalation_conditions say who has to sign off when a contract deviates, and we will come back to those.
rationale records why the firm holds the position, so a junior reviewer inherits the reasoning and not just the rule.
And an optional link to a vetted library clause lets the position point at blessed wording instead of a paraphrase.
Two more fields keep the artifact honest. A per-position toggle lets you park an alternative position on the shelf without it silently affecting live reviews, and a per-position risk weight lets a clause you care about more count for more when a contract is scored against the playbook.
The reason to split a position into these fields rather than one prose blob is that each field is separately usable. A free-text "we prefer a twelve-month cap and won't go below six" reads fine to a human and is useless to a machine that has to decide whether a specific contract complies, what to retreat to, and whether to stop. The ordered ladder, the explicit floor, and the priority tier are what let a reviewer negotiate the way your senior lawyers would, instead of flagging everything at one flat level of alarm.
The fallback ladder and the walk-away floor
Every real negotiation has three layers: what you ask for, what you will settle for, and what makes you leave. Most tools capture only the first, and maybe a fuzzy version of the second. The playbook captures all three as distinct, machine-readable things.
The ladder is ordered on purpose, best to worst, so that when the opening position does not survive, there is a defined next move rather than an ad-hoc one. The floor is categorical: a term at or below the declared deal-breaker is forced to the highest-severity, needs-attention state regardless of what the model itself thought of the clause. That override is the point. You want your walk-away line to be a rule the system cannot talk itself out of, not something that depends on a language model happening to feel strongly about a clause.
You can pre-load these from a template and then edit, or extract them from a contract your firm has already negotiated well: upload an exemplar, and the positions come back pre-filled for you to correct rather than authored from a blank page. Either way the output is the same structured record, so the rest of the machinery does not care where it came from.
The sign-off ladder: from opinion to accountable requirement
A position that says "we don't accept uncapped liability" is still just advice unless something enforces who gets to accept a deviation from it.
That is what the approval fields do, and they are backed by a single shared ordering: none < manager < partner < gc.
A position's approval_level names the seniority required to sign off when a contract deviates from that position.
There is one built-in floor that is not up for debate: a declared deal-breaker requires partner sign-off at minimum, even when the position set no explicit approval level.
A walk-away line is never allowed to be silent.
On top of the flat level sit the conditional rules. A rule can raise the required sign-off when the deal context matches, and the context it reads is concrete: the deal value, whether the contract is on the counterparty's paper, the governing law, and the review's own severity finding for that clause. So a playbook can say "partner normally, but GC if the deal is over a million dollars, or it is on their form, or the finding comes back red." At review time the engine takes the base level, applies every matched condition, and lands on the highest required sign-off, with a note explaining which condition raised it. A numeric condition compares with a small fixed set of operators, greater-than, at-least, less-than, at-most, equal, not-equal, and a condition that references deal context the caller never supplied fails safe to no escalation, so the gate never raises a requirement on data it does not actually have. The result is that a deviation from the house standard carries a named authority who has to approve it before it can be sent, and a deal-breaker redline cannot quietly ride out to the other side without the sign-off your own playbook demands.
This ordering lives in exactly one place in the code and is imported everywhere it is needed, because a divergence between what the reviewer thinks needs partner sign-off and what the playbook author thinks needs partner sign-off would be a bug in the precise control these features exist to provide. The same shared parser decides what counts as a valid numeric threshold, so the engine that escalates on a value and the linter that validates that value can never disagree about what a number is.
The structure linter: catch a broken playbook before it reviews a contract
Here is the failure mode that matters. Someone authors a playbook, marks a clause deal-critical, and forgets to give it a fallback ladder or a sign-off gate. Or they write a conditional rule that escalates to a level no higher than the clause already requires, so it can never actually fire. Or they leave a position with no text in it at all. None of that throws an error. The playbook looks complete. It just silently fails to protect you in exactly the spots you thought you had covered.
So before a playbook is trusted, it goes through a structure linter. This is deliberately not analytics about how the playbook performs against real deals. It is a pure, deterministic check over the authored positions, with no database and no language model, which means it is cheap, fully testable, and cannot itself hallucinate a problem that is not there. It answers one question: is this playbook well-formed enough to rely on?
Each finding carries a severity, a plain-language message, and a concrete suggestion. Simplified, a finding looks like this:
// simplified: one lint finding
{
"code": "must_have_no_fallback",
"severity": "warning",
"label": "Limitation of Liability",
"message": "Limitation of Liability is deal-critical but has no fallback ladder.",
"suggestion": "Add the ordered positions you can retreat to before walking away."
}
The checks map directly to the ways a playbook is quietly broken. An empty position, a clause marked as important with nothing written in it, is an error. A conditional rule with a missing or non-numeric threshold where a number is required is an error. A conditional rule that can never raise the sign-off above the clause's base level is a dead rule, and also an error, because it is a control the author believes exists and does not. A deal-critical clause with no fallback ladder is a warning: you declared it matters but gave the reviewer no defined retreat, so it is all-or-nothing by accident. A deal-critical clause with no sign-off gate is a warning: a deviation on your most important clause could be accepted with nobody senior signing off. A walk-away line with nothing to retreat to before it draws the same warning. And if nothing in the whole playbook is marked deal-critical, that is an informational nudge, because a playbook where every clause is equally negotiable has not told the reviewer what to defend first.
Disabled positions are skipped, so a draft you parked on the shelf does not drag down a playbook you are actually using. The linter rolls the findings into a score and a grade, with errors weighing more heavily than warnings and warnings more than nudges, so an author gets one fast read on whether the playbook is ready. The weights are fixed and inspectable, not vibes: errors weigh more than warnings, warnings more than nudges, the score is floored at zero, and it buckets into excellent, good, and needs-work. The function is pure, so the same positions in produce the same grade out, which is what lets it back a unit test. Because it is a pure function over the authored positions, the same input always produces the same findings and the same number, which is what lets it back a unit test rather than a screenshot. The grade is the signal; the findings are the actionable part, each naming the exact clause and the exact fix.
The buyer-relevant claim here is narrow and true. A playbook you point at a hundred contracts is only worth as much as it is complete, and completeness is not something you can eyeball on a screen full of positions. The linter is what turns "we wrote a playbook" into "we can see, before we rely on it, that it actually encodes retreats and sign-offs where it claims to."
Why this is the accountable version
Put the three pieces together and the artifact stops being one senior lawyer's instinct. The positions make the firm's standard explicit and structured. The sign-off ladder makes a deviation an accountable event with a named approver, not a judgment call the most available reviewer makes alone. The linter makes the whole thing inspectable before it is trusted. And every edit snapshots a prior version, so a change to the house standard is undoable and has a trail.
That is what "house-standard review at scale" actually requires. Not a smarter model reading each contract in isolation, but a written, checkable, signed-off standard that every review is measured against the same way, whether it is run by the partner who wrote the playbook or the associate who joined last week.
Test it yourself, and questions to ask any vendor
You do not need our code to tell an encoded playbook from a wish list. You need to try to author one and watch what the tool lets you get away with.
-
The fallback-ladder test. Try to encode a clause with an opening position, two ordered retreats, and a hard walk-away floor as separate things. A tool that models negotiation lets you. The tell of a weak one: a single free-text box where "preferred" and "acceptable" and "walk away" all blur into one paragraph the reviewer cannot act on differently.
-
The deal-breaker test. Mark a clause as a non-negotiable and then feed it a contract that violates it. A real floor forces the flag no matter how mild the language sounds. The tell: the tool's own read of the clause quietly overrides your walk-away line.
-
The incomplete-playbook test. Mark a clause deal-critical, leave its fallback ladder and sign-off gate blank, and save. A tool that takes the artifact seriously warns you, before you rely on it, that a critical clause has no retreat and no approver. The tell: it saves silently and lets you point an unfinished playbook at real contracts.
-
The sign-off test. Ask whether a deviation from a position carries a required approval level, and whether that level can rise based on deal value, whose paper it is, or the governing law. A real gate names an authority and enforces it. The tell: "it flags the clause" with no notion of who has to sign off, which is a color, not a control.
-
The dead-rule test. Write a conditional escalation that escalates to the same level the clause already requires. A tool that validates its own logic tells you the rule can never fire. The tell: it accepts a control that does nothing and reports the playbook as fine.
If a tool passes these, it is treating your playbook as an accountable artifact. If it takes your standard positions as free text, cannot enforce a floor, and never warns you that the playbook you are about to trust is missing the very retreats and sign-offs you thought you had encoded, then it is not teaching the reviewer how your firm negotiates. It is just reviewing contracts against its own defaults and letting you believe they were yours.
