01The problem

Why comparing versions takes so long

Specifications get reissued. A designer sends revision C, and somewhere in two hundred pages a material has changed, a tolerance has tightened, or a clause has been added that puts a cost on you.

Finding those changes is somebody senior reading both versions side by side for an afternoon, and it is exactly the kind of work people put off. When it gets skipped, the change is discovered on site, which is the most expensive place to discover anything.

Contracts have the same problem with higher stakes. The version you are asked to sign is rarely the version you sent, and the difference between them is where the risk sits. Reading a contract properly takes hours, so it gets skimmed, and the clause that matters is the one nobody read.

02What we built

What we built: specification and contract comparison

We build the AI inside APSIS Business Components, a construction software platform. Two of the capabilities in it deal with documents that change.

Specification comparison takes the old version and the new one and reports what actually changed. Contract review takes the contract you sent and the contract you got back, and finds where the risk has moved. You can then ask it questions in plain English about what a clause means for you.

03How it works

How the comparison works

Comparing documents sounds simple and is not. A page can look identical and read differently, and it can look completely different because a paragraph moved and read exactly the same.

So the comparison runs two ways at once, independently. One looks at the pages as pages, and catches anything that moved, was added or was removed. The other reads both versions as language, and catches the changes that matter but do not look like anything: a material substituted, a figure altered, a requirement that used to be optional.

Each of those runs and reports on its own. If one finishes and the other is still working, you see that, rather than staring at a spinner wondering which part failed. If something goes wrong, the comparison can be run again and the new attempt keeps a link to the one it replaced, so there is a history rather than a mystery.

And as everywhere else in the platform, when someone corrects what the AI found, the system keeps both: what the AI said, what it was changed to, and who changed it. On a specification that matters, because the record of what changed is the thing you will be arguing from later.

04Contracts

Asking a contract questions

Contract review works the same way, comparing what you sent against what came back, and it adds something the specification side does not need.

You can ask it questions. What is our liability if the programme slips. Does this cap our exposure or theirs. What changed about payment terms. The answer comes back with the part of the document it came from, so you are reading the actual clause rather than trusting a summary.

That last point is the whole design. An answer without its source is an opinion, and nobody should make a contractual decision on an opinion from software. An answer with the clause attached is a shortcut to the paragraph you needed to read, which is genuinely useful and safe to act on.

Corrections here are recorded against the specific clause, so a note that "our reading of clause 14.3 differs" survives, with the name of whoever made it.

05Why it matters

Why finding changes early matters

Every change in a reissued specification has a price, and the price goes up the later it is found. Caught at review, it is a conversation and possibly a variation. Caught on site, it is rework, delay and an argument about who should have spotted it.

The same is true of a contract. A clause read before signing is a negotiation. The same clause read after signing is a loss.

None of this replaces the person doing the reviewing. It puts the differences in front of them in minutes, so the hours they spend go on judging what the changes mean rather than on hunting for them.

See how the same platform reads drawings and schedules →

06Where it sits

The other capabilities in the platform

Comparing documents is one of the things we have built into the APSIS platform over more than a year. The others: reading drawings and schedules, processing procurement paperwork, pricing quotes, drafting bids and answering questions from project documents.

They run on the same foundations. Each arrives faster than the last, and they work together. A specification compared in one place can be questioned in another. A change found in a reissue can be priced against the bill it affects. That is the advantage of building capability into a platform rather than bolting separate tools onto the side of a business.

It is also the reason this work has continued for over a year rather than ending at a pilot. Read how we build the AI inside the platform →

07What it does

How it works in practice.

Two ways of lookingOne pass sees the pages, the other reads the words, so a moved paragraph and a swapped material are both caught.
You can see it workingEach pass reports separately, so you know what has finished and what is still running.
Answers come with the clauseAsk a contract a question and get the part of the document the answer came from.
Corrections stickWhat the AI found and what a person changed it to are both kept, against the clause and the name.
Next

Start with one process.

Tell us where your team loses the most time. We will tell you honestly whether AI pays there, what it takes to build, and what we have already delivered for businesses like yours.