How to Move an Office Master from CAWS to Uniclass 2015

Why would a practice move its office master from CAWS to Uniclass?

A practice moves when something outside the specification starts asking for Uniclass, or when the master has become so hard to maintain that a restructure is overdue. Wanting to look modern is not a reason on its own.

CAWS, the Common Arrangement of Work Sections, arranges a specification by work section: a package of work a trade could price and carry out. Uniclass 2015 arranges information by what the thing is: an element or function, a system, a product. Both are legitimate. The question is whether the way your practice is asked for information now matches the way your master is organised. The background to the two systems is in Specification Writing for Beginners, and the section structure itself is covered in CAWS: The Common Arrangement of Work Sections.

In practice the triggers fall into four groups. Pick the one that is actually driving your migration, because it decides how far you need to go.

The ISO 19650 series sets out information management for projects delivered with building information modelling, and the UK BIM Framework publishes the UK guidance that sits alongside it. These documents ask appointing parties to state their information requirements, and in the UK those requirements commonly refer to Uniclass 2015 for classification, so check the appointing party's requirements for the project. Uniclass 2015 itself is structured in accordance with ISO 12006-2, the framework standard for classifying construction information (ISO 12006-2:2015). For the practice-level view of ISO 19650, see ISO 19650 for Architects.

When not to migrate yet

Do not start while the master is still an old project in disguise. A reclassification carries every existing defect into a new structure. If the master has no owner, two or three copies in circulation, and withdrawn standards still cited, fix those first. Why Specifications Fail the Same Way in Every Practice sets out that order, and The Office Master Specification covers how to put a master on a proper footing.

Also hold off if no live project or client is asking for classified output. A migration done without a deadline tends to stall in the mapping stage. If the only driver is future readiness, a lighter option is to add Uniclass codes as reference fields against existing CAWS clauses and migrate the structure later.

Which parts of the master should be in scope?

Start with the sections where the classification change affects the output: the building fabric and finishes sections that tie to model elements and schedules. Leave preliminaries and general workmanship until last, because they have no clean Uniclass target.

An office master is rarely a single block. Most have preliminaries, a set of fabric and finishes sections, a set of services sections (often written by engineers), and general workmanship and materials sections. Each behaves differently under migration, so triage before you map.

Four bands of sections

Fabric and finishes (CAWS groups such as F masonry, H cladding and covering, J waterproofing, K linings and dry partitioning, L windows, doors and stairs, M surface finishes) are where the benefit is greatest. These map to systems in the Uniclass Ss table and are the sections that model objects and schedule types refer to. Migrate these first.

Structure and groundwork (D, E, G) are often written by or with the structural engineer. Keep them in scope only if the engineer's output is also being reclassified, otherwise you will create a mismatch inside one specification.

Services (R to X) sit in a different part of Uniclass again. Where the practice writes its own, migrate them after the fabric. Where engineers write them, agree the approach with the engineers rather than imposing one. See MEP Specification: A UK Guide.

Preliminaries and general sections (A, and the Z reference sections for workmanship) describe how the work is run, or sit under every system. They have no equivalent system in Uniclass. They stay as they are, or are handled as a separate structure. This is normal and should be planned for, not treated as a failure of the mapping.

Set a boundary before you start

Write down which sections are in the first wave, which are deferred and which are out of scope, and tell the team. A master that is half migrated and half not is workable only if everyone knows where the line is. A first wave of 10 to 20 sections covering the most-used fabric work is an illustrative size. Choose them by usage: the sections that appear in nearly every project specification, so the benefit arrives early and the risk of leaving old content behind is lowest.

How do you build the CAWS to Uniclass mapping?

Build the mapping as a table with one row per relationship, not one row per CAWS section, and classify each relationship as one-to-one, one-to-many, many-to-one or many-to-many before you decide anything else.

The mapping is the working document of the whole migration. Its columns should be: CAWS section code and title, Uniclass code and title, table (usually Ss, sometimes Pr or EF), relationship type, who decided, date, and a note on the clause content that has to change. A spreadsheet is enough. What matters is that one CAWS section can appear in several rows, and one Uniclass code can appear against several CAWS sections.

Published Uniclass 2015 tables are freely downloadable, and they include a title for every code. Work from the current release and record which release you used, because the tables are revised periodically and a code you rely on can be retitled or retired.

Why the straight lookup fails

