DocuDiff: Structured, AI‑Assisted PDF Comparison

Two versions of a long document land on your desk, a revised drawing package or an amended PO, sometimes hundreds of pages of it, and someone needs to answer "what changed?" before anything downstream can move. The question sounds simple. On manufacturing documents it almost never is, because the changes that matter live in structure that the PDF format does nothing to preserve.

The edits that matter are almost always small and structural: a BOM row where the material moves from 6061-T6 to 7075-T6, a tolerance added to a single dimension line, a PO line with a quiet unit-price drop and a UoM tweak riding along in the same revision, a clause that shifts a single verb and flips which side carries the risk. Each of those is a handful of characters inside hundreds of pages that mostly didn't change, and each one is expensive to miss.

Generic "PDF compare" tools miss them because they treat the file as a wall of characters. Tables get flattened into text, so a column that shifted by a few spaces lights up as a change while the material swap you actually care about sits buried in the same noise. Anyone who has run a drawing package through one of these tools knows the output: pages of highlighted reflow, with the real edits somewhere inside it.

Why handing both files to a model doesn't work either

The tempting shortcut now is to give a language model both documents and ask it what changed. For a two-page letter that works fine. For a drawing package or a long PO it runs into trouble, because two full documents rarely fit comfortably in a context window, so something gets truncated, and truncation on a comparison task means missed changes. Even when the files do fit, most of what the model reads is noise: headers, footers, title blocks, boilerplate repeated on every page. The model burns its capacity rediscovering the document's structure from scratch before it can get anywhere near the one line where the price moved.

And there's a deeper problem for anyone doing regulated work. When the model reports a change, you can't trace why it said that. There is no deterministic record underneath the claim to check it against, and my suspicion is that better models don't fix this, because what's missing is provenance. In an aerospace quality system, "the model said so" doesn't survive an audit.

The deterministic pass

So we built DocuDiff to run the whole thing in the other order: structure first, model last.

It's built for PDFs with selectable text, and the pipeline starts with the boring parts done carefully. Annotation-aware preprocessing strips embedded markups first, so a reviewer's comment sitting on top of the page doesn't masquerade as document content. Then the text gets segmented into logical chunks using title patterns you define, things like "BILL OF MATERIALS" or "TERMS", with a little context carried above each match so headings stay attached to the content they head.

The part that does the real work is a declarative rule engine that understands how tables actually appear in PDFs. A table in a PDF is usually just text spaced until it looks like a table, which is exactly why generic tools mangle it, and the rule engine deals with that using a small set of mechanisms. Regex anchors locate the repeating markers of a row, a line ID like "Line 120" or "Item 3.2". Span expansion widens the capture from that anchor out to the neighboring columns, even when the only alignment is whitespace. When a related value sits on the line above or below, a rule can hop up or down to pull it in. Secondary regexes then confirm that captured values have the right shape, so a price has to look like currency and a tolerance has to look like ±N.NN, and a check called check_empty asserts that the gap between two captures really is blank, which is how you avoid reading two adjacent columns as one merged cell. And every rule reports the first and last line it matched, so table regions get fenced off and kept out of the narrative diff entirely.

Chunks that carry a line ID get classified as line items, and that classification matters at diff time, because line items and narrative text want different treatment. Matched line items are compared field by field, so what you see is the add, the removal, or the changed value at the level of the field that moved. When the same edit occurs in every row, DocuDiff collapses it into a single entry, so a vendor rename shows up as "Vendor name normalized across 127 lines" rather than 127 separate diffs a reviewer has to wade through. Narrative differences in notes and clauses get reported on their own, without double-counting anything already caught in a table.

Then the model writes the brief

Only now does a language model get involved, and its job is deliberately small. It reads the structured deltas, already extracted and validated, and writes a short brief about what changed and where review attention should go first. The rule engine gives you auditable, repeatable diffs; the model turns structured deltas into a readable brief, nothing more mystical than that.

That ordering is the whole design, deterministic first and generative second, and it's what makes the summary trustworthy. When the brief says the unit price on a line dropped, the claim ties back to a captured field with its before and after values and the rule that harvested them. All of this machinery can stay hidden from the person reading the diff; what it buys is an output you can defend.

What this buys you when someone asks later

Run the same two PDFs through the same rules and you get the same diffs, every time, which sounds like a small thing until you're reconstructing a change record. Because every reported change carries its provenance, you can archive the rule definitions and the diff artifacts alongside the ECO or the PO record, and when someone asks two years from now why revision C went through with that material change, the answer is sitting in the file. DocuDiff writes both a human-readable change report and machine-readable JSON and CSV, so the same diffs can flow into PLM, ERP, review queues, or whatever gating workflow sits downstream.

The places this earns its keep are the ones where revisions are frequent and missing one is expensive. In aerospace configuration and quality work, that's BOM and tolerance changes buried in drawing packages, with note edits cleanly separated so they don't distract from the table changes. In procurement, it's price and UoM drift across PO line items, plus the clause edits that ride along in the same document and deserve their own careful read.