

There is a pattern in legal AI that has become so common most people stopped questioning it. You upload a contract. The AI reads it. Then it gives you a list of suggestions in a sidebar, a chat window, or a PDF markup. And then you, the attorney, have to manually apply each one.

That is not a workflow improvement. That is a second job.

## The Suggestion Problem

Suggestions are fine for brainstorming. They are not fine for contract review. When a tool tells you "consider adding a mutual indemnification clause" but leaves you to figure out where it goes, how to phrase it, and how to mark it up for opposing counsel, it has done maybe 20% of the work.

The remaining 80% is still on you. Open the document. Find the right section. Draft the language. Format it. Insert a tracked change so your counterpart can see exactly what moved. That last part is critical. In transactional practice, tracked changes are not optional. They are the language of negotiation.

## What Tracked Changes Actually Do

When you send a redline to opposing counsel, every tracked change carries meaning. A deletion says "we reject this." An insertion says "we propose this instead." A comment says "we need to discuss this." The combination of those marks tells a story about your position, your priorities, and your risk tolerance.

No suggestion list can replicate that. A bullet point that says "Flag the indemnification cap" does not move the deal forward. A tracked change that rewrites the cap with a comment explaining the rationale does.

## How Reddox Handles This Differently

Reddox does not give you suggestions. It gives you tracked changes. Native Word tracked changes, applied directly to your document through the Office API. You can [see it in action on the product page](/product).

When you click "Redline," Reddox reads the full document, identifies issues based on your playbook or instructions, and applies edits as tracked changes. Each one is tagged with a confidence rating: critical, recommended, or optional. You accept, reject, or modify them using the same workflow you have used for your entire career.

The key technical detail is the [word-level diff engine](/blog/word-level-diff-engine-explained). Most AI tools, if they attempt edits at all, replace entire paragraphs. That makes the tracked change unreadable. If the AI changed two words but replaced the whole paragraph, opposing counsel sees a wall of red instead of a surgical edit. They cannot tell what actually moved.

Reddox computes the diff at the word level using a longest common subsequence algorithm. If only two words changed, only two words show up as tracked changes. The rest of the paragraph stays clean.

## Why This Matters for Your Practice

Three reasons.

First, speed. You do not have to manually apply anything. The AI did the markup. You just review it.

Second, credibility. When you send a redline with surgical tracked changes and [confidence-rated comments](/blog/confidence-scoring-how-to-triage-a-redline), it signals thoroughness. It tells opposing counsel that every edit was deliberate.

Third, consistency. If your firm uses playbooks, every attorney gets the same review. The junior associate who runs the playbook on a Tuesday night produces the same quality of markup as the partner who would have done it on a Friday morning.

## The Bottom Line

Suggestions are a starting point. Tracked changes are a finished product. If your AI tool is not producing native tracked changes in Word, it is not doing contract review. It is doing contract commentary. And that is a very different thing. [Try Reddox for free](/signup) and see the difference in your next redline.


Why Tracked Changes Matter More Than Suggestions



Every law firm has a set of documents they consider the standard. The NDA your partners approved three years ago. The MSA template your litigation team vetted. The lease form your real estate group uses on every deal. These are your gold-standard templates, and they represent your firm's position on hundreds of individual clauses.

The problem is that most attorneys keep these templates in a folder somewhere and compare them manually. They open the incoming contract in one window, the template in another, and read them side by side. Section by section. Clause by clause. It works, but it takes hours and it depends entirely on the attorney catching every deviation.

## What Reference Doc Comparison Actually Does

Reddox lets you upload your gold-standard templates to a reference doc library. When you upload a document, it does not just store the file. It reads the full text, identifies individual clauses, and indexes them by type and content. An NDA template gets broken into its confidentiality definition, its exclusions, its term and termination provisions, its remedies clause, and so on.

When an incoming contract arrives and you run a review, Reddox compares each clause in the incoming document against the corresponding clause in your reference template. It flags three possible states for each clause: match, deviation, or missing.

A match means the clause is substantively aligned with your standard. A deviation means there are differences that need review. A missing flag means the incoming contract lacks a clause your template includes.

## How the Clause Extraction Works

The clause extraction engine looks at document structure, heading patterns, and content boundaries to identify individual clauses. It handles numbered sections, lettered subsections, and even clauses that run together without clear formatting.

Each extracted clause gets a normalized identifier so it can be matched across documents. A "Governing Law" clause in your template gets compared to the "Governing Law" clause in the incoming contract, even if the section numbers are different or the heading uses slightly different wording.

This is not keyword matching. The system understands that "Choice of Law" and "Governing Law" refer to the same concept. It compares the substantive content, not just the labels.

## What This Looks Like in Practice

