Ask almost any legal-AI tool to fix a bad clause and it will fix it. Instantly, confidently, and in well-formed legal prose. That is the easy version, and it is the dangerous one. A one-shot "rewrite this clause" is a single model call with no way to know whether the rewrite is right, whether it quietly gave away a term you cannot give away, or whether the clause needed fixing at all. It always returns something, because returning something is what it was built to do.
The more useful behavior, for a lawyer, is a tool that can say "I could not produce a fix I trust here." An honest abstention costs a reviewer nothing. A confident bad redline costs them the exact thing they hired the tool to protect: the assumption that the change is safe to send.
This post is about the loop we actually run when we draft a fix for one flagged clause. It is not a rewrite call. It is a bounded sequence of steps, each of which can stop the process or downgrade its own output, so that what reaches the lawyer is either a change that passed its own checks or an explicit "no." There is one flow illustration and one small snippet, both simplified for readability, because the interesting part is the shape of the loop, not any single prompt.
The loop, in order
When a clause is flagged against your negotiation playbook, the fix runs through these steps, in this order.
# simplified: the per-clause fix loop
plan -> find your playbook position for this clause type
diagnose -> name the specific deviations, or return an empty list
draft -> redraft surgically, fixing only what was diagnosed
validate -> deterministically check the draft against numeric floors
repair -> if it broke a numeric rule, rewrite to satisfy it (bounded retries)
self-critique -> a skeptical pass: does the rewrite cure every diagnosed issue?
gate -> deterministic sign-off gate (deal-breaker + escalation) before it can be sent
Drawn out with the exits it can take, the same loop looks like this.
The three boxes on the left that begin with "Stop" or "No redline" are the abstentions, and the two "Mark not validated" and "Attach caveat" boxes are the downgrades: places the loop ends early or ships a result wearing a flag rather than pretending it is clean.
In plain English: the model does not get to jump straight from "here is a clause" to "here is a better clause." It has to locate what your playbook says, state exactly what is wrong, change only that, prove the numbers, defend the result against a skeptic, and pass a sign-off gate. Each of those is a place the process can decline or flag itself. Concretely, the diagnosis is capped at a small fixed number of issues ordered most severe first, the numeric repair is bounded to a few attempts before the draft is marked not validated rather than looped forever, and every phase streams a progress event so the reviewer watches the loop reason rather than staring at a spinner.
Let me walk the steps that matter, because the value is in what each one is allowed to refuse.
Plan: draft toward a position, not toward a vibe
The loop begins by looking up your playbook position for that clause type: the preferred stance, the walk-away floor, any vetted library clause you have blessed, and the fallback ladder you are willing to climb down.
If your playbook has no position for that clause type, the loop stops right there and tells you so. There is nothing to draft toward, so it does not invent a target. This is the first and cheapest abstention: the tool refuses to redline against a standard you never set.
Everything downstream steers on this position. When you have supplied a vetted library clause, the draft step is told to adopt that language wherever the counterparty would accept it, adapting only defined terms and cross-references. The fix is drafting toward your house position, not toward a generic notion of "better."
Diagnose: the step that is allowed to find nothing
Before any redrafting, a diagnosis step reads the current clause against the playbook position and names the specific, concrete ways it deviates. Not "this could be clearer." Concrete deviations tied to a named escalation trigger or a real breach of the acceptable range, with the offending words quoted.
The important instruction here is the one that tells it to find nothing when there is nothing to find. A clause that already satisfies your standard position and stays inside your acceptable range has no issues, and the diagnosis is required to return an empty list. Stylistic preferences and belt-and-suspenders additions do not count.
When the diagnosis comes back empty, the loop short-circuits. It does not draft. It returns a result that says, in effect, "this clause already tracks your playbook; no change recommended," and it hands back the original language unchanged.
# simplified: a clean diagnosis short-circuits to "no redline needed"
if not issues:
yield thinking("done", "This clause already meets your playbook position. No redline needed.")
return no_change_result(current_language) # original text, no rewrite
# only past this point does the loop draft a fix
In plain English: if nothing is wrong, the tool does not manufacture a rewrite to look busy. This matters more than it sounds, because gratuitously editing an already-acceptable clause is one of the most common ways a review tool wastes a lawyer's attention and introduces risk into language that was fine. The self-check that prevents this is the difference between a redline and noise.
Draft: surgical, not wholesale
Only once there is a diagnosis with real issues does the draft step run. It is given the diagnosis and told to fix every listed issue and change as little else as possible: preserve the counterparty's wording, defined terms, numbering, and structure wherever they are already acceptable.
The goal is a surgical redline, the kind a lawyer would actually make, not a whole paragraph deleted and retyped to move one number. It is told to reach the preferred position where it can and never cross the walk-away floor. If it has to climb down the fallback ladder to get to something the counterparty would accept, it has to name which rung it used, so that a fallback is a visible decision and not a silent concession.
If the draft step comes back empty, the loop stops and says it could not draft a replacement. That is the second abstention: better to admit no draft than to emit a blank or malformed one.
Validate and repair: the deterministic part
Here the loop stops trusting the model and checks its work with code.
Many playbook positions carry hard numeric floors: a cure period no shorter than some number of days, a liability cap no lower than some multiple, a notice window, and so on. These are exactly the terms a fluent rewrite gets subtly wrong, because prose that reads perfectly can still say the wrong number. So the draft is run through a deterministic validator that checks it against those numeric rules. No model call, no judgment, just arithmetic against your floors.
If the draft violates a numeric rule, the loop does not shrug and ship it. It runs a repair step: it hands the model the specific violations and tells it to rewrite to satisfy every rule exactly, changing nothing else, and then it validates again. This repair is bounded. It retries a small, fixed number of times rather than looping forever chasing a floor the model keeps missing.
If, after those bounded repair attempts, the draft still fails a numeric floor, the loop does not hide that. It marks the result not validated and carries that flag forward. The fix is still produced, but it reaches the lawyer labeled as not having met a numeric rule, rather than dressed up as clean. An accurate caveat is worth more than a false all-clear.
Self-critique: a skeptic reads the rewrite
A draft that passes the numeric check can still miss the point. It can satisfy the floors and still fail to cure the actual issue that was diagnosed, or it can over-reach past what the counterparty would ever accept.
So the loop runs a self-critique step. A separate, deliberately skeptical pass is given the original clause, the proposed rewrite, the playbook position, and the list of issues the rewrite was supposed to fix, and it has to decide whether every issue is genuinely resolved without over-reaching or crossing the walk-away floor. It returns whether the rewrite cures the issues and lists any issue left unresolved.
If the critique finds unresolved issues, that does not silently vanish either. The result is surfaced with the caveat attached and the unresolved items named, so the lawyer sees "here is a proposed fix, and here is the part it did not fully solve" rather than a redline presented as complete.
Gate: what has to be true before it can be sent
The last step is not a model call at all. It is a deterministic sign-off gate, and it decides what level of human approval a fix needs before it can go to the other side.
First the loop grounds the redline: it confirms the "current language" the fix claims to be editing is a real span of the clause, so a proposed change is anchored to text that actually exists rather than to a hallucinated quote. Then it applies your playbook's approval rules. Each deviation carries a required approval level and a deal-breaker flag, and conditions can raise that level based on the deal value, whose paper the contract is on, the governing law, or how severe the deviation is. Those levels are one ranked ladder, none below manager below partner below GC, and a condition only ever raises the rank, never lowers it; a condition that references deal context you did not supply fails safe and does not escalate, so the gate never invents a stricter requirement out of missing data. This is the same grounding-and-gate primitive the whole-document review runs, reused here for one clause rather than reimplemented, which is why a fix drafted in isolation still lands under the exact sign-off rule the rest of your review obeys. The gate aggregates all of that into a single answer, for example "requires partner sign-off before sending."
Be clear about what this gate does and does not do. It does not hide a redline from you. It decides whether a fix can quietly go out the door or whether your own playbook says a human of a certain seniority has to sign off first. A deal-breaker edit does not ride out to the counterparty without the sign-off you told the system to require. That is the honest scope of the gate: it governs sending, not seeing.
Where the honesty actually lives
Put the abstentions together, because they are the whole argument.
The loop declines outright when there is no playbook position to draft toward. It declines to edit at all when the clause already meets your position, instead of inventing a rewrite. It stops when it cannot produce a usable draft. It labels a fix not validated when it cannot meet a numeric floor after bounded repair. It labels a fix caveated when the skeptical pass finds an issue unresolved. And when this per-clause loop runs across a whole document and a given clause cannot be fixed and verified, that clause keeps its first-pass redline marked unverified rather than being silently dropped, so nothing disappears.
All of that makes the tool look less magical in a demo, because sometimes the answer is "no" or "yes, but." That is the point. A tool that always returns a confident redline has simply moved the risk from the model onto the lawyer, who now has to catch the bad ones by hand. A tool that can decline, or hand you a fix wearing its own caveats, has done part of the reviewing for you.
Test it yourself in about five minutes
You do not need our code to find out whether a tool earns its fixes or just emits them. You need a few deliberately hard clauses and an eye on whether the tool is ever willing to say no.
-
The already-good clause. Take a clause that is genuinely fine against a standard you specify, then ask the tool to improve it. A tool that earns its output says there is nothing to fix. The tell of a weak one: a confident rewrite that changes wording for the sake of looking busy, with no real issue behind it.
-
The impossible floor. Give the tool a rule it cannot satisfy without breaking another rule, for example "the cure period must be at least 60 days" against a clause and counterparty posture where 60 is a non-starter. A strong tool either meets the floor exactly or tells you it could not. The tell: prose that reads well and quietly lands on the wrong number.
-
The over-reach trap. Ask it to fix a one-sided indemnity in your favor and watch how far it goes. A disciplined tool fixes the diagnosed problem and stops. The tell: a rewrite that swings the clause so far your way the counterparty would never sign it, presented as a normal redline.
-
The no-standard test. Ask it to "improve" a clause without giving it any position or playbook to draft toward. A tool with discipline asks what you are trying to achieve or declines to guess. The tell: a confident rewrite toward a standard you never set.
-
The unresolved-issue test. Hand it a clause with two distinct problems and see whether the fix, and the tool's own description of the fix, addresses both. A strong tool tells you which issues it resolved and which it did not. The tell: a clean redline that silently solves one problem and leaves the other, with no mention that it did so.
And four questions to ask the vendor
The clauses test the product. These test whether the people who built it thought about failure at all.
-
Does your fix ever decline to produce a redline, and on what basis? A system that cannot say no has no gate.
-
What do you check with code versus with the model? Numeric floors are arithmetic. A tool that only asks a model whether the number is right has skipped the cheap, certain check.
-
What happens when the proposed fix fails your own validation? "We flag it" is a real answer. "It never fails" is not.
-
Who has to sign off before a fix can be sent, and is that rule enforced or advisory? A sign-off gate that the tool can talk its way past is decoration.
A vendor who answers these with specifics is doing the unglamorous work. A vendor whose tool always returns a confident redline has built the easy version, and handed you the risk it chose not to carry.
