For decades, UK architects classified specification content using CAWS, the Common Arrangement of Work Sections. CAWS was originally published in 1987 and served the industry well for a long time. It organised specifications by trade, grouping information into work sections like L10 (Windows/rooflights/screens/louvres) or E05 (In-situ concrete). If you trained in the 1990s or 2000s, CAWS is probably in your muscle memory.
The problem was scope. CAWS was designed around how buildings get built on site, broken into packages of work that a contractor might subcontract. That made sense for procurement and tendering, but it struggled when the industry started thinking about buildings as digital assets with full lifecycle data. A window in CAWS is classified by the trade that installs it. A window in Uniclass 2015 is classified by what it is, what system it belongs to, and what products make it up. That distinction matters when your model needs to carry data from design through to facilities management.
Uniclass 2015 launched in April 2015 as part of the Digital Toolkit for BIM. It was designed to comply with ISO 12006-2, the international standard for organising construction information, and to support BIM Level 2 requirements. NBS maintains and updates the tables, which means the classification keeps pace with new products and systems as the industry evolves. CAWS, by contrast, is no longer actively maintained.
Uniclass 2015 uses a set of tables, each covering a different class of information. Think of them as layers of zoom. At the widest view, you have complexes and entities. At the closest, you have individual products.
The tables most relevant to specification writing are Co (Complexes), covering the overall project such as a university campus or hospital site; En (Entities), covering individual buildings or structures within a complex; SL (Spaces/Locations), describing rooms and functional areas; Ac (Activities), defining what happens in those spaces; EF (Elements/Functions), identifying main building components like walls, roofs, and floors; Ss (Systems), describing collections of components that together form an element; and Pr (Products), the individual items that make up a system.
For day-to-day spec writing, the three tables you'll use most are EF, Ss, and Pr. Elements tell you what part of the building you're dealing with. Systems tell you how that part is assembled. Products tell you what specific items go into that assembly. A roof, for instance, is the element (EF_30_10). A light steel roof framing system is the system (Ss_30_10_30_45). The individual steel beams and roofing clamps are products within that system.
This hierarchy is one of the genuinely useful things about Uniclass. Instead of scattering your roof specification across multiple CAWS work sections for steelwork, insulation, and finishes, everything sits under a single system code. Anyone reading the spec can understand the full construction sequence in one place.
Every Uniclass code follows a consistent pattern. The first pair of characters is always letters, identifying which table the code belongs to. Ss means Systems. Pr means Products. EF means Elements/Functions. After that, each pair of numbers represents a progressively finer level of detail: group, sub-group, section, and object.
Most tables use four pairs of characters. The Systems and Products tables use five pairs because they need finer granularity to accommodate the thousands of products and assemblies used in construction.
Take the code Ss_25_30_95. The Ss tells you this is a system. The 25 identifies the group (wall and barrier systems). The 30 narrows it to external wall sub-systems. The 95 specifies window systems. If you needed a particular type, say a precast concrete security window system, you'd go one level deeper to Ss_25_30_15_66.
The numbering uses pairs, which means each level can hold up to 99 entries. That gives the system plenty of room to grow as new products and assemblies enter the market. And because the structure is consistent across all tables, once you can read one code, you can read any of them.
The easiest way to get comfortable with Uniclass is to classify something you already know well. Take an external wall.
At the element level, external walls sit under EF_25_10_25. That tells you this is an element in group 25 (walls and barriers), sub-group 10 (walls), section 25 (external walls). Clear enough.
Now move to the system level. An external wall sheathing system would be Ss_25_25_95_28. A timber frame external wall system would carry a different code. The point is that the system code captures not just what part of the building you're describing, but how it's constructed.
At the product level, you're specifying the individual materials: the insulation boards, the vapour barriers, the cladding panels. Each gets its own Pr code.
This three-tier approach mirrors how architects actually think about buildings. You start with the broad design intent (you need an external wall), move to the construction logic (it will be a timber frame with external insulation), and finish with the material choices (this brand of mineral wool, that type of membrane). Uniclass formalises that thinking into a structure your BIM model and your specifications can both use.
For architects transitioning from CAWS, the mental shift is worth noting. Under CAWS, you'd open work section L10 to specify windows. Under Uniclass, you'd find the specific window system code in the Ss table. The advantage is precision: where CAWS lumped windows, rooflights, screens, and louvres into one section, Uniclass gives each a distinct code. That means fewer cross-references, less ambiguity, and specifications that are easier for contractors to price.
If you're writing specifications for a project that requires BIM compliance, Uniclass classification isn't optional. But even on projects where it's not mandated, using Uniclass brings real benefits to your spec workflow.
First, it creates consistency. When every project in your practice uses the same classification logic, specs become easier to template, reuse, and quality-check. A junior architect can find previous external wall specifications by searching the Ss code rather than remembering which project had that particular wall build-up.
Second, it connects your spec to your model. If your Revit families are classified with Uniclass codes, your specification can reference the same codes. That alignment between model and spec is exactly what design teams are expected to deliver on BIM-mandated projects. When the two don't match, it creates coordination gaps that surface as RFIs during construction.
This is where tools like Avoice become particularly useful. Avoice generates specifications classified under Uniclass, CAWS, NATSPEC, and CSI MasterFormat standards, so the classification is handled as part of the drafting process rather than bolted on afterwards. For practices still getting comfortable with Uniclass, that removes a significant source of friction. The AI agents within Avoice can ingest your firm's existing project documentation, including historical specs, material libraries, and schedules, then produce new specifications that cite the right standards, products, and clauses while applying the correct Uniclass codes.
Third, Uniclass-classified specs travel better. When your specification uses standard codes that contractors, engineers, and facilities managers all recognise, the risk of misinterpretation drops. Specification ambiguity is one of the most common sources of construction disputes, and consistent classification is a straightforward way to reduce it.
The most frequent mistake is classifying at the wrong level. Architects sometimes assign element codes (EF) to items that should be classified at the system (Ss) or product (Pr) level. A specification for a window should reference the system code, not the element code. The element tells you there is a window opening. The system tells you what kind of window goes in it. Mix these up and your spec will lack the detail contractors need.
Another common error is trying to map CAWS sections directly onto Uniclass codes one-to-one. The structures don't align that neatly. A single CAWS work section might split across several Uniclass system codes, or the reverse. NBS has published mapping spreadsheets that help, but the real answer is to learn Uniclass on its own terms rather than treating it as CAWS with different numbers.
A third pitfall is inconsistency between the model and the spec. If your Revit model classifies a curtain wall system with one Uniclass code and your spec uses a different one, you've created a coordination problem. Agree the codes early, ideally at RIBA Stage 2 when you're defining the information requirements, and make sure both the modelling team and the spec writer use the same reference.
Practices that use Avoice for specification writing can sidestep several of these issues. Because the platform flags inconsistencies between specifications and other project documents, mismatched codes get caught before they reach the contractor. That kind of automated cross-checking is difficult to replicate manually, especially on larger projects where specifications run to hundreds of pages.
Adopting Uniclass doesn't require a wholesale transformation. Start with one project. Pick a building type your practice does frequently, classify the main systems using the Ss table, and write the specification around those codes. Compare it to how you would have done it under CAWS. Most architects find the Uniclass approach cleaner once they're past the initial learning curve.
Build a small reference library of the codes you use most. External walls, roofing systems, window systems, floor finishes, and drainage systems will cover a large proportion of a typical building specification. Once those are familiar, the rest follows naturally.
If your team finds the classification overhead burdensome, consider using Avoice to handle the heavy lifting. The platform applies Uniclass classification automatically as part of the specification drafting process, drawing on your firm's own data and project history. That frees your architects to focus on design decisions rather than looking up codes in spreadsheets.
The direction of the UK construction industry is clear. BIM mandates are tightening, digital delivery expectations are rising, and the projects that run smoothly are increasingly the ones with well-structured, consistently classified documentation. Uniclass 2015 is the system the industry has settled on. The sooner your practice is fluent in it, the better positioned you'll be when the next brief lands on your desk.