Imagine you are reviewing an incoming NDA. You have uploaded your firm's standard NDA template to the reference doc library. You open the incoming NDA in Word, click the Reddox task pane, and select your reference template.

Reddox runs the comparison and presents results in a [clause comparison view](/blog/clause-comparison-view-explained). On the left, your reference clause. On the right, the incoming clause. Status badges show you which clauses match, which deviate, and which are missing entirely.

For deviations, Reddox can automatically redline the incoming document to bring it in line with your standard. The tracked changes show exactly what would need to change. You review them, accept the ones you agree with, and modify the ones that need a different approach.

For missing clauses, Reddox flags the gap and can insert your standard language as a tracked change, placed in the appropriate location in the document.

## Why This Changes the Review Process

Without reference doc comparison, every contract review starts from scratch. The attorney reads the document, recalls what the firm's standard position is on each issue, and manually checks whether the incoming language matches. This relies on memory, experience, and attention to detail across what might be 40 or 50 individual clauses.

With reference doc comparison, the firm's institutional knowledge is encoded in the template. A first-year associate running a comparison against the firm's standard NDA will catch the same deviations a tenth-year partner would catch. The review becomes systematic instead of intuitive. Pair this with [custom playbooks](/blog/playbooks-for-consistent-contract-review) and the consistency gains multiply.

This is especially valuable for firms that handle volume. If you review 20 NDAs a month, reference doc comparison turns each one from a 90-minute read into a 15-minute triage of flagged deviations.

## Setting Up Your Library

Getting started takes about five minutes. Drag and drop your template into the Reddox reference doc panel. The system extracts and indexes clauses automatically. You can upload as many templates as you want: one for NDAs, one for MSAs, one for leases, one for employment agreements. Learn more about how it all works on the [product page](/product).

Each template stays in your library and can be selected on any future review. Upload once, use forever.

## The Bigger Picture

Reference doc comparison is not just a time saver. It is a quality control mechanism. It ensures that your firm's standards are applied consistently, regardless of who runs the review, what time of day it happens, or how many deals are running in parallel. The template holds the standard. The AI enforces it. [Check our pricing](/pricing) and start building your reference library today.


Reference Doc Comparison: How to Automate Clause-by-Clause Review



Most legal AI products work like a chatbot. You paste in a contract, ask a question, and get text back. Maybe the text is helpful. Maybe it even includes a suggested redline. But the output is always text. It never touches your document.

Reddox works differently. Instead of generating text for you to copy and paste, it calls tools that directly manipulate your Word document. It inserts tracked changes. It adds comments. It edits table cells. It formats text, inserts footnotes, creates bookmarks, and generates templates. All of this happens through the Word API, not through a chat window.

This is the difference between an AI that talks about your document and an AI that works on your document. See the full toolkit on the [product page](/product).

## How Function Calling Works

Under the hood, Reddox uses OpenAI's function calling capability. When you ask Reddox to review a contract, the AI does not just generate prose. It generates structured function calls that specify exactly which tool to use and what arguments to pass.

For example, when the AI decides a clause needs to be rewritten, it does not say "consider replacing the indemnification clause with mutual language." Instead, it calls the `apply_redline` tool with the specific text to find, the specific replacement text, and a confidence rating. The tool then executes that edit as a native Word tracked change. You can define what the AI looks for using [custom playbooks](/blog/playbooks-for-consistent-contract-review).

This is a fundamental architectural difference. The AI is not advising you. It is acting on your behalf, using the same document tools you would use yourself.

## The 29 Tools

Reddox gives the AI access to 29 tools organized across 10 plugin groups. Here is what they cover.

**Editing tools** handle tracked changes. The AI can insert, delete, or replace text with full tracked change markup. The [word-level diff engine](/blog/word-level-diff-engine-explained) ensures edits are surgical.

**Formatting tools** control font styling, paragraph alignment, spacing, and styles. If the AI needs to bold a defined term or change a heading style, it calls the appropriate formatting tool.

**Annotation tools** insert comments and footnotes. Comments include the AI's rationale for a suggested change. Footnotes can add explanatory text or cross-references.

**Structure tools** work with bookmarks, content controls, and document navigation. The AI can bookmark a clause for reference, insert fillable content controls for template generation, or navigate to a specific section.

**Table tools** let the AI read and edit individual table cells. This matters for contracts with payment schedules, fee tables, or structured data.

**Document tools** handle broader operations like reading the full document text, detecting document type, and generating templates from existing documents.

**List, hyperlink, field, and search tools** round out the toolkit with capabilities for creating structured lists, inserting links, working with Word fields, and performing wildcard searches.

## Why More Tools Means Better Results

A chatbot with no tools can only do one thing: generate text. That means every interaction ends with you doing manual work to apply whatever the AI suggested.

