The instinct when starting a new specification is to open a previous project file and start editing. Most architects have done it. You find a similar project, swap out the product names, update the clause references, and hope for the best. It works until it doesn't, and it usually fails quietly, surfacing as a coordination issue weeks into construction.
Better specification writing best practices start before a single clause is drafted. The first step is establishing a clear organisational framework. In the UK, that typically means Uniclass or CAWS classification, depending on the project and the client's requirements. Uniclass has become the default for most BIM-enabled projects, but CAWS still appears regularly on smaller schemes and renovation work. The classification system you choose shapes the entire document, so settle it early.
Once the framework is set, map out which sections your project actually needs. A residential extension doesn't require the same scope as a mixed-use development. Resist the temptation to include everything from a previous project's spec. Every unnecessary section creates maintenance overhead and, worse, potential contradictions with the drawings.
Ask any experienced architect where specification problems originate, and they'll point to coordination. The spec says one thing, the drawing shows another, and the contractor builds whichever version costs less. This isn't cynicism. It's rational behaviour when conflicting information is present.
Coordination failures happen for a predictable reason: specs and drawings are usually produced by different people at different times. The person detailing a window schedule in Revit may not be the same person writing the fenestration specification. Without a deliberate process to reconcile the two, discrepancies accumulate silently until someone prices the job or starts building it.
The practical solution is to build coordination checkpoints into your workflow. At minimum, cross-reference your spec sections against the drawing register at the end of RIBA Stage 3 and again before issuing tender documents at Stage 4. Check that product references match, that performance criteria align, and that anything described as "to architect's approval" actually has an approval mechanism defined somewhere.
Tools like Avoice are starting to automate parts of this process. By ingesting both specifications and project documentation, AI agents can flag inconsistencies between what the spec describes and what appears in schedules and drawings. That doesn't replace professional judgment, but it catches the sort of mismatches that human review misses under deadline pressure.
There's a particular style of specification writing that prioritises legal defensiveness over clarity. You've seen it: clauses nested four levels deep, cross-references to standards that cross-reference other standards, and sentences that need a law degree to parse. Specs written this way protect the architect on paper. They also guarantee that nobody on site will read them properly.
Good architectural specifications in the UK balance precision with readability. Each clause should do one job. If a clause covers material specification, installation method, and quality assurance all at once, break it apart. Contractors scan specs for the information relevant to their trade. Making that information easy to find reduces the risk of it being overlooked.
Be specific about products and performance. "High-performance glazing system" means nothing. "Double-glazed sealed unit, minimum U-value 1.2 W/m²K, to comply with Approved Document Part L 2021" gives the contractor something to price and the building control officer something to verify. Where you allow alternatives, state the criteria an alternative must meet. "Or equal and approved" without defined criteria is an invitation for substitution disputes.
Plain language matters more than most specification writers admit. "Shall" and "must" have specific contractual meanings, but the rest of the clause can be written in straightforward English. Short sentences. Active voice. Fewer subordinate clauses. The goal is a document that a site manager reads once and understands, not one that requires three readings and a phone call to the architect.
Some specification problems appear on almost every project. Knowing where they tend to occur makes them easier to prevent.
Copy-paste inheritance is the most common. Clauses from a 2019 project reference standards that have since been superseded. Product lines get discontinued, and the spec still calls for them by name. Building regulations change, and performance requirements lag behind. Every spec should be audited against current standards before issue, not after a contractor queries it during tender.
Another frequent problem is scope ambiguity between specification sections. If the external wall spec mentions a cavity barrier and the fire stopping spec also mentions a cavity barrier, who is responsible for supplying it? Overlapping scope creates gaps in pricing and, more dangerously, gaps in responsibility on site. Each item should appear once, in the section where it logically belongs, with clear cross-references elsewhere.
Overspecification can be as damaging as underspecification. Specifying a particular manufacturer's product when the client's brief allows for alternatives limits competitive tendering and drives up costs. Worse, it can create procurement delays if the specified product has long lead times. Specify by performance where possible, and reserve proprietary specifications for situations where a specific product is genuinely required by the design intent.
Many practices also underestimate the time required for specification writing. It gets squeezed into the final days before tender, produced under pressure, and reviewed inadequately. The result is a document full of the errors that proper time and attention would have prevented. Sound specification writing best practices start with allocating adequate time in the project programme, ideally beginning outline specs at RIBA Stage 3 rather than treating the whole exercise as a Stage 4 afterthought.
A specification isn't a document you write once. It evolves through RIBA Stages 3, 4, and 5, growing in detail and precision as the design develops. The practices that produce good specs treat them as living documents with version control, change tracking, and clear ownership.
Version control sounds obvious, but the reality in many firms is a folder of Word documents with names like "Spec_v3_FINAL_revised_ACTUAL.docx". When three people contribute to a spec over six months, tracking what changed and why becomes critical. At minimum, maintain a change log. Better still, use a system that tracks revisions automatically and ties changes to specific design decisions.
Ownership matters because specifications touch multiple disciplines. The architect writes the architectural spec, but mechanical, electrical, and structural consultants contribute their own sections. Without a clear spec coordinator, nobody takes responsibility for the document as a whole. Assign one person to own the spec, review consultant contributions, and resolve contradictions before they reach the contractor.
This is where platforms like Avoice offer a different approach. By structuring specifications as data rather than static documents, and classifying clauses under Uniclass and CAWS standards automatically, the spec becomes something a team can maintain without the overhead of manual version tracking. The firm's historical project data, material libraries, and standard clauses feed into each new project, reducing the rework that eats into every fee.
AI in specification writing is still early, but it's already practical for specific tasks. The question for most UK practices isn't whether to adopt it, but which parts of the workflow benefit most from it.
The clearest wins are in the repetitive, high-volume aspects of spec production: generating initial drafts based on project parameters, checking clause references against current standards, and flagging coordination issues between specs and other project documents. These are tasks that consume hours of a senior technologist's time on every project, and they're prone to human error precisely because they're tedious.
Avoice approaches this by deploying AI agents that act as digital teammates for the specification process. Rather than starting from a generic clause library, these agents draw on the firm's own project history, preferred products, and standard approaches. The output is a draft specification that reflects how the practice actually works, classified under the appropriate standards, and ready for professional review and refinement.
What AI doesn't replace is the architect's judgment about what to specify. Performance requirements, material choices, and design intent still need a human being with project context and professional accountability. The value of AI specification tools is in handling the administrative burden so that architects can spend their time on the decisions that actually shape the building.
For practices looking to improve their approach to specifications, the starting point isn't technology. It's process: establish a clear structure, coordinate rigorously with drawings, write for the people who will read the spec on site, and allocate proper time in the programme. Technology, whether that's Avoice or another tool, amplifies good process. It can't fix a broken one.
The practices writing the best architectural specifications in the UK five years from now will be the ones investing in both: better workflows today, and the tools that make those workflows faster and more reliable as projects grow in complexity.
