CAWS to Uniclass: The Sections That Don't Map One to One

What kinds of mapping relationship exist between CAWS and Uniclass?

There are four: one-to-one, one-to-many, many-to-one and many-to-many, plus a fifth case where a CAWS section has no Uniclass system target at all.

CAWS, the Common Arrangement of Work Sections, was built to organise bills of quantities and specifications by the work a trade performs. Uniclass 2015 was built to classify information throughout the life of an asset, so the Ss (Systems) table describes assembled systems and the Pr (Products) table describes the products inside them. The two are answering different questions. That is why a code-for-code lookup does not work, and why this guide treats the relationship type as the first thing to decide. For the full migration sequence, see How to Move an Office Master from CAWS to Uniclass 2015.

How the codes are built

A Uniclass 2015 code starts with a table prefix, followed by pairs of digits for group, sub-group, section and, in the tables that go that far, object. Ss_25_10_30_35 is therefore Table Ss, group 25 (Wall and barrier systems), sub-group 10 (Framed wall systems), section 30 (Framed partition systems), object 35 (Gypsum board partition systems). A mapping can land at any level, and the right level depends on how specific your clause is. Uniclass Codes Explained sets out the table structure in full.

Where the codes in this guide come from

Every Uniclass 2015 code in the tables below is taken from the published Uniclass 2015 Ss and Pr tables and checked by title. The CAWS section codes and titles are taken from a published list of CAWS sections. Codes are taken from the published Uniclass 2015 tables. Check them against the current release before use, as the tables are updated regularly.

Which common architectural sections map cleanly?

Sections that describe a single, self-contained system usually land on a single Uniclass system code. The check is that the clause would still read correctly if you replaced the CAWS heading with the Uniclass one.

These are the sections where a straight pairing is safe. Even so, apply the replace-the-heading test: read the clause under the new heading and ask whether anything in it belongs to a neighbouring system.

Notice how many of the clean matches are finishes, treatments and accessory systems. Where the CAWS section was already defined by a single process or product family, the system view and the trade view tend to agree. Where it was defined by a trade working across many parts of the building, they do not.

Which sections split across several systems, or merge into one?

The sections that cause the most trouble are the ones written around a trade or a material, because the same material appears in several systems. Roofing, linings, openings and plastering are the usual culprits.

For each row below, the CAWS section is a package of work and the Uniclass codes are the systems that package contributes to. The right target for a particular clause depends on what the clause actually describes, so the table lists candidates, not answers.

Reading the table

Two patterns repeat. First, the same material appears in a roof system and a cladding system (natural slate, lead, tiles), so a section named after the material splits by location. Second, one trade covers several assemblies (plasterboard in partitions, linings and ceilings), so a section named after the trade splits by assembly. In both cases the product stays the same and the system changes, which is why a Pr clause written once and referred to by several Ss clauses reduces duplication.

Which sections have no clean Uniclass target?

Preliminaries (the A sections), general reference sections (the Z group for workmanship and materials) and some alteration and survey sections describe how work is run or what applies everywhere, so they have no assembled system to map to.

This is not a gap in your mapping. It is a structural difference. A system classification has no natural home for the contract's general conditions, and only a partial home for rules that apply to every trade.

Three ways to treat them

Leave them in CAWS form. The most common answer. The preliminaries stay as a preliminaries block, and general sections stay in their existing reference structure. Nothing needs to be re-keyed and the specification stays coherent.

Map the product-level Z sections to Pr. Where a Z section is really a product family (sealants, mortars, adhesives, fasteners), the Pr table is a good home, and the Ss clauses can refer to it. This is the hybrid structure described in the migration guide.

Create practice-specific references. For rules that apply everywhere (a general workmanship clause, for instance), keep a short practice reference with its own codes, and say so in the master. Do not force a Uniclass code onto them just to complete the table.

The Uniclass PM table (Project Management) carries project information classes, which can cover some preliminaries-type content, but it classifies information about the project, not the contract conditions. Do not treat it as a replacement for the A sections.

How do you decide where a section should go when the mapping is not obvious?

Start from the assembly that appears on your drawings and in your model, find the Uniclass system that matches it, and only then check the CAWS section title. If two systems fit, split the clause. If none fit, record that and leave it.

The following sequence resolves most cases. It reads the clause rather than its heading, because the heading is what misleads.

Treat the table of candidates in this guide as a prompt for your own mapping, not a final answer. The same CAWS section can map differently in two practices because they write the clause differently. A practice whose K10 clause is mainly about partitions will map it differently from one whose K10 covers all three assemblies.

Common mistakes

• ✓Pairing by title alone, so Plasterboard dry linings becomes one wall lining code and loses the partitions and ceilings.
• ✓Choosing the deepest object level for a clause that is written at section level, which makes the code more specific than the text.
• ✓Using a Pr code as a clause heading for a whole assembly.
• ✓Forcing preliminaries and general sections into Ss or Pr to complete the table.
• ✓Not recording the Uniclass release used, so a later retitle or retirement breaks the mapping silently.

The mistakes above are why a mapping should be reviewed by someone who knows the master. A technical director reading a one-to-many row is faster and more accurate than a lookup tool, because they know which of the three systems their practice actually specifies under that heading. CAWS: The Common Arrangement of Work Sections helps when you need to check what a section was meant to cover.

Questions technical directors ask about CAWS to Uniclass mapping

Is there a one-to-one mapping between CAWS and Uniclass?

Not for most architectural sections. Some, such as H92 Rainscreen cladding (Ss_25_20_70), have a clean equivalent. Many split (K10 across partitions, linings and ceilings) or merge (three flat roof covering sections into Ss_30_40_30).

Which Uniclass table do CAWS sections map to?

Mainly the Ss (Systems) table for assembled work, and the Pr (Products) table where a section is really a product family such as sealants or mortars. The EF (Elements/functions) table is used for classifying elements in a model and cost plan, and is not usually the target for a specification clause.

What happens to the A preliminaries sections?

They have no Uniclass system equivalent. Most practices keep them as a preliminaries block alongside the Uniclass-structured work sections.

Should I map to the section, sub-group or object level?

Map to the level that matches how specific your clause is. A clause for a type of curtain walling can use the object level. A general curtain walling clause belongs at the section level.

Where do I find the Uniclass codes to use?

The Uniclass 2015 tables are published and can be downloaded. Use the current release, and record which release you used.

Can software do the mapping for me?

It can propose candidates and keep the result consistent, but it cannot decide which system a clause describes. That decision sits with the person who knows the master.

Where Avoice fits

A mapping table is only useful if it stays attached to the clauses it describes. Holding it inside the master, with an owner, is what keeps it current.

In Avoice the office master is a governed library with an owner, so a mapping decision is recorded against the clause it applies to rather than in a separate spreadsheet that drifts. Practice Rules and the pre-issue Technical Review then check the rebuilt clauses against schedules and drawings during a parallel run. Avoice writes specifications in CAWS or Uniclass 2015: each clause carries a CAWS reference or a Uniclass code, and the practice chooses which.

If your practice wants help building the table, Avoice can map an existing CAWS master to Uniclass 2015 and flag the sections that need a decision, with the practice reviewing and approving each mapping.