Ask any contractor where projects lose money and they won't point at design. They'll point at the gap between documents. A window schedule that calls for one U-value while the spec calls for another. A floor finish named in the room data sheet that never appears in the specification at all. Each of these is small on its own. Together they generate requests for information, variations, and delay, and every one of those carries a cost.
The numbers add up faster than most firms realise. A single RFI costs the industry somewhere between £700 and £1,000 to process once you account for the time of everyone who touches it. A medium-sized project might generate hundreds. When a meaningful share of those trace back to a document that contradicts itself, the specification stops being a quality risk and becomes a budget line.
The reason a single specification error costs thousands rather than tens of pounds is that errors don't stay contained. Picture a curtain walling clause that specifies a glazing unit by reference to a discontinued product. On its own, a small slip. The contractor raises an RFI. The design team picks a replacement. The replacement has a different thickness, so the cill detail no longer works. The revised cill changes the head detail above it. The window schedule now needs updating, and so does the U-value calculation that fed the Part L submission. One wrong product reference has touched five documents and three disciplines.
That cascade is the real cost. The fee to fix the original clause is trivial. The fee to chase the consequences across a coordinated set of documents, under time pressure, with a contractor waiting, is not. This is why catching errors early is worth so much more than catching them well. An error found at RIBA Stage 4 is a five-minute amendment. The same error found during construction is a variation, a delay, and a difficult conversation about who pays.
The most common specification error in UK practice isn't a mistake in the spec itself. It's a disagreement between the spec and everything around it. Your specification says the external doors are powder-coated aluminium to a 25-year warranty. Your door schedule, updated three weeks later by someone else, lists a different finish. Both documents are internally correct. Read together, they're a problem.
This happens because specifications and schedules live in different files, owned by different people, updated on different days. Revit holds the schedule. The spec sits in a separate document, often in NBS or a Word file. Nobody owns the relationship between them. So when the schedule changes, the spec doesn't, and the contradiction waits.
A surprising number of specifications describe what a thing is without ever saying what it has to do. A roof build-up is named in full, every layer listed, but the U-value it has to achieve under Part L is missing. An acoustic partition is specified by construction but not by the sound reduction it needs to deliver. The contractor builds exactly what the document says and still misses the requirement, because the requirement was never stated.
Performance gaps are dangerous precisely because they pass review. The spec looks complete. It reads well. It names real products and real standards. Only when someone tests the finished element against Building Regulations does the omission surface, and by then it's built. Catching a missing performance figure on site costs a great deal more than catching it at RIBA Stage 4.
Fire is where this gets serious. Since the Building Safety Act, the expectation around a clear, traceable record of what was specified and why has hardened into law for higher-risk buildings. A specification that states a cladding system without its fire classification, or names a product whose certification doesn't cover the application, is no longer just a commercial risk. It's a gap in the golden thread that someone will eventually be asked to explain. Performance criteria that were once nice to have in writing are now part of the evidence trail.
Classification errors are quieter and more common than anyone admits. A firm reuses a specification from a previous project, which is sensible, but the Uniclass 2015 codes come along with it. A system coded as Ss_25 on the last job gets carried into a new one where it should sit somewhere else entirely. The clause reads fine. The classification underneath it is wrong.
This matters more as projects move toward structured data. When your specification feeds a model, a cost plan, or a client's asset database, a wrong code propagates. It miscategorises the element everywhere downstream. The error that started as a copy-paste convenience becomes a data problem that someone has to unpick months later. Tools like Avoice that classify specifications under Uniclass and CAWS as they're written, grounded in the firm's own data rather than a generic library, remove the temptation to carry an old code into a new context.
Specifying a named product is fine. Specifying it without an or-equal provision, on a project bound by procurement rules, is a specification error that can stall a tender. UK public work and much private work expects a fair route to competition. Name a single manufacturer with no equivalent allowed and you either restrict the field unlawfully or invite a stream of substitution requests that eat the same hours you were trying to save.
The fix is well understood. State the performance, name the reference product, allow equivalents that meet the stated criteria. The problem is consistency. On a large spec written under deadline, the or-equal language gets applied to some clauses and forgotten on others. The gaps stay invisible until procurement finds them.
So why does a careful review process miss errors this common? The answer is that human review is good at reading documents and poor at cross-referencing them. A reviewer reads the spec and it makes sense. They read the schedule and it makes sense. Almost nobody reads the spec with the schedule open beside it, clause by clause, checking that every figure agrees.
That's not a failure of diligence. It's a limit of attention. A specification can run to hundreds of pages. The schedule has hundreds of rows. The drawings number in the dozens. Holding all of that in your head at once, and noticing the one U-value that doesn't match, is not something people do reliably at four in the afternoon on a deadline. The errors survive because the checking method was never suited to the task.
This is the kind of work that suits a machine. Cross-referencing a specification against the schedules, the drawings, and the relevant Approved Documents is exactly the sort of patient, exhaustive checking that loses nothing to repetition. An AI agent doesn't get tired at clause 340. It reads the whole document set as one connected thing and flags the places where they disagree.
The starting point isn't a new piece of software for its own sake. It's a shift in where the check happens. Instead of a final read-through by one person at the end, the cross-checking runs continuously against the live document set, so a schedule change that breaks the spec gets flagged the day it happens rather than the month it ships. That changes the economics of the whole process. The expensive errors were always the ones found late, and moving the check earlier is the cheapest intervention available to a practice.
That's the approach Avoice takes. It ingests a firm's existing specs, schedules, and material libraries, then flags inconsistencies between the specification and the other project documents before they reach site. Rather than checking a spec against a generic clause library, it checks against the firm's own data and the standards the project is bound by. The specification errors that used to surface as an RFI in month eight surface instead as a flag in the office, while there's still time and it still costs nothing to fix.
None of this removes the architect from the work. Avoice doesn't decide what the building should be. It catches the contradictions that a tired reviewer was always going to miss, and it leaves the judgement where it belongs.
The firms that get ahead of this won't be the ones who review harder. They'll be the ones who stop relying on a person to hold two hundred pages in their head and start letting the documents check each other. The errors aren't going away. The question is whether you find them in the office or on site. If you'd like to see how that checking works on a real project, Avoice runs demos built around your own specifications.
