If you have written specifications for any length of time, you will recognise most of what follows. The point isn't to catalogue every possible error. It's to show you the small number of habits that cause the majority of problems, and why they keep happening even in good practices with experienced people. Most of them have nothing to do with talent and everything to do with time.
Good NBS clause writing is less about knowing the right words and more about discipline applied consistently across a document that nobody has time to read end to end. That tension, between the care a clause deserves and the hours a project allows, is the thread running through every mistake below.
NBS is built on a classification system. Work sections, and now Uniclass 2015 with its Pr and Ss codes, exist so that everyone reading the document knows exactly where to find a given requirement. A clause about cavity wall insulation belongs in a specific place. Put it somewhere else and you have not just created untidiness, you have broken the logic the contractor relies on to price and build.
The common mistake is treating the structure as a filing convenience rather than as part of the meaning. People drop a performance requirement into a product clause, or scatter related requirements across three work sections because that's where the source clauses happened to sit. The result reads fine to the author. It reads as a contradiction to the estimator who finds two different answers to the same question.
Good clause structure also protects you when something is missing. If your sections follow the standard arrangement, a gap is obvious. A reviewer can see that the roof section has no clause on the membrane. When the structure is improvised, gaps hide. Nobody notices the missing requirement until the wrong product turns up on site.
There is a quieter benefit too. A well-structured specification is reusable. The next project starts from a sound arrangement rather than from last time's improvisation, and the practice slowly builds a body of clauses it can trust. Treat structure as disposable and you start from scratch every time, which is how the same mistakes get rewritten into job after job.
This is the single most expensive habit in UK spec writing, and it shows up everywhere. A clause says the windows are to be installed as drawing, with no drawing number. A door type references a schedule that has since been renumbered. A fire-rated partition cites a detail that was superseded two issues ago. Each of these is a broken link, and broken links generate RFIs.
The specification, the drawings, and the schedules are meant to be one coordinated set. In practice they are three documents maintained by different people on different timelines. The window schedule gets updated after a client change. The spec doesn't. Now the schedule says one glazing specification and the clause says another, and the contractor has to stop and ask which one governs.
The fix sounds simple. Reference precisely, and check that what you reference still exists. The reason it stays broken is that no single person holds the whole picture at the moment of writing, and manual cross-checking across hundreds of clauses and dozens of schedules is exactly the kind of work people skip when a deadline is close. This is where tools like Avoice earn their place, by flagging inconsistencies between a specification and the schedules and drawings before the package goes out rather than after the contractor finds them.
Read a poorly written clause closely and you will often find that it does not actually require anything. Phrases like to be agreed, or similar approved, high quality, suitable for purpose, and as appropriate feel like specification. They are not. They defer the decision to a point in the project where deferring it is far more expensive.
Or equal approved is the classic example. Used carelessly, it invites the contractor to propose a cheaper substitute, and then puts you in the position of either approving something you didn't intend or rejecting it and arguing about programme. The clause was meant to maintain fair competition. Instead it hands away control of the very thing you were specifying.
The discipline here is to write performance you can actually test. Not high thermal performance, but a U-value. Not durable, but a stated service life or a named standard the product must meet. If a clause cannot be checked against an objective criterion, it is a wish, not a requirement. Ambiguous performance language is the third leg of the trio that causes most specification disputes, alongside broken cross-references and misplaced clauses.
Anyone who has worked with NBS knows the prompts. Optional text in square brackets. Guidance notes that explain how to complete a clause. Placeholder phrases waiting for a value. They exist to help you write, and they are not meant to survive into the issued document.
They survive far more often than they should. A spec goes out with insert thickness still sitting in the middle of a screed clause, or with three product options left in because nobody chose between them. It looks careless because it is, but the underlying cause is volume. A full specification runs to hundreds of clauses, and editing each one down to a single clean requirement is slow, repetitive work that rewards no one until it goes wrong.
That repetition is exactly what makes this part of NBS clause writing suited to AI assistance. Avoice ingests a firm's existing specifications, schedules, and material libraries and uses that history to draft clauses that are already resolved to the practice's standard choices, rather than leaving a field of brackets for someone to clean up under deadline pressure.
The coordination gap deserves its own heading because it causes a particular kind of damage. When a specification and a schedule disagree, the contractor is entitled to build to either, and will usually build to whichever is cheaper or easier. You then discover the conflict during a site inspection, when the cost of correcting it is at its highest.
This happens because specs and schedules are authored separately and reconciled rarely. A door schedule lists an ironmongery set. The spec describes a different set in its clause. Both were correct at some point. The schedule changed and the clause didn't, or the other way round. Neither author saw the mismatch because neither was looking at both documents at once.
The same logic applied to hand-drafting before CAD, and to 2D drawing before BIM. Each time, the profession moved from documents that had to be coordinated by memory and diligence to documents where the software held the relationships and surfaced the clashes. Specifications are the last major part of the architectural output still being coordinated largely by hand. That is starting to change, and it is the most useful thing the current generation of AI tools can do for spec writers.
One more mistake is worth naming because it only bites later. Clauses that cite standards or Approved Documents by a specific date or edition age badly. Part L moves. A British Standard gets revised. The clause that referenced the 2013 edition is now pointing at superseded guidance, and the spec quietly drifts out of compliance without anyone touching it.
The honest answer is that keeping references current across a back catalogue of specifications is more than most practices can do manually. You can write carefully and still fall behind, because the regulations change on their own schedule, not yours. Structuring specifications around recognised standards in a way that can be checked and updated systematically is one of the clearest arguments for treating spec content as structured data rather than as static prose, which is the approach Avoice takes by grounding its output in the firm's own documentation and the relevant Uniclass and CAWS classifications.
None of these mistakes come from a lack of skill. They come from the gap between how much care a good specification needs and how much time the average project allows for it. Clause structure, cross-referencing, performance language, editing out the prompts, coordinating with schedules, keeping references current. Each is straightforward in isolation. Together, across a full package under deadline, they are more than careful reading alone can reliably catch. This is why NBS clause writing remains one of the most underrated risks in a project, and one of the easiest to improve.
That is the real shift worth thinking about. For most of its history, specification quality has depended on one experienced person having the time and attention to get every clause right. The work hasn't got smaller, but the tools have finally got good enough to take on the repetitive, error-prone parts and leave the judgement to you. If you want to see how that works on a real specification, you can try the AI Spec Agent from Avoice on your own project and watch where it catches the things a tired reader would miss.