An AI with a few tools can do a few things well but hits walls quickly. If it can apply tracked changes but cannot insert comments, it cannot explain its reasoning inline. If it can edit text but cannot touch tables, it skips payment schedules entirely.

An AI with 29 tools across 10 plugin groups can handle nearly any task a lawyer would perform in Word. The breadth of the toolkit is what allows Reddox to do multi-step operations. Read the document, identify an issue in a table, edit the relevant cell, add a comment explaining the change, and format the result. All in one pass.

## Multi-Turn Tool Loops

Some tasks require multiple steps. The AI reads the document and identifies that a defined term is used inconsistently. But to fix it, it needs to find every instance, check the context around each one, and make targeted edits in different sections.

Reddox handles this through multi-turn tool loops. The AI calls a read tool, processes the result, decides what to do next, calls an edit tool, reads again to verify the change, and continues until the task is complete. This read-think-act cycle is what allows Reddox to handle complex, document-wide operations that a single-shot AI cannot.

## What This Means for Your Practice

The practical impact is straightforward. You give Reddox an instruction. It executes the instruction directly in your document. You review the result using the same accept/reject workflow you already know.

No copying. No pasting. No reformatting. No switching between a chat window and your document. The AI works inside Word because that is where lawyers work. [Sign up for free](/signup) and try it on your next contract.


What Are AI-Callable Tools and Why Do They Matter for Legal AI?



Here is a scenario most transactional attorneys have encountered. A 40-page operating agreement goes through six rounds of negotiation. Both sides sign. Three months later, a dispute arises because the definition of "Net Revenue" in Section 2.1 does not match how the term is used in the distribution waterfall in Section 8.4. One section uses a capitalized defined term. The other uses a lowercase variation that was never actually defined. Nobody caught it during review.

This is not a hypothetical. Defined term inconsistencies are one of the most common sources of ambiguity in executed contracts, and they are also one of the hardest things to catch manually.

## Why Manual Review Fails Here

A typical commercial contract might contain 30 to 80 defined terms. Each term is defined once but used dozens of times throughout the document. To verify consistency manually, an attorney would need to identify every defined term, note its exact definition, then check every instance where it appears to confirm the usage matches the definition.

For a 50-page contract with 60 defined terms, this is not a 10-minute task. It is a multi-hour exercise in Ctrl+F and careful reading. Most attorneys, under time pressure, do a spot check at best. They verify the key commercial terms and hope the rest are consistent.

That hope is where problems start.

## The Four Types of Defined Term Errors

Reddox's defined term checker looks for four categories of issues.

**Inconsistent casing.** A term is defined as "Confidential Information" but later used as "confidential information" or "confidential Information." In some jurisdictions and under some drafting conventions, the lowercase version is not the defined term. It is a general use of those words, which may carry a different meaning.

**Unused definitions.** A term is defined in the definitions section but never appears anywhere else in the document. This usually means the definition was carried over from a template and never cleaned up. It adds clutter and can create confusion about whether the drafter intended to use it.

**Undefined usage.** A term is capitalized and used as if it were a defined term, but no definition exists anywhere in the document. This is the most dangerous category because it creates genuine ambiguity. The parties may have different understandings of what the term means.

**Conflicting definitions.** A term is defined in one section and then effectively redefined in another, either through a "notwithstanding" clause or through a narrower or broader restatement. This creates internal contradictions that may not surface until a dispute. When reviewing against a [reference document](/blog/reference-doc-comparison-explained), these conflicts become even easier to spot because the system can compare defined terms across both documents.

## How Automated Checking Works

Reddox extracts defined terms using three detection methods. It identifies parenthetical definitions, where a term is introduced in quotation marks followed by "means" or similar language. It catches terms defined with smart quotes or bold formatting. And it identifies section-header definitions where an entire section serves as the definition of a term.

Once extraction is complete, the system builds a map of every defined term and every location where it appears. It then runs consistency checks across the full document, flagging any of the four error types described above.

The results appear in the Reddox task pane. Each flagged issue includes the term, the type of error, and the specific locations in the document where the inconsistency occurs. You can click any result to navigate directly to the relevant text.

## Real-World Impact

Defined term checking is one of those features that sounds incremental until you use it on a real document. The first time you run it on a contract you thought was clean and it surfaces four undefined terms and two casing inconsistencies, the value becomes obvious.

For firms that handle volume, the impact is multiplied. If every contract that leaves the firm has been through automated term checking, the baseline quality of your work product goes up. Fewer ambiguities survive into execution. Fewer disputes arise from drafting errors. And the time attorneys spend on manual Ctrl+F verification drops to near zero.

## Building It Into Your Workflow

