Uniclass Codes Explained: Ss, Pr or EF, and Which One Your Specification Uses
How Uniclass 2015 codes are built, what each table is for, and which ones belong in a specification
Uniclass 2015 is a set of linked tables, not a single list of codes. A specification mostly uses two of them: Ss for systems and Pr for products. The EF table links the same work to elements, cost plans and models. This guide explains each table, how a code is built, and how the tables connect, with worked examples from the published tables.
Ss describes the assembled system, Pr describes the products inside it and EF describes the element it serves. A clause is usually headed with the first.
What is Uniclass 2015 and what are its tables?
Uniclass 2015 is a unified classification for the whole life of a built asset, published as a set of tables. Each table classifies one kind of thing, so the same building is described through several tables at once.
Uniclass 2015 is structured in accordance with ISO 12006-2, the framework standard for classifying information about construction works. It is used by project teams to organise models, cost plans, briefs, drawings and specifications, and it is the classification the UK BIM Framework commonly points projects to. The tables are published openly and are revised periodically.
The table prefix tells you what kind of thing the code classifies. The published tables are listed below, each with a code taken from the table as an example. Codes are taken from the published Uniclass 2015 tables. Check them against the current release before use, as the tables are updated regularly.
Scroll horizontally to view all columns.
| Prefix | Table | What it classifies | Example code and title |
|---|---|---|---|
| Co | Complexes | Groups of buildings or assets on a site, such as a campus or estate | Co_20 Administrative, commercial and protective service complexes |
| En | Entities | A whole building or asset | En_45_10_39 Houses |
| Ac | Activities | What people do, including project management activities | Ac_05_00_10 Business case development |
| SL | Spaces/locations | Rooms and places within a building or site | SL_20_15_59 Offices |
| EF | Elements/functions | The parts of a building by function, used in cost plans and models | EF_25_10 Walls |
| Ss | Systems | Complete assembled systems | Ss_25_10_30_35 Gypsum board partition systems |
| Pr | Products | Individual manufactured or formless products | Pr_25_71_35_65 Gypsum plasterboards |
| TE | Tools and equipment | Construction tools, plant and temporary equipment | TE_10 Formwork |
| PM | Project management | Project information and management documents | PM_10_20 Client requirements |
| FI | Form of information | The type of document or information item | FI_10_20 Correspondence (CO) |
| Ro | Roles | People and organisational roles on a project | Ro_50_10_03 Architect (A) |
| Zz | CAD | Drawing and CAD content such as frames and viewports | Zz_10_20 Drawing frame |
Prefixes, table names and example codes are from the published Uniclass 2015 tables.
Most people who write specifications will only ever use Ss and Pr, with EF and SL appearing in schedules and models. The other tables matter to the wider project team: Ro for naming responsibilities, FI and PM for classifying documents, Zz for CAD layers and content.
What Uniclass replaced, and what it does not replace
Uniclass 2015 is a fresh classification and its codes are unrelated to the section codes of CAWS (the Common Arrangement of Work Sections) used by most UK specifications. CAWS organises a specification into work sections such as K10 Plasterboard dry linings, partitions and ceilings. Uniclass does not replace the idea of a specification, only the way its content is classified. An earlier edition of Uniclass also exists with a different code format. If you are weighing a move between the two systems, read CAWS to Uniclass: The Sections That Don't Map One to One and How to Move an Office Master from CAWS to Uniclass 2015.
How is a Uniclass code structured?
A Uniclass 2015 code is a table prefix followed by pairs of digits separated by underscores, each pair moving from general to specific: group, sub-group, section and, in some tables, object.
Take Ss_25_10_30_35. Reading left to right, each part narrows the one before.
- 1
Ss: Table
The table prefix. Ss is Systems.
- 2
25: Group
Ss_25 Wall and barrier systems.
- 3
10: Sub-group
Ss_25_10 Framed wall systems.
- 4
30: Section
Ss_25_10_30 Framed partition systems.
- 5
35: Object
Ss_25_10_30_35 Gypsum board partition systems.
Each level inherits the meaning of the level above. A clause can be classified at any level, and a code is only as specific as its last pair.
Depth varies by table
Not every table goes down to object level. In the published tables, Ss, Pr and TE run to object level, so a full code has a table prefix and four pairs. Most others (Co, En, SL, Ac, EF, PM, Ro and Zz) stop at section level, with three pairs after the prefix, and FI stops at sub-group. This is why a code such as EF_25_10 (Walls) is complete at only two pairs, while a system object needs four.
Codes are not meant to be read in isolation
The numbers are positional, not meaningful in themselves. Ss_25 does not mean "twenty-five" in any sense; it means "the group that carries wall and barrier systems". Always keep the title with the code when you write a specification, schedule or mapping table. If a revised release changes a title or retires a code, the title is what tells you what was meant.
Separators and formatting
The published form uses underscores between pairs, as in Ss_25_10_30_35. Some tools show spaces or other separators. Pick one form for the practice and use it everywhere, including in model parameters, schedules and clause headings, because a code with the wrong separator will not match when you search or filter.
Which Uniclass tables does a specification use?
A specification mostly uses Ss for the complete system and Pr for the products it is built from. EF links the same work to elements for cost planning and models, and SL links it to the rooms where it occurs.
The tables connect through the thing being described. A wall is an element (EF), built as a system (Ss), from products (Pr), and it appears in spaces (SL). Which of these a clause is headed with depends on what the clause is for.
EF and Ss: the part and the build-up
The element says what the part does. The system says how it is built.
Pr: what goes into it
Each product in the build-up has its own code.
Codes are from the published Uniclass 2015 tables. The system and product choices are illustrative.
Ss: the default for a clause
A specification clause normally describes a complete system. It says what the assembly must achieve, how it is built, and how it is tested. That is an Ss clause. Ss is also the table that drawings, schedule types and model objects most often cite, so it is the best table for keeping the specification and the model in agreement.
Pr: the products inside
Pr codes classify the products that make up a system. Use them when the clause is about a product's properties rather than the assembly, such as plasterboard, insulation or fixings, and when you want one product clause to be referred to by several system clauses. A product code is not a substitute for a system code. A brick is not a wall, and the specification has to say what the wall must do.
EF: the link to cost and the model
The EF table classifies elements by function. It is the table cost plans and early models commonly use, because the design at early stages is described by elements (walls, roofs, floors) before the systems are chosen. In the published Ss table, systems also carry a column relating them to RICS New Rules of Measurement (NRM 1) elements, for example Ss_25_10_30_35 to "2.7.1 Walls and partitions", which helps connect a specification to a cost plan. For how codes sit in the model, see Uniclass Codes in Revit and ArchiCAD.
SL and the others
SL (Spaces/locations) classifies rooms, and appears in room data sheets and finishes schedules. Co, En, Ac, PM, FI, Ro and Zz are about the project, its documents and its people, and rarely appear in clause headings. The project's information requirements will say which tables are expected in which deliverables; see ISO 19650 for Architects for how those requirements are set.
What do Uniclass codes look like for real specification items?
Each row below takes a common item and gives the element, system and product codes that apply to it. Use these as a pattern: one element, one system, one or more products.
The examples are chosen from the published tables. They show the chain from element to system to product. They are examples of how the tables connect, not a recommended specification, and the system and product choices will differ on your project.
Scroll horizontally to view all columns.
| Item | EF (element) | Ss (system) | Pr (product) |
|---|---|---|---|
| Plasterboard partition | EF_25_10 Walls | Ss_25_10_30_35 Gypsum board partition systems | Pr_25_71_35_65 Gypsum plasterboards; Pr_25_57_06_53 Mineral wool insulation |
| Masonry external wall leaf | EF_25_10 Walls | Ss_25_13_50_51 Masonry wall leaf systems | Pr_20_93_52_15 Clay bricks; Pr_20_85_84_19 Cavity wall ties |
| Rainscreen cladding | EF_25_10 Walls | Ss_25_20_70 Rainscreen cladding systems | Chosen once the cladding panel and subframe are selected |
| Timber window | EF_25_30 Openings | Ss_25_30_95_95 Window systems | Pr_30_59_98_96 Wood window units |
| Natural slate roof | EF_30_10 Roofs | Ss_30_40_95_55 Natural slate roofing systems | Pr_25_93_72_56 Natural slates |
| Demountable suspended ceiling | EF_30_25 Ceilings and soffits | Ss_30_25_22 Demountable suspended ceiling systems | Pr_20_85_32_22 Demountable suspended ceiling grids |
| Fire stopping to service penetrations | The wall or floor element that is penetrated | Ss_25_60_30_40 Individual services penetrations fire-stopping systems | Pr_25_80_81_51 Mineral wool fire-stopping |
Codes and titles are from the published Uniclass 2015 EF, Ss and Pr tables.
In the first row, the same element (EF_25_10 Walls) is served by the partition, masonry leaf and rainscreen systems, which shows why EF alone is not enough for a specification. The element tells you where a cost or model object sits. The system tells you what to specify. The products tell you what to buy.
Using the chain in a clause
A clause headed with an Ss code, listing the Pr codes of the products it uses, carries enough classification for most project information requirements. The EF code usually lives in the model and the cost plan, with the specification linking to it rather than repeating it. This keeps the clause readable by someone who has never opened the Uniclass tables.
What do people most often get wrong about Uniclass codes?
The usual errors are treating Pr as a substitute for Ss, treating EF as a specification table, assuming CAWS and Uniclass pair code for code, and using a code without its title or release.
Ss and Pr mixed up
A system and the products inside it are different things. A plasterboard partition (Ss_25_10_30_35) contains plasterboard (Pr_25_71_35_65), but the code for the product does not describe the partition. A clause headed with a product code usually leaves the performance of the assembly undefined.
EF used as the specification code
EF_25_10 Walls tells you the clause is about a wall. It does not tell you which of many wall systems. Use EF for model objects and cost plans, and Ss for the clause.
CAWS and Uniclass treated as the same list
CAWS section K10 and Uniclass system Ss_25_10_30_35 are not equivalents. K10 covers partitions, linings and ceilings; Ss_25_10_30_35 covers partitions only. See CAWS to Uniclass: The Sections That Don't Map One to One.
Ss: the assembly
Describes what the complete partition must achieve and how it is built and tested.
Pr: the product
Describes one product inside the assembly. Several systems can use the same product.
The 60 minute figure is illustrative. A system clause owns the performance. A product clause owns the product properties. Mixing them leaves the assembly's performance unspecified.
Codes quoted without a title or release
A code on its own is fragile. Titles are revised and codes are added, retitled and retired between releases. Quote the code with its title, and record the release of the tables used on the project. The first thing to check when two documents disagree is whether they used the same release.
Treating Uniclass as a specification system
Uniclass classifies information. It does not define clause content, a clause order or a way of writing requirements. A specification can be classified with Uniclass and still be badly written, for the reasons set out in Common Specification Defects at Contract Issue. Classification helps people place and retrieve information; the quality of the clause is still the author's job. For the wider context, see the classification section of Specification Writing for Beginners.
Questions technical directors ask about Uniclass codes
What are Uniclass codes?
Uniclass codes are the alphanumeric identifiers in the Uniclass 2015 classification. Each has a table prefix (such as Ss for Systems or Pr for Products) followed by pairs of digits for group, sub-group, section and sometimes object, for example Ss_25_10_30_35 Gypsum board partition systems.
What is the difference between Ss and Pr in Uniclass?
Ss classifies complete systems, such as a plasterboard partition. Pr classifies the products inside them, such as plasterboard. A specification clause is normally headed with an Ss code and refers to Pr codes for the products.
What does EF mean in Uniclass?
EF is the Elements/functions table. It classifies the parts of a building by function, such as walls (EF_25_10) or roofs (EF_30_10), and is commonly used in cost plans and models.
Which Uniclass table should a specification use?
Mainly Ss for systems and Pr for products. EF and SL link the same work to elements and spaces in the model and schedules.
Which tables make up Uniclass 2015?
The published release lists the tables Co, En, Ac, SL, EF, Ss, Pr, TE, PM, FI, Ro and Zz. Check the current release in case tables have been added.
Is Uniclass the same as CAWS?
No. CAWS arranges a specification by work section and Uniclass classifies information across the asset life cycle. Their codes do not pair one to one.
Where Avoice fits
Uniclass codes only help if the specification, the schedules and the model carry the same ones. That is a consistency problem, which is where software earns its place.
In Avoice the office master is a governed library with an owner, and practice Rules apply the standards and wording you decide on as the specification is written. The pre-issue Technical Review compares the specification with schedules and drawings, which is where a code that has drifted between documents is caught. 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 needs to relate its CAWS-numbered master to Uniclass, Avoice can map an existing CAWS master to Uniclass 2015 and flag the sections that need a decision. The practice reviews and approves each mapping. The choice of which system or product code a clause carries stays with the technical director.