CAWS, or the Common Arrangement of Work Sections, was first published in 1987 by the Co-ordinating Committee for Project Information. Its purpose was practical: give the industry a shared way to organise specifications and bills of quantities so that everyone, from the architect writing the spec to the quantity surveyor pricing it, could find the same information in the same place.
The system organises building work into 26 alphabetical groups, from A (Preliminaries/General conditions) through to Z (Building fabric reference specifications). Each group contains numbered work sections. If you've ever written a specification using section F10 (Brick/block walling) or M60 (Painting/clear finishing), you've used CAWS. NBS adopted CAWS as its organisational framework in 1988, and for three decades it served as the backbone of UK specification writing.
A second edition followed in 1998, aligning CAWS with the broader Uniclass 1997 system. But the core structure, grouping work by trade and material, remained unchanged. That trade-based logic made it intuitive for anyone familiar with how buildings are actually constructed. Bricklaying in one section, screeding in another, painting in another. Easy to navigate, easy to coordinate with bills of quantities.
Uniclass 2015 is a fundamentally different proposition. Where CAWS was a single classification table for work sections, Uniclass 2015 is a suite of twelve interrelated tables that classify everything in the built environment, from the broadest project type down to an individual product.
The tables most relevant to specification writers are Ss (Systems), Pr (Products), and EF (Elements/Functions). The Ss table classifies building systems like wall systems, floor systems, and roof systems. The Pr table classifies individual products. The EF table classifies functional elements. Each code uses a hierarchical structure of paired characters: the first two identify the table, followed by groups, subgroups, sections, and objects.
This matters because Uniclass 2015 was designed for a world where building information doesn't just sit in a specification binder. It flows between models, databases, cost plans, and asset management systems. The same classification code that identifies a wall system in a BIM model can appear in the specification, the schedule, and the facilities management database. That consistency is what makes digital workflows possible.
For an architect sitting down to write a spec, the differences show up in three areas.
Scope is the first. CAWS covers work sections for building projects. Uniclass 2015 covers everything: civil engineering, landscape, infrastructure, and buildings. If your practice works across sectors, Uniclass gives you a single classification language for all of them.
Granularity is the second. CAWS organises by trade. Section M10 covers cement-based levelling screeds, with clauses for aggregate quality and curing requirements nested within. Uniclass 2015 organises by system and product. A floor screed would appear under the relevant Ss system code, with the specific product classified separately under Pr. That separation means you can reference the same product across multiple systems without duplicating specification clauses.
Interoperability is the third. CAWS was designed for paper-based workflows. The section numbers made sense when you were printing binders and cross-referencing by hand. Uniclass 2015 was designed for BIM. Its codes are machine-readable, structured for databases, and intended to travel between software applications. Tools like Avoice are built around this principle, using Uniclass and CAWS classification to structure specifications that integrate with the rest of your project data rather than sitting in isolation.
The shift isn't just about preference. It's about mandates. The UK government's BIM Framework, which applies to all centrally funded public sector projects, requires information management in accordance with BS EN ISO 19650. That standard recommends classification in line with ISO 12006-2, and in the UK, that means Uniclass.
NBS Chorus, the most widely used specification platform in the UK, supports both CAWS and Uniclass. But CAWS is no longer actively maintained as a classification system. It is, technically, Table J from the earlier Uniclass 1.4. NBS has noted that an increasing share of projects now select Uniclass 2015, and the direction of travel is clear.
The quarterly update cycle confirms this. In January 2026, NBS released improvements across eight Uniclass tables, including new classifications for deconstruction activities supporting circular construction principles, and extended roles for quality managers and utilities consultants. Twenty-six new classifications and five amended codes in a single release. That kind of active development signals where the industry's attention sits.
For practices still using CAWS, this creates a growing friction. Your specifications work fine on private sector projects where no one mandates a particular classification. But the moment you bid for a public sector scheme, or collaborate with a team using BIM workflows, the expectation is Uniclass. And increasingly, even private clients and main contractors are asking for it.
That said, CAWS isn't dead. Roughly half the industry still uses it, particularly smaller practices working on domestic and small commercial projects where BIM isn't a contractual requirement.
CAWS has real strengths. Its trade-based structure mirrors how subcontractors think about work packages. A bricklayer doesn't care about system classifications; they want to find the brickwork section and read the relevant clauses. For projects where the specification is the primary coordination document and digital information exchange isn't required, CAWS is familiar, fast, and effective.
The mapping between CAWS and Uniclass 2015 is also well documented. NBS has published classification mapping tables, so it is possible to cross-reference between the two systems. If you receive a CAWS-classified spec and need to convert it for a Uniclass project, or vice versa, the pathway exists. Platforms like Avoice support both classification systems, which means practices in transition don't have to abandon their existing documentation overnight. You can continue working in CAWS on projects that don't demand otherwise while building your Uniclass fluency on new ones.
If your practice is still primarily on CAWS, there are a few practical steps worth considering.
Start by running your next project with Uniclass classification, even if the client doesn't require it. The work section structure will feel unfamiliar at first, but the logic is coherent once you understand the table hierarchy. Use the Ss table for systems and the Pr table for products. Look up codes on the NBS Uniclass website, which is searchable and updated quarterly.
Review your clause libraries. If you've built custom specification clauses over years of practice, they'll be organised by CAWS sections. Reclassifying them under Uniclass codes takes effort, but it's a one-off exercise that pays dividends on every subsequent project. AI-powered specification tools can accelerate this significantly. Avoice, for example, ingests a firm's existing documentation, including sheets, schedules, material libraries, and historical projects, and restructures it around recognised classification standards. It handles the mapping between CAWS and Uniclass as part of the process, so you don't lose years of accumulated knowledge when you switch systems.
Get your team comfortable with the code structure. Uniclass codes look intimidating at first glance, with their paired character format. Ss_25_10_30 for a blockwork wall system, say. But they follow a consistent logic. Once someone on the team understands the pattern of table, group, subgroup, section, and object, it becomes second nature. The same was true of CAWS when it was introduced in 1987. Every classification system feels opaque until you've used it on a few projects.
The deeper reason Uniclass matters isn't about section numbers or coding conventions. It's about whether your specification data can connect to your other project data.
When a specification is classified under Uniclass, it can be linked to a BIM model, cross-checked against a cost plan using NRM-aligned codes, and carried through to facilities management. When it's classified under CAWS, it works well within the construction phase but sits disconnected from the wider project information chain that clients and asset managers increasingly expect.
That distinction matters more with every year. Clients on larger projects expect coordinated information deliverables. Contractors expect specifications that align with their digital workflows and procurement systems. And the tools the profession is adopting, from BIM authoring software to AI-powered specification platforms, are built around Uniclass as the common language.
The choice between CAWS and Uniclass isn't really a choice about which system is better in the abstract. CAWS served the industry well for nearly forty years and continues to work perfectly well on projects that don't require digital information exchange. The real question is whether your practice's specification workflow is positioned for the projects you want to win in the next five to ten years. If you want to see how Avoice handles classification across both systems on a real project, it's worth exploring what AI-powered specification tools can do with your existing documentation.