The defined term check runs with a single click in the Reddox task pane. It works on any document type and does not require you to upload anything to a separate platform. Open the document in Word, click Check Defined Terms, and review the results. Learn more about how the full toolkit works on the [product page](/product).

For firms that want to build this into their standard review process, it pairs naturally with [playbooks](/blog/playbooks-for-consistent-contract-review). A custom playbook can include defined term checking as one of its steps, ensuring that every review automatically includes a consistency audit alongside the substantive redline.

Consistency in defined terms is not glamorous work. But it is the kind of work that separates a thorough review from one that merely looks thorough. And it is exactly the kind of work that AI handles better than humans. [Sign up](/signup) and run your first defined term check in minutes.


The Defined Term Problem: Why Contracts Break at the Definition Level


Reviewing an incoming contract against your firm's standard is one of the most common tasks in transactional law. You open two documents, put them side by side, and start reading. Section by section. Clause by clause. Hoping you catch every deviation before the redline goes out.

It works. But it is slow, it is manual, and it depends entirely on the reviewer's attention to detail across what might be 40 or 50 individual provisions.

## The Side-by-Side Problem

Manual comparison has two fundamental weaknesses. First, it requires the reviewer to hold the standard language in memory while reading the incoming language. For common clauses like confidentiality or governing law, experienced attorneys can do this quickly. For less familiar provisions or complex commercial terms, the mental load adds up.

Second, manual comparison is linear. You read from top to bottom, and if the incoming contract organizes its sections differently than your template, you have to hunt for the corresponding clause. A confidentiality provision in Section 5 of your template might appear in Section 11 of the incoming contract. Or it might not appear at all, and you will not realize it is missing until you reach the end of the document.

## How Clause Comparison Works in Reddox

Reddox solves both problems with a structured clause comparison view. When you have a reference document loaded in your library, Reddox extracts individual clauses from both documents, matches them by type and subject matter, and presents them side by side.

On the left, your reference clause. On the right, the corresponding clause from the incoming contract. Each pair gets a status badge: match, deviation, or missing.

A **match** means the incoming clause is substantively aligned with your standard. The language may not be identical word for word, but the substance is equivalent. You can move on with confidence.

A **deviation** means there are meaningful differences between your standard and the incoming language. The comparison view highlights what changed so you can evaluate whether the deviation is acceptable or needs to be redlined back to your position.

A **missing** badge means the incoming contract does not include a clause that your reference template contains. This is often the most valuable finding, because missing clauses are the hardest things to catch in a linear read-through. You do not notice what is not there.

## What Makes This Different from Word's Built-In Compare

Word has a built-in document comparison tool. It produces a redline showing every difference between two documents. The problem is that it compares everything: formatting, spacing, section numbering, defined term capitalization, and substantive changes all appear in the same markup. On a 30-page contract, this produces hundreds of tracked changes, most of which are noise.

Reddox's clause comparison is substantive, not textual. It compares the meaning and coverage of individual clauses, not the character-by-character differences between two files. A clause that uses slightly different wording to express the same obligation shows as a match. A clause that changes a material term shows as a deviation. The distinction between signal and noise is built into the comparison logic.

## How Clause Matching Works

The matching engine does not rely on section numbers or headings alone. It uses content analysis to identify what each clause covers and matches them accordingly.

If your template has a "Governing Law" clause in Section 12 and the incoming contract has a "Choice of Law" provision in Section 8, the engine recognizes that both clauses address the same topic and pairs them for comparison. Different labels, different locations, same subject matter.

This is important because contracts from different parties rarely follow the same organizational structure. Your NDA template might put confidentiality obligations in Section 3. The incoming NDA might put them in Section 6. Without intelligent matching, you would be comparing unrelated clauses or missing the match entirely.

## Using Clause Comparison in Your Workflow

The typical workflow is straightforward. Upload your gold-standard template to the [reference doc library](/blog/reference-doc-comparison-explained). When an incoming contract arrives, open it in Word, select your reference template in the Reddox task pane, and run the comparison.

The results appear in the clause comparison view. Scan the status badges first. Matches can be skipped. Missing clauses need immediate attention. Deviations need review.

For deviations, you can ask Reddox to automatically redline the incoming document to bring the deviating clause in line with your standard. The redline appears as a native Word tracked change, ready for you to accept, modify, or reject. Learn more about the full feature set on the [product page](/product).

## Clause Comparison and Playbooks Together

Clause comparison works especially well in combination with [playbooks](/blog/playbooks-for-consistent-contract-review). A playbook tells the AI which issues to focus on and what your position is. The clause comparison shows where the incoming language deviates from your standard. Together, they give the AI both the strategic context (from the playbook) and the specific language benchmark (from the reference template).

A landlord-side lease review with both a playbook and a reference template active will catch deviations at two levels: substantive issues the playbook flags (like tenant termination rights) and language deviations the clause comparison identifies (like a different CAM reconciliation formula).

