Inside the Word-Level Diff Engine: How Reddox Makes Surgical Tracked Changes

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. 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 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, or sign up for free and try it on your next contract.