Insight
6.9.2026

AI-powered quality control: catching specification conflicts before they reach site

Most specification conflicts surface on site, where they cost the most. They could be caught weeks earlier, at the desk, before anyone breaks ground.

A specification conflict rarely announces itself. It sits quietly in a set of documents, a fire rating that says one thing in the spec and another on the door schedule, until a contractor finds it on site and sends an RFI. By then it costs money. So the question worth asking is why we keep finding these problems at the most expensive possible moment, when the information needed to catch them existed weeks earlier.

Where conflicts actually come from

Most specification conflicts aren't errors of knowledge. They're errors of coordination. An architect upgrades a window from double to triple glazing on the drawings, the schedule gets revised to suit, and the specification clause still quotes the old U-value. Each document is internally sensible. Read together, they contradict each other.

This happens because the documents that describe a building are written at different times, by different people, in different software. The spec lives in one system. The schedules live in a spreadsheet or inside Revit. The drawings sit somewhere else again. Nobody reads all three side by side, clause by clause, because doing that for a real project would take days that nobody has.

Version drift makes it worse. A project of any size goes through dozens of revisions, and each revision is an opportunity for one document to move while another stays put. The drawing register gets updated. The spec, which feels finished, doesn't get reopened. By tender, you can have three documents that were all correct on the day they were written and are no longer correct as a set. The conflict was introduced by the act of revising, not by anyone making a mistake.

What goes wrong, in concrete terms

Consider a few that turn up again and again. A door schedule lists FD30 fire doors, but the specification calls up an FD60 frame set for the same opening. A roof build-up in the spec gives a U-value that no longer meets the Part L figure quoted in the energy strategy. A window schedule references a product that was value-engineered out three revisions ago, while the spec still names it by manufacturer.

None of these is hard to understand once you see it. Each is almost impossible to spot when you're checking one document at a time, which is how documents are nearly always checked. The error isn't in any single place. It lives in the gap between two places.

The cost lands later, and it compounds. A mismatch caught at the desk is a five-minute edit. The same mismatch caught on site is an RFI, a pause while a trade waits for an answer, and often a variation with a price attached. Acoustic ratings between a party wall spec and the room data sheet, ironmongery sets that don't match the door types they're scheduled against, a balustrade height that reads differently in the spec and on the section. Small contradictions on paper, real delays in the ground.

Why manual review keeps missing them

Manual coordination relies on someone holding the whole project in their head. On a small job, one experienced architect might just about manage it. On anything larger, the knowledge is spread across a team, and the gaps appear at the seams, between the person who wrote the spec and the person who drew the details.

There's also the timing problem. Specifications are often finalised late, under deadline pressure, after the drawings have already moved on. The review that would catch a conflict competes with every other task in the run-up to a tender or a Building Regs submission. It usually loses that competition. Quality control becomes whatever you can manage at ten o'clock the night before issue.

Checklists help, but they don't scale the way the problem does. A good QA checklist will remind you to confirm fire ratings and U-values. It won't read every door in a hundred-door schedule against every clause in the spec. That kind of line-by-line cross-reference is exactly what people skip when time is short, and skipping it is invisible until it isn't. You only learn what you missed when the contractor tells you.

How AI-assisted conflict detection works in practice

This is where specification conflict detection changes shape. Instead of a person reading documents in sequence, an AI system reads them in parallel and looks for the places where they disagree. It cross-references the specification against the schedules, the drawings, and the relevant standards, then flags the contradictions for a human to judge.

Tools like Avoice work by ingesting a firm's own project documents, the sheets, specs, schedules, and material libraries, rather than checking against a generic clause library. That distinction matters, because a conflict is only a conflict relative to your project. Avoice uses AI agents to compare what the spec says against what the schedules and drawings say, and surfaces the mismatches: a fire rating that doesn't line up, a product that appears in one document and not another, a U-value that two sources quote differently. The work that used to depend on one tired person reading carefully becomes something a system does on every line.

Because it reads your own material, it gets sharper the more of your work it sees. A practice tends to repeat its detailing, its preferred products, and its standard clauses across projects, and a system that learns from that history knows what your documents normally say. So when a clause quietly drifts from your usual standard, there's a baseline to measure it against, rather than every project being treated as a blank sheet.

What AI catches, and what it doesn't

In practice the check runs across the whole document set at once. The system reads the specification, reads the schedules, reads the drawings and their annotations, and builds a picture of what each one claims about the same element. A fire door isn't just a line in a schedule. It's a fire rating, a frame set, an ironmongery reference, and an acoustic figure, each of which might be stated in a different document. The tool lines those statements up and reports where they don't agree.

The strength of automated checking is consistency. It doesn't get tired on the four hundredth clause. It doesn't assume the schedule is right because the schedule is usually right. It applies the same scrutiny to every line, which is exactly the kind of work humans are worst at and machines are good at.

What it doesn't do is decide what's correct. When the spec says FD60 and the schedule says FD30, the system can tell you they disagree. It can't tell you which one the design actually intends. That's a judgment call, and it stays with the architect. The value here isn't in replacing that judgment. It's in making sure the architect is asked the question at all, at the desk, before a contractor asks it from site.

Where the limitations show

Automated conflict detection is only as good as the documents it reads. If a schedule is buried in a PDF as a flattened image, or a spec is written in prose so loose that no two clauses use the same term for the same thing, the system has less to work with. Consistent classification helps. When documents are structured around recognised standards like Uniclass and CAWS, the relationships between them become legible to software, and Avoice structures its output around those standards for exactly that reason.

It's also fair to be honest about scope. Catching a contradiction between two documents is tractable. Judging whether a compliant detail is the right detail for this particular building is not, and no current tool should pretend otherwise. Conflict detection narrows the field of things you have to worry about. It doesn't empty it.

What this means for a small practice

For a small firm the appeal is plain. A two or three person practice doesn't have a dedicated QA function. The principal is the QA function, usually late and usually rushed. Shifting even part of that check onto a system that reads every document at once gives back hours and lowers the odds of the expensive surprise on site.

There's a professional risk angle too. Specification errors that reach site are a steady source of variations, and variations are a steady source of disputes. Anything that catches contradictions before issue lowers your exposure, not just your stress. For a practice carrying its own PI risk, fewer surprises in the documents means fewer arguments about who owns the cost of fixing them.

The same logic applied to hand-drafting before CAD, and to 2D drawing before BIM. Each time, a task that leaned on individual diligence became something a tool could support, and the profession adjusted. Specification coordination is next in that line. If you want to see how conflict detection performs on a real set of your own documents, Avoice offers demos tailored to your practice, run against the kind of project you'd actually issue.

The conflicts in your next set of documents already exist. The only thing left to decide is whether you find them at the desk, or whether the contractor finds them for you.

ready to start with avoice
Ready to leverage AI for your architecture and construction practice? From specification writing to submittal review, Avoice automates the admin work so your team can focus on design. Book a demo and see how we can transform your project delivery.
Arrow right icon
z
z
z
z
i
i
z
z
From workload to workflow
Try the AI workspace built for architecture.