## Why This Matters at Scale

For firms that review 10 or 20 contracts of the same type each month, clause comparison eliminates the most tedious part of the process. The first review against a reference template takes 5 minutes instead of 90. Every subsequent review of the same contract type uses the same template and produces the same structured comparison.

The consistency gain is just as important as the time savings. When every NDA review runs against the same reference template, the firm's standard is enforced uniformly. No clause gets missed because the reviewer was in a hurry. No deviation slips through because it appeared in an unexpected section of the document.

The reference template holds the standard. The clause comparison enforces it. The attorney makes the final call. [View pricing](/pricing) and start running clause comparisons today.


Clause Comparison: How Reddox Shows You Exactly Where a Contract Deviates



One of the persistent challenges in legal practice is consistency. Two attorneys at the same firm, reviewing the same type of contract, will often produce different redlines. Not because one is wrong and the other is right, but because they have different habits, different priorities, and different levels of experience with that document type.

Partners know this. It is why senior attorneys spend time reviewing the work of junior attorneys, why firms develop internal checklists, and why some practice groups hold training sessions on how to approach specific contract types. These are all attempts to solve the same problem: making sure the firm's standards are applied uniformly.

Playbooks are a more direct solution.

## What a Playbook Is

A playbook in Reddox is a set of instructions that tells the AI how to review a specific type of document. It encodes your firm's position on the issues that matter for that document type.

For example, a landlord-side lease playbook might include instructions like: ensure the indemnification is one-sided in favor of landlord, flag any tenant termination rights that are not tied to landlord default, verify that the CAM reconciliation language matches our standard, and check that the assignment clause requires landlord consent.

A playbook for reviewing incoming NDAs from the disclosing party's perspective might say: ensure the definition of confidential information is broad, flag any carve-outs from the non-disclosure obligation, verify the term is at least three years, and check that the remedies clause includes injunctive relief.

Each playbook captures the judgment calls your best attorneys make on that document type. The AI then applies those judgments consistently, every time.

## Built-In vs. Custom Playbooks

Reddox ships with built-in playbooks for common review scenarios. These include general risk review, landlord-side review, tenant-side review, lender-side review, indemnification review, and a few others. They are designed to cover the most frequent use cases out of the box.

But the real power is in custom playbooks. Every firm has positions that are specific to their practice, their clients, and their risk tolerance. A real estate firm in Texas has different standards than a tech company's in-house team in San Francisco. Custom playbooks let you encode those differences.

Creating a custom playbook takes a few minutes. You write the instructions in plain English, save the playbook, and it becomes available in the task pane for any future review. There is no special syntax or configuration language. If you can describe your review approach to a junior associate, you can write a playbook. See how it works on the [product page](/product).

## How Playbooks Change the Review Process

Without playbooks, every review starts with the attorney deciding how to approach the document. What issues to focus on. What the client's position is. What the firm's standard language looks like for each clause. This decision-making process takes time and varies from person to person.

With playbooks, those decisions are made once and applied forever. The first-year associate who clicks "Review as Landlord" gets the same review that the partner who wrote the playbook would produce. The instructions are explicit, the AI follows them, and the output is a marked-up document with tracked changes and [confidence ratings](/blog/confidence-scoring-how-to-triage-a-redline).

This has three practical benefits.

**Training acceleration.** New associates do not need months of mentorship to learn how the firm approaches a specific document type. The playbook encodes that knowledge. They run the playbook, review the results, and learn the firm's standards through the markup itself.

**Quality floor.** Even on busy weeks when review time is compressed, the baseline quality stays high. The playbook does not get tired, does not skip sections, and does not forget that the firm always flags one-sided indemnification.

**Partner leverage.** Senior attorneys can encode their expertise into playbooks and distribute them to the team. The partner's judgment scales across every review the team runs, without the partner having to personally review each document.

## Building Effective Playbooks

A few principles make playbooks more effective.

Be specific. "Review this lease" is too vague. "Review this lease from the landlord's perspective, flag any tenant-favorable termination rights, ensure the indemnification runs to landlord only, and verify that the insurance requirements match our standard" gives the AI clear instructions.

Focus on your firm's positions. The built-in playbooks cover general best practices. Your custom playbooks should capture what makes your firm's approach different. The clauses you always negotiate. The language you always use. The issues your clients care about most.

Iterate. Run the playbook on a few documents and review the results. If the AI misses something you expected it to catch, update the playbook instructions. If it flags something that is not relevant, refine the scope. Playbooks improve as you use them.

## Playbooks and Reference Docs Together

Playbooks and [reference docs](/blog/reference-doc-comparison-explained) complement each other. The playbook tells the AI how to think about the document. The reference doc tells it what your standard language looks like.