A published crosswalk, or a spreadsheet that pairs each CAWS code with one Uniclass code, can only be a starting point. CAWS arranges the work by the trade that carries it out. Uniclass describes the assembled system. A plasterboard partition in CAWS is part of K10, together with the lining to a masonry wall and the suspended ceiling, because the same trade fits all three. In Uniclass the partition, the wall lining and the ceiling are different systems with different codes. No lookup can tell which of those a given clause in your master actually describes. Someone who knows the master has to read the clause.

Decide the direction of the mapping

Two directions are possible and they give different tables. Mapping from CAWS to Uniclass answers "where does this clause go?". Mapping from Uniclass to CAWS answers "what must the new structure cover?". Do both. Mapping from CAWS finds clauses that have nowhere to land. Mapping from Uniclass finds systems your practice specifies often that your master has no clause for, which is the most useful gap list a migration produces.

Record decisions, not just pairs

Every row where the relationship is not one-to-one needs a recorded decision: what rule was applied, by whom, and on what date. Without that, the first reviewer who disagrees reopens the whole table. A short rule set helps: map to the most specific Ss code that fits the typical assembly; use Pr codes only for products named inside a clause, never as the clause heading; and where a section straddles two systems, split it rather than choose one.

How do you rebuild clauses rather than just renumber them?

Take each CAWS section apart by system, rewrite the clauses so each one describes one complete system, and move products down to the product level. A renumbered CAWS clause under a Uniclass heading is still a CAWS clause.

Renumbering is what practices attempt first, and it is where migrations go wrong. A CAWS section such as K10 describes plasterboard work in every location the trade works in, with shared sub-clauses for boards, framing, jointing and finish. Put the Uniclass partition code over that section and the clause still talks about ceilings. Drawings and schedules that cite the partition system now point at a clause that describes something broader, and the mismatch is invisible until a contractor asks about it.

Decide: Ss clauses, Pr clauses, or both

The structural decision in a Uniclass master is where the requirement lives. Three patterns are common.

System-led. The clause heading is an Ss code, and the products are described inside it. The clause says what the complete assembly must achieve, and names the products that make it up. This is the closest match to how CAWS clauses read today, and it is the usual choice for fabric and finishes. It also matches how drawings tag assemblies.

Product-led. The clause heading is a Pr code. This suits items that are procured and installed as a product with little assembly around them, for example ironmongery, sanitaryware or a manufacturer's proprietary item. It does not suit a wall build-up.

Hybrid. A system clause refers to product clauses by code. The system clause carries performance and workmanship for the assembly, and each product clause carries the product requirements and evidence. This gives the cleanest reuse, because a plasterboard product clause is written once and referred to from the partition, lining and ceiling systems. It also needs the most discipline in cross-references. Uniclass Codes Explained shows how the Ss and Pr tables relate.

Rebuild checklist for each clause

The last two items are where the real cleaning happens. A migration is the one moment a practice re-reads its whole master. Use it to remove leftover project content, resolve open defaults and retire withdrawn standards, which is the work keeping the office master up to date describes as a continuing task.

How long does a migration take, and how do you run it on live projects?

For a full master expect months, not weeks, and expect to run both structures side by side on live projects for at least one full project cycle before cutting over. The durations below are planning assumptions, not benchmarks.

The timings depend on the size of the master, the number of authors, and how many sections are in the first wave. They also depend on how much time the person leading the work has. A technical director who can give half a day a week will take much longer than a practice that assigns an owner for a few days a week. The ranges below assume one named owner and a first wave of 10 to 20 sections These are illustrative planning assumptions, not benchmarks.

Why run in parallel

The mapping looks right on paper and then meets a real project. A live project exposes the clause that was split wrongly, the assembly that has no Ss code in the master yet, and the schedule type that cites a section that no longer exists. Running the new structure on a project of moderate size, ideally one at Stage 3 or earlier, shows these without putting a tender at risk. Pick a project with a team that will tell you what went wrong. The RIBA stage matters: starting a new structure at Stage 2 or 3 is far cheaper than changing classification mid-way through technical design.

Parallel running means the project specification is produced from the new structure, and the CAWS-numbered version is kept as a reference output, not as a second specification. Keep one authoritative document per project. Two live specifications for the same project is the failure to avoid.

Running both structures without duplicating work

For the period of overlap the master carries both references. Each rebuilt clause holds its Uniclass code and a "formerly" field with the CAWS section it came from. That lets an author search by the old section number, lets a reviewer trace a clause back to its origin, and gives the mapping table a live test. Remove the "formerly" field only when the CAWS copy is retired.

How do you cut over, retire the CAWS copies and train the team?

Cut over by project start date, not by calendar date: every project that starts after the cut-over uses the new structure, and live projects finish on the structure they began with. Then retire the CAWS copies deliberately, and train people on the rules, not the codes.

Changing structure mid-project makes every drawing note, schedule reference and consultant document that cites a section number wrong at once. So the rule is simple: no live project changes structure unless the project lead and the technical director both agree, in writing, and the cost is accepted.

Cut-over conditions

Do not cut over until each of the following is true.

• ✓The first-wave sections have been used on at least one live project and the corrections have been folded back into the master.
• ✓Every one-to-many and many-to-many mapping row has a recorded decision and an owner.
• ✓Model parameters, schedule templates and drawing notes use the new codes, or have a documented translation.
• ✓A named person owns the master and the mapping table, and there is a route for authors to raise problems.
• ✓The CAWS copies have a withdrawal date and an archive location.

Retire the CAWS copies

The most common reason a migration fails after cut-over is that the old master is still on the server. Authors who are under time pressure open the file they know. Archive the CAWS master as read-only, rename it so it cannot be mistaken for current, remove it from project templates, and record the archive date. Keep it for reference, because completed projects may need to be re-issued from it. Do not keep it where a new project can pick it up.

If the practice uses specification software, change the default master at the same time, so that no new project can start from the old one. Switching tools at the same moment as switching classification doubles the risk, so do one and then the other. Switching Specification Software covers the tool side.

Train on rules, not on codes

Authors do not need to memorise Uniclass codes. They need to know three things: which system their clause describes, how to find the matching master clause, and what to do when there is no matching clause. Run a short session on each, using real project examples from the parallel run. Give authors a one-page decision rule for the awkward cases, such as a partition that also lines a wall, or a roof covering that is also a cladding. Expect questions for the first two or three projects, and keep a log of them, because the log is the next version of the mapping table.

Plan the second wave

After the first wave, repeat the sequence for the remaining sections, usually faster because the rules are settled and the authors have seen the pattern. Finish with the preliminaries and general sections, and decide explicitly whether they stay in CAWS form, which is a valid long-term answer.

Questions technical directors ask about a CAWS to Uniclass migration

Can we just add Uniclass codes to our existing CAWS master?

Yes, as a first step. Adding a Uniclass reference field to each CAWS clause gives you classified output for model and schedule linking without restructuring the master. It does not solve one-to-many cases, because a clause that covers three systems can carry only one honest code. Treat it as a bridge, not the destination.

How long does a CAWS to Uniclass migration take?

For a first wave of 10 to 20 fabric and finishes sections, plan for roughly six to nine months from decision to cut-over, including a parallel run on live projects (an illustrative planning assumption, not a benchmark). A full master takes longer. The time is driven by author availability and the number of one-to-many mappings, not by the size of the codes table.

Is there an official mapping from CAWS to Uniclass?

Published crosswalks exist, but they pair codes and cannot decide which of several systems a given clause describes. Use them to find candidates, then have someone who knows the master make the decision and record it.

Should clauses be organised by Ss or Pr?

Usually by Ss for fabric and finishes, with products described inside the clause or in referenced Pr clauses. Use Pr as the heading only for items procured as products with little assembly, such as ironmongery.

What happens to preliminaries and general workmanship sections?

They have no equivalent system in Uniclass. Most practices keep them in their existing form. Plan for this at the start so that the final specification has a coherent structure.

Do we have to migrate every project already in progress?

No. Cut over by project start date. Live projects finish on the structure they started with unless the project lead and technical director agree to change and accept the re-coordination cost.

Where Avoice fits

The expensive part of a migration is the mapping and the rebuild, because both depend on someone who knows the master. Software helps most by holding the result in place once the decisions are made.

In Avoice the office master is a governed library with an owner, and projects draw from it rather than copying the last job, which is the footing a migration needs. Practice Rules apply the values, standards and wording you decide on while the specification is written, and the pre-issue Technical Review compares the specification with schedules and drawings, which is the check you want 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.

For the mapping itself, 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. The one-to-many cases are flagged for a technical director to decide. The decision on which Ss code a clause belongs under stays with the practice.