Linking Uniclass Codes in Revit and ArchiCAD to Your Specification

How do you link model objects to specification sections?

Classify each model type once with a Uniclass Systems or Products code, then map each code to the specification clause or clauses that govern it. The code is the shared key, and the map is the table the practice owns.

Classification matters to a specification for one reason: it lets two documents refer to the same thing without relying on a person to notice. A drawing tag, a schedule type name and a clause title are all free text, and free text drifts. A classification code is a controlled identifier. If the wall type in the model, the wall type in the schedule and the clause in the specification all carry the same code, a comparison can be automated and the contradictions can be found before the contractor finds them.

Decide the level before you start

Uniclass 2015 is a set of tables. For specification links, the tables that matter are Systems (Ss), Products (Pr) and Elements and functions (EF). A clause usually describes a system (an external wall build-up) and the products in it (the insulation, the membrane, the facing). Decide which table each category of model type carries. A common arrangement is Ss codes on types that are assemblies, such as walls, floors and roofs, and Pr codes on types that are products, such as doors, windows and sanitaryware. Uniclass Codes Explained sets out the tables and code formats in detail. Write the decision into the BIM execution plan, because the rest of the team will follow whatever the plan says and the specification checks depend on it.

Codes should be taken from the published Uniclass 2015 tables, not typed from memory, and the release used should be recorded. The classification file, the model and the specification should all name the same release. Codes are taken from the published Uniclass 2015 tables. Check them against the current release before use, as the tables are updated regularly. This matters because a code can be amended or withdrawn between releases, which silently breaks a mapping.

Map codes to clauses, not clauses to codes

Mapping starts from the model, because the model defines what the project contains. For each classified type, record the clause or clauses that govern it. A single external wall type may need several: the system clause, the insulation product clause and the membrane clause. Expect one code to map to several clauses, and a clause to serve several codes. Two rules keep the mapping healthy. Every classified type must have at least one clause. Every clause that describes a modelled element must have at least one type. Anything that breaks either rule is either an omission in the model, an omission in the specification, or a clause that should have been deleted.

If the practice specification is numbered in CAWS, the map has an extra column. The specification clause carries a CAWS section number and the model type carries a Uniclass code, and the map joins them. CAWS to Uniclass Mapping explains how work sections relate to systems and products, and CAWS Explained covers the numbering that is being mapped.

How do classification parameters work in Revit?

Revit holds a classification in a type parameter. You can use the built-in Assembly Code, the Keynote field, or shared parameters such as Classification.Uniclass.Ss.Number that the project defines and loads into every family.

Revit does not ship with Uniclass. It gives you four places to put a classification, and the project's BIM execution plan should say which one the team uses. Mixed practice across a consultant team is the commonest reason for a classification schedule that looks full and cannot be trusted.

Shared classification parameters

The most common approach in UK practice is a shared parameter file that defines text parameters for each Uniclass table. Published lists use names in the form Classification.Uniclass.Ss.Number and Classification.Uniclass.Ss.Description, with matching Pr and EF versions. Adopt the exact parameter names set by the project's BIM execution plan or the client's information requirements; the names above are those in published shared parameter lists. The working steps are the same in any practice. Load the shared parameter file using Revit's shared parameter settings. Add the parameters to each family as type parameters, grouped under Identity Data. Load the families into the project. For system families such as walls, floors and roofs, bind the same shared parameters to the categories as project parameters. Menu names vary between Revit versions.

Fill the Number parameter with the code and the Description parameter with the title exactly as the published table gives it. Do not abbreviate. If the number and description disagree, schedules will show it, and so will an IFC check. Set the parameters as type parameters. A code on the type applies to every instance, and one correction fixes them all.

Assembly Code

Assembly Code is Revit's built-in classification field. It is a type parameter that selects a code from a text file, and the read-only Assembly Description updates to match. The default file is Uniformat. Autodesk documents how to add or change a Uniformat assembly code for a selected element type, and the file can be replaced with another classification by creating a text file in the same syntax. Follow the Autodesk help for the Revit version in use. Using Assembly Code has one useful side effect: it exports to IFC as a true classification reference, although the classification is named Uniformat unless the export is configured otherwise. That can confuse downstream users, which is why many practices prefer a dedicated shared parameter for Uniclass and leave Assembly Code alone.

Keynotes for the specification link

Keynote is a built-in type parameter that picks a value from a keynote file, a tab-delimited text file set up in Revit's keynoting settings. Keynote tags place the value on a drawing, and a keynote legend lists the values used. For a specification link, the keynote file can carry the clause reference, so that a tag on a drawing reads as the clause number. This is the closest thing in Revit to a native link between a drawing and a specification section. It carries one value per type, so it complements a classification parameter and does not replace it. Keep the keynote file in step with the master, because a keynote file that diverges from the specification gives drawings a reference that no longer exists.

Practical rules for Revit

• ✓Type parameters only, unless there is a documented reason for instance level.
• ✓One shared parameter file, controlled by the BIM manager, with GUIDs preserved across all families.
• ✓Number and description filled together, copied from the published table.
• ✓In-place families avoided for anything that will be scheduled or specified.
• ✓A parameter for the clause reference, or Keynote, filled from the master.
• ✓Parameters added to the IFC export classification list before the first coordination issue.

How does ArchiCAD handle Uniclass classification?

ArchiCAD manages classification in the Classification Manager. Import a Uniclass 2015 classification XML once, then assign codes to elements in the Classification and Properties panel, ideally through favourites and a project template.

ArchiCAD treats classification as a first-class model attribute. Classification systems are managed in the Classification Manager, and each element can hold one classification for each system loaded. That makes it simpler than Revit to carry a Uniclass code, because the system is imported rather than built from parameters.

The working steps are as follows. Open Options, then Classification Manager, and use the Import button to load a classification file. Graphisoft publishes a Uniclass 2015 classification as an XML file on its BIM data downloads page, with a version date and a note of the source, so record which version the project imported. Check that the download matches the release the project has agreed to use. Once imported, the system appears in the Classification and Properties panel in the settings of every element, where a code can be picked from the tree or searched. The classification system and its assignments are part of the project, and a template that already holds the system saves repeating the import on each job.

Use favourites and templates to keep assignments consistent

The commonest ArchiCAD failure is an element drawn from default settings that carries no classification, because it was never set. Prevent it by building classification into favourites and the project template. A wall favourite for the practice's external wall type should already carry its Systems code, its composite, and its properties. Anyone placing that favourite then places a classified element. Elements drawn outside favourites should be caught in the coverage check described below.

Several classification systems can coexist

Because each element holds one value per classification system, a project can carry Uniclass 2015 alongside another system, for example a practice-specific classification, without conflict. This is a practical route for a practice that numbers its specification in CAWS: keep Uniclass as the model classification and carry the CAWS section as a property or a second classification system, then join them in the mapping.

Properties and schedules

Classification values can be read as fields in Interactive Schedules, so a schedule of walls, doors or windows can show the code and its title as columns beside the performance values. Custom properties can carry the clause reference. Publishing the schedule, or exporting it, then gives the specification author and the reviewer the same table to compare. Field names in the schedule settings vary between ArchiCAD versions.

How do you check that every type is classified and mapped?

Schedule the model types with the classification column, filter for blanks and invalid codes, then compare the code list against the clause map. Report coverage per category and run the check at every model issue.

A classification field that is mostly filled is worse than one that is empty, because people trust it. Check coverage the same way you check anything else before issue: with a defined test, a pass mark and an owner.

Report coverage as a number

Coverage is the share of types, by category, that carry a valid code. Compute it per category, because a good result for doors can hide a poor result for walls. Report the count of blanks, the count of invalid codes and the count of types with no clause. The same three numbers, taken at each model issue, show whether classification is improving or decaying. A practice that checks only before contract issue will find the faults when they are most expensive to fix. The Pre-Issue Technical Review Checklist shows where the coverage check sits among the other pre-issue comparisons.

Who owns the checks

The model owner is accountable for the first four checks, because they concern the model alone. The specification author is accountable for the last two, because they concern the join. Where a practice uses a design responsibility split, the matrix sets out who classifies the specialist elements. What Is a Design Responsibility Matrix? covers that split. Without named owners, classification coverage degrades as a model grows, because every team member assumes someone else filled the field.

Do Uniclass codes survive IFC export?

Yes, if the exporter is set up to write them. IFC stores a classification as IfcClassification and IfcClassificationReference linked to each object. In Revit you list the parameters to export, and in ArchiCAD the Classification Manager assignments export as references.

An IFC file carries classification in three linked entities. IfcClassification names the system, its source and its edition. IfcClassificationReference holds the code and title and points to the system. IfcRelAssociatesClassification attaches a reference to an object. All three must be present for a viewer, a model checker or a cost tool to read the code, and the standard is documented by buildingSMART.

Revit export

The Revit IFC exporter does not write a parameter as a classification unless you tell it to. In the IFC export settings, the classification options include a Classification field name list. Each parameter named there is converted to an IfcClassificationReference. Add the Uniclass parameter names, for example the Ss and Pr number parameters, and keep the same list on every export so the property is named identically in every model. Assembly Code exports as a classification reference without this step, but it is named for the Uniformat file it came from. The classification options available depend on the exporter version and Revit release in use, so check the system name and edition fields in the export settings.

ArchiCAD export

ArchiCAD maps classification into IFC through its IFC translator and IFC Manager. Classification assignments made in the Classification Manager export as classification references, and the classification system carries the name and edition recorded when it was imported. This is another reason to record the version at import: the edition in the IFC file will match what the team actually used. The translator settings required depend on the ArchiCAD version in use.

Check the export, not the settings

Open the exported file in a viewer or checker and inspect a sample of objects from each category. Check that the code is present, that the system name and edition are populated, and that the number and title agree. A settings screen tells you what you intended. The file tells you what was produced. If the project follows ISO 19650, the classification is also part of the information requirements the model is checked against; ISO 19650 for Architects explains how those requirements reach the architect.

• ✓System name and edition recorded in the IFC file, matching the release the team adopted.
• ✓Every specified category exports with a classification reference.
• ✓No Uniformat reference appearing where a Uniclass reference is expected.
• ✓Codes in the IFC file agree with the schedule and the clause map.
• ✓The export setup is saved and shared, not rebuilt for each issue.

Questions technical directors ask about model classification

Which Revit parameter should hold a Uniclass code?

Use a text type parameter that the project's BIM execution plan names, and apply it consistently to every family and category. Published shared parameter lists use names in the form Classification.Uniclass.Ss.Number and Classification.Uniclass.Pr.Number, with matching Description parameters. Assembly Code can also hold a code, but it is built around a Uniformat file and needs a replacement file for Uniclass.

How do I import Uniclass 2015 into ArchiCAD?

Open Options, then Classification Manager, and use the Import button to load a classification XML file. Graphisoft publishes a Uniclass 2015 classification XML on its BIM data downloads page. Once imported, the classification appears in the Classification and Properties panel of element settings, where each element or type can be assigned a code.

Should the classification go on instances or types?

On types wherever the software allows it. A code on the type applies to every instance, schedules read cleanly, and one correction fixes all occurrences. Use instance-level classification only for genuine exceptions, because instance codes are the hardest to audit.

Which Uniclass tables does a specification link to?

Most specification links use the Systems (Ss) and Products (Pr) tables, because clauses describe systems and the products inside them. The Elements and functions (EF) table is used for functional groupings such as external walls or roofs. A practice should decide which table each model type carries and write that decision down.

How do Uniclass codes travel in an IFC file?

Through IfcClassification, which names the classification system and edition, and IfcClassificationReference, which holds the code and title, linked to each object by IfcRelAssociatesClassification. In Revit the parameters to export are listed in the Classification field name setting of the IFC export set-up. ArchiCAD exports its Classification Manager assignments as classification references.

How do I check that every model type has a code?

Schedule the types in each category with the classification parameter as a column, filter for blank values, and report coverage as the share of types with a valid code. Add a second check that the code comes from the expected table, and a third that every code has at least one specification clause linked to it.

Where Avoice fits

The classification fields hold the code. The specification holds the requirement. Avoice sits between them and checks that the two agree.

Avoice links specification clauses to Revit and ArchiCAD model objects, keeps performance data in step, and flags mismatches before issue. Tagging an object in the model connects it to the clause that governs it, so the schedule and the specification read from one source. The BIM integration page sets out what the Revit and ArchiCAD connections do. Where the model carries Uniclass codes, they provide a stable key for the match.

The pre-issue Technical Review then compares the specification with the schedules and drawings, so a type with no clause, or a clause for something the model does not contain, appears as a finding and not as a site query. Practice rules keep the values consistent as the specification is written. Avoice writes specifications in CAWS or Uniclass 2015, each clause carrying a CAWS reference or a Uniclass code, and the practice chooses which. For practices moving from CAWS, 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; CAWS to Uniclass: Migrating an Office Master covers that route. The boundary stays the same as in every field guide: software retrieves, compares and flags, and the technical director decides what the practice classifies by.