When both are active, the AI has full context. It knows your firm's position on each issue (from the playbook) and it knows your firm's preferred language (from the reference template). The combination produces reviews that are both substantively correct and stylistically consistent with your firm's drafting.

## The End Goal

The goal is not to remove attorneys from the review process. It is to remove the variability. Every contract that leaves your firm should reflect the firm's standards, regardless of who ran the review, what day of the week it was, or how many other deals were running in parallel.

Playbooks make that possible. They turn institutional knowledge into a repeatable, automated process that every attorney on the team can use. [View pricing](/pricing) and start building your first playbook today.


Playbooks: How to Standardize Contract Review Across Your Team



Most AI contract review tools look at one document at a time. You upload a contract. The AI reads it. It flags issues. Done.

But real transactions do not work that way. A typical commercial deal might include a master services agreement, a statement of work, one or two side letters, and a prior amendment. Each document references the others. The SOW incorporates the MSA by reference. The side letter modifies a specific provision of the MSA. The amendment changes the payment schedule.

If the AI only sees the document you are currently reviewing, it misses everything that depends on those cross-references.

## The Cross-Document Problem

Here is a concrete example. You are reviewing a new SOW that references a master services agreement. The SOW says "Services shall be performed in accordance with the standards set forth in the MSA." The AI, looking only at the SOW, cannot evaluate whether the service standards in the MSA are adequate, whether they have been modified by a prior amendment, or whether there is a side letter that carves out an exception.

Without the MSA, the AI cannot tell you that the liability cap in the SOW conflicts with the cap in the master agreement. It cannot flag that the termination provisions in the SOW are more restrictive than what the MSA allows. It cannot identify that a defined term used in the SOW was redefined in Amendment No. 2.

These are not edge cases. In any multi-document transaction, the most important issues often live at the intersection of the documents. And a single-document AI is blind to all of them.

## How Deal Context Works in Reddox

Reddox lets you upload related transaction documents as deal context. Before you run a review on the current document, you add the MSA, the prior SOW, the side letters, and any amendments to the deal context panel in the task pane.

When the AI reviews the current document, it has access to the full text of every document you uploaded. It can cross-reference defined terms across documents. It can check whether provisions in the current document are consistent with the master agreement. It can identify conflicts between the current document and prior amendments.

The deal context documents are not modified. They serve as reference material. The AI reads them for context and applies edits only to the document you are actively reviewing.

## What the AI Can Catch

With full deal context, the AI can identify several categories of issues that single-document review misses.

**Defined term conflicts.** A term defined in the MSA is redefined differently in the SOW. Or a term used in the current document was never defined in any of the related documents. This pairs well with [reference doc comparison](/blog/reference-doc-comparison-explained), which can check each document against your firm's standard templates.

**Provision conflicts.** The liability cap in the SOW is lower than the cap in the MSA. The termination-for-convenience provision in the current document contradicts the termination provisions in the master agreement. The [clause comparison view](/blog/clause-comparison-view-explained) makes these conflicts easy to see side by side.

**Missing cross-references.** The SOW references a section of the MSA that was deleted in Amendment No. 1. Or the side letter references a payment schedule that was superseded.

**Scope gaps.** The SOW describes services that fall outside the scope of the MSA. Or the current document includes obligations that are not addressed in any of the related agreements.

**Inconsistent standards.** The confidentiality obligations in the SOW are weaker than those in the MSA. The indemnification in the side letter is broader than what the MSA provides.

## Practical Applications

Deal context is especially valuable in a few scenarios.

**Amendment review.** When reviewing a proposed amendment, uploading the original agreement and all prior amendments lets the AI check for cascading effects. Does the change to Section 4.2 affect the cross-reference in Section 8.1? Does the new payment schedule conflict with the existing cap?

**SOW review under a master agreement.** Every SOW exists in the context of its MSA. Reviewing the SOW without the MSA is like reading Chapter 5 without having read Chapters 1 through 4.

**Multi-party transactions.** Joint venture agreements, partnership documents, and multi-party commercial arrangements often involve several related agreements. Deal context lets the AI see the full picture.

**Due diligence.** When reviewing a set of contracts for a transaction, uploading related documents as context helps the AI identify issues that only become apparent when the documents are read together.

## Setting Up Deal Context

Adding deal context is simple. In the Reddox task pane, click the Deal Context panel and drag in the related documents. They are parsed and indexed automatically. When you run your next review, the AI includes them in its analysis. See how it works on the [product page](/product).

You can add and remove documents from deal context at any time. If you are reviewing a series of SOWs under the same MSA, the MSA stays in your deal context while you swap in each SOW for review.

## Why This Matters

Contracts do not exist in isolation. They exist in the context of a transaction. An AI that cannot see that context is solving the wrong problem. It might produce a technically correct review of the document in front of it, but it will miss the issues that arise from the relationships between documents.

Those are often the issues that matter most. [Sign up for free](/signup) and try deal context on your next multi-document review.


Reviewing Contracts in Context: Why Single-Document AI Falls Short



You just ran a Reddox review on a 25-page services agreement. The AI produced 32 tracked changes and 8 comments. That is a thorough review, but now you are looking at a document full of red markup and you need to decide what to focus on.

If every edit were equally important, you would have to read through all 32 changes carefully. But they are not equally important. Some edits address critical risk issues that could expose your client to significant liability. Others are recommended improvements that strengthen your position. And some are optional refinements that improve precision but are not essential.

Reddox tells you which is which.

## The Three Confidence Levels

Every [tracked change](/blog/why-tracked-changes-matter-more-than-suggestions) and comment that Reddox produces is tagged with one of three confidence levels.

**Critical** edits address issues that represent significant legal risk. These are the changes you should review first and almost certainly accept. Examples include removing a unilateral termination right that benefits only the counterparty, adding a liability cap where none exists, flagging an indemnification obligation that is uncapped and one-sided, or correcting a defined term that is used but never actually defined.

Critical edits are the ones that, if missed, could result in a material adverse outcome for your client.

**Recommended** edits address issues that improve your client's position but may involve negotiation trade-offs. These are changes you should review carefully and likely accept, but where you might choose to modify the approach based on the specific deal dynamics. Examples include tightening a broad force majeure clause, adding a notice requirement to a termination provision, or strengthening a representations section.

Recommended edits represent good lawyering. They make the contract better, but their absence would not necessarily create an emergency.

**Optional** edits address stylistic, structural, or minor substantive improvements. These are changes that improve the document but that you might choose to skip depending on time pressure, deal dynamics, or negotiation strategy. Examples include standardizing defined term formatting, adding clarifying language to an unambiguous provision, or reordering sections for better logical flow.

Optional edits are the polish. They matter, but they are the first thing you drop when you are under time pressure.

## How to Use Confidence Levels in Practice

The confidence tags create a natural triage workflow.

**First pass: Critical only.** Scroll through the document and review every edit tagged as critical. These represent genuine risk issues. Read each one, understand the AI's rationale (included in the comment), and accept or modify. This pass usually takes two to three minutes on a typical contract.

**Second pass: Recommended.** If you have time and the deal warrants it, review the recommended edits. These improve your position and demonstrate thoroughness to your client. On a high-value deal, you review all of them. On a routine NDA, you might skim and accept in bulk.

**Third pass: Optional.** On important documents where you want a polished final product, review the optional edits. On routine documents or when time is short, skip them. They are nice to have, not need to have.

This three-pass approach means you can handle a 30-edit redline in under five minutes if needed. Review the 6 critical edits carefully, quick-scan the 14 recommended edits, and defer the 10 optional edits for later or skip them entirely.

## How the AI Assigns Confidence

The AI assigns confidence levels based on several factors. The severity of the legal risk if the issue is not addressed. The degree to which the current language deviates from standard market terms. The potential financial impact of the provision. And the specificity of any playbook instructions that apply.

For example, if your [playbook](/blog/playbooks-for-consistent-contract-review) says "ensure all indemnification is mutual," a one-sided indemnification clause will be flagged as critical because it directly contradicts an explicit instruction. A missing "best efforts" qualifier on a performance standard might be tagged as recommended because it improves the position but does not create an immediate risk.

The confidence assignment also accounts for document type. A missing liability cap in an enterprise SaaS agreement is critical. The same missing cap in a short-term consulting engagement might be recommended, because the risk profile is different.

## Confidence Levels and Client Reporting

Confidence tags are also useful for client communication. When you send a redline to your client for approval before sending to opposing counsel, the confidence tags help them understand your priorities.

"We made 28 edits. Six are critical risk issues we strongly recommend you insist on. Fourteen are improvements that strengthen your position. Eight are optional refinements." That kind of summary gives the client a clear framework for reviewing your work and making decisions about negotiation strategy.

If you export a Reddox review report, the confidence levels are included in the output. The report groups edits by confidence level, making it easy for anyone reviewing the markup to understand the priority structure. Explore the full feature set on the [product page](/product).

## The Goal

The goal of confidence scoring is not to make decisions for you. It is to organize the information so you can make decisions faster. Every edit still needs your professional judgment. But instead of reading 30 edits with equal attention, you can allocate your attention where it matters most.

On a Monday morning with five contracts in your inbox, that distinction is the difference between a managed workload and an overwhelming one. [Sign up for free](/signup) and see how confidence scoring changes your review workflow.


Confidence Scoring: How to Triage a 30-Edit Redline in Under Five Minutes



There is a problem that every AI writing tool shares, and it becomes especially visible in legal contract review. When an AI edits text, it tends to rewrite more than necessary. Ask it to change "best efforts" to "commercially reasonable efforts" and it might rewrite the entire sentence. Or the entire paragraph. The AI does not think in terms of minimal edits. It thinks in terms of complete outputs.

For most applications, this is fine. In contract review, it is a serious problem.

## Why Paragraph-Level Edits Break the Workflow

When an attorney sends a redline to opposing counsel, every [tracked change needs to be readable](/blog/why-tracked-changes-matter-more-than-suggestions). The receiving attorney looks at each change, understands what was modified, and decides whether to accept or push back. That process depends on being able to see exactly what moved.

If the AI changed two words but the tracked change shows an entire paragraph as deleted and reinserted, the receiving attorney cannot tell what actually changed without reading both versions carefully and comparing them manually. The redline becomes a wall of red. It obscures the substance of the edit instead of highlighting it.

This is not a theoretical concern. It is the primary reason most attorneys distrust AI-generated redlines. The markup looks sloppy, even when the underlying edit is correct.

## How the Diff Engine Works

Reddox solves this with a word-level diff engine built on a longest common subsequence (LCS) algorithm. Here is what happens when the AI applies an edit.

First, the AI generates the edit. It specifies the original text and the replacement text. At this stage, the replacement might be a full paragraph rewrite even though only a few words changed.

Second, the diff engine takes the original text and the replacement text and breaks both into individual words. It then computes the longest common subsequence of words between the two versions. This identifies which words stayed the same and which words changed.

Third, the engine generates micro-edits. Each micro-edit targets only the specific words that changed. If the AI rewrote a 50-word paragraph but only three words are different, the engine produces three small tracked changes instead of one large one.

Fourth, each micro-edit is applied as a native Word tracked change through the Office API. This is one of the [29 AI-callable tools](/blog/what-are-ai-callable-tools) that Reddox uses to work directly inside your document. The result is a document where only the actual changed words appear in red, and the rest of the paragraph stays clean.

## A Concrete Example

Consider this original clause:

"Seller shall use best efforts to deliver the Goods within thirty (30) days of the Effective Date."

The AI decides to change "best efforts" to "commercially reasonable efforts" and "thirty (30) days" to "forty-five (45) business days." It generates a replacement:

"Seller shall use commercially reasonable efforts to deliver the Goods within forty-five (45) business days of the Effective Date."

Without the diff engine, this would appear as a single tracked change: the entire sentence deleted and the entire sentence reinserted. The receiving attorney would have to read both versions to figure out what moved.

With the diff engine, the result is two targeted tracked changes. "best efforts" shows as deleted and "commercially reasonable efforts" shows as inserted. "thirty (30) days" shows as deleted and "forty-five (45) business days" shows as inserted. The rest of the sentence is untouched.

The difference in readability is dramatic. One version is a clean, professional redline. The other is a red mess.

## Technical Challenges

Building a word-level diff engine for legal documents involves several challenges that do not arise in general-purpose text diffing.

**Document size.** The LCS algorithm has quadratic complexity. For long documents, this can be expensive. Reddox handles this by diffing individual edit pairs rather than the entire document at once. Each edit is diffed independently, keeping the computation manageable.

**Overlapping edits.** When the AI makes multiple edits in close proximity, the micro-edits can overlap. The engine includes overlap detection and merging to ensure each tracked change is applied cleanly without conflicting with adjacent changes.

**Pre-flight validation.** Before applying any edit, the engine verifies that the target text exists in the document at the expected location. If the document has changed since the AI read it (for example, due to a prior edit in the same session), the engine detects the mismatch and adjusts.

**Fallback handling.** In rare cases where micro-editing fails (for example, due to complex formatting or embedded objects), the engine falls back to the full edit. A single paragraph-level tracked change is better than a failed edit. But in practice, the word-level diff succeeds on the vast majority of edits.

## Why This Is a Core Feature

The diff engine is not a nice-to-have. It is what makes Reddox's output usable in real practice. A redline that opposing counsel cannot read is worse than no redline at all, because it creates the impression of sloppy work even when the substance is correct.

Surgical tracked changes communicate precision. They tell the receiving attorney that every word was chosen deliberately. They make the review process faster for both sides. And they maintain the professional standard that transactional practice requires.

The AI handles the substance. The diff engine handles the presentation. Together, they produce redlines that look like they were done by a meticulous human attorney, not by a machine that rewrites paragraphs wholesale. See it in action on the [product page](/product), or [sign up for free](/signup) and try it on your next contract.


Reddox Blog