Before moving on to the software examples (how to ensure the principles of CCI, CCI-EE with them), let’s take a general look with the help of some examples of how the introduction of a unified classification system helps to design an asset-centric unique ID that considers the building whole lifecycle and both human and machine readable. If another unique ID has been previously used, it must be linked to the CCI-EE codes, which are not covered here. In general, it can be noted that any IT system can use its own unique ID value and we may not be able to redefine it in that software/application (take for example BMS or Building Management System, some security system solutions, room register, property register, etc. – all of them may have their own unique ID logic defined, some for example only in the form of numbers). Therefore, in the context of building information models or in the context of asset maintenance resulting from it, we have to perform mutual integration of information, where the unique ID resulting from the building information model and based on, for example, the CCI-EE classification system, is linked to other information systems that are important to the customer. Software default unique IDs (GUID, Element ID, Handle etc.) are not human or machine readable, in addition, different software packages do use different unique IDs, and when transferring similar information, we have to do multiple different integrations (extra work).

The adoption of a unique ID across information systems becomes critical if we want to move to model-based maintenance, where, among other things, optimal information exchange transfers must be defined (EIR or Exchange Information Requirements as stipulated by the EN ISO 19650 series). At the same time, it is important to talk about a single, unique ID concept (human and machine readable) at any stage of the construction life cycle, where it is necessary to make summaries or extracts from the quantities/ volumes (either from the building information model or related documentation), which are then used for budget compilations or connected to other information databases. Based on its unique code, CCI-EE enables automatic connections with other sub-tables of CCI-EE, e.g., certain construction aids/resources or construction activities are connected to certain construction components. CCI-EE provides an opportunity to talk about quantities both on a more general level (e.g., in the context of CCI core tables, international dimension) and also in a more detailed presentation, which already includes CCI-EE application tables (CCI-EE/R), where in addition to the general level code, the type/subtype context is also introduced. Please note that the CCI-EE application tables (types/subtypes) are a supplement to the CCI-EE additions (tables), which are a separate development and are also briefly included here as an example.

Classification usually means defining some specific attributes, using them in the context of digital / physical assets. These attributes should be clearly defined and also named, only then can we clearly understand the attribute conveyed through them (attribute term = property name that carries the property value). Originally part of CCI-EE, the attributes table is now found under the name of CIA-DD table, which then defines the attributes that any project wants to use to ensure a uniform structure/naming. Among other things, there are also attributes that allow us to introduce a classification system or a logic based on it, a reference designation system (RDS).

In the CIA-DD table, a uniform structure is ensured through the attribute code (2 letters + 3 numbers), which must remain in place in any application if uniform information exchange based on the CIA-DD table is desired. In general, however, the name of our attribute also consists of a textual entry, which is not clearly prescribed by the CIA-DD table and which can therefore also be defined on a project or customer basis. Therefore, here is an example of one of the possible naming schemes. Although the textual entry is somewhat free, it must remain within the boundaries set by the property code/definition/standard and should not be confusing. A reference to the CIA-DD table can be added to the attribute code (if it is used in some application), where you can read more detailed information about the given attribute. In this way, attribute definitions are managed from one specific place, where, in turn, connections to other information systems can be found (e.g. IFC property, ETIM code, etc.).

In this example, we limit ourselves to the attributes defining the core CCI tables + additional attributes related to type and ID. At the same time, it is also possible to create an extended view, which includes the attribute information of the so-called yellow/red tables. However, it is worth emphasizing that the attributes of the base tables are the most decisive, and all the attribute information does not have to be included in the model, but thanks to the attributes of the base tables, additional attributes can be linked outside the models as well.

Below is a list of CIA-DD attributes used in the following examples. It is important to ensure that attributes with the same structure are used in any software, so that we can understand the information exported from any source software in the same way. Although the list of attributes may seem long, some of them are filtered only for certain types of elements, for which you can already find more information in the software examples.

Attribute name	General description of the attribute (see CIA-DD table for additional information + connections with IFC / ETIM / standards)
AC125_BSpaceClassCode	CCI classification code that identifies the built space (e.g. AAB)
AC126_BSpaceTypeCode	type code that subdivides the CCI built space class into types and subtypes according to a specific standard(s) and/or asset register needs (e.g. AAB10)
AC127_BSpaceID	enumerable code that points to a specific built space (according to its type or without it, e.g. AAB1001, AAB1, AAB01 etc.)
AC130_BSpaceClassName	CCI classification term that identifies the built space (e.g. Living space)
AC131_BSpaceTypeName	type name that subdivides the CCI built space class name into types and subtypes according to a specific standard(s) and/or asset register needs (e.g. Living room)
AC135_CoComplexClassCode	CCI classification code that identifies the construction complex (e.g. A)
AC136_CoComplexTypeCode	type code that subdivides the CCI construction complex class into types and subtypes according to a specific standard(s) and/or asset register needs (e.g. A10)
AC137_CoComplexID	enumerable code that points to a specific construction complex (according to its type or without it, e.g. A1001, A1, A01 etc.)
AC140_CoComplexClassName	CCI classification term that identifies the construction complex (e.g. Residential complex)
AC141_CoComplexTypeName	type name that subdivides the CCI construction complex class name into types and subtypes according to a specific standard(s) and/or asset register needs (e.g. Caravan park)
AC145_CoEntityClassCode	CCI classification code that identifies the construction entity (e.g. AA)
AC146_CoEntityTypeCode	type code that subdivides the CCI construction entity class into types and subtypes according to a specific standard(s) and/or asset register needs (e.g. AA10)
AC147_CoEntityID	enumerable code that points to a specific construction entity (according to its type or without it, e.g. AD1001, AD1, AD01 etc.)
AC150_CoEntityClassName	CCI classification term that identifies the construction entity (e.g. Single-dwelling house)
AC151_CoEntityTypeName	type name that subdivides the CCI construction entity class name into types and subtypes according to a specific standard(s) and/or asset register needs (e.g. Summer house)
AC155_SystemClassCode	CCI classification code that identifies the functional system (e.g. A), represents a system that is divided into, or may include, one or more subsystems
AC156_SystemTypeCode	type code that subdivides the CCI functional system class into types and subtypes according to a specific standard(s) and/or asset register needs (e.g. A10)
AC157_SystemID	enumerable code that points to a specific functional system (according to its type or without it, e.g. A1001, A1, A01 etc.)
AC160_SystemClassName	CCI classification term that identifies the functional system (e.g. Ground system)
AC161_SystemTypeName	type name that subdivides the CCI construction entity class name into types and subtypes according to a specific standard(s) and/or asset register needs (e.g. Embankment)
AC165_SubsystemClassCode	CCI classification code that identifies the technical system (e.g. AB), denotes a subsystem that originates from or is a subsystem of a functional system (the system as the main system)
AC166_SubsystemTypeCode	type code that subdivides the CCI technical system class into types and subtypes according to a specific standard(s) and/or asset register needs (e.g. AB10)
AC167_SubsystemID	enumerable code that points to a specific technical system (according to its type or without it, e.g. AB1001, AB1, AB01 etc.)
AC170_SubsystemClassName	CCI classification term that identifies the technical system (e.g. Foundation construction)
AC171_SubsystemTypeName	type name that subdivides the CCI technical system class name into types and subtypes according to a specific standard(s) and/or asset register needs (e.g. Slab foundation construction)
AC175_ComponentClassCode	CCI classification code that identifies the construction component (e.g. ULD)
AC176_ComponentTypeCode	type code that subdivides the CCI construction component class into types and subtypes according to a specific standard(s) and/or asset register needs (e.g. ULD10)
AC177_ComponentID	enumerable code that points to a specific construction component (according to its type or without it, e.g. ULD1001, ULD1, ULD01 etc.), uniqueness may derive from the technical system and/or functional system ID
AC180_ComponentClassName	CCI classification term that identifies the construction component (e.g. Column)
AC181_ComponentTypeName	type name that subdivides the CCI construction component class name into types and subtypes according to a specific standard(s) and/or asset register needs (e.g. Prefabricated column)
AN143_RoomName	common or given name which represents the intended use or function of the room, used in the examples here only for premises of a building to refer to an existing name
AN144_RoomNo	number allocated to a room, used in the examples here only for premises of a building to refer to an existing number

Some attributes are a combination of previous attribute values, so they are presented in a separate table. Please note that these properties use the values of the previously described properties + additional symbols. Therefore, it is important that the value of the basic property is available in a so-called pure form, which allows it to be edited in any way (according to the subscriber-specific information content requirement, for example).

Attribute name	General description of the attribute (see CIA-DD table for additional information + connections with IFC / ETIM / standards)
AN116_IfcClassReference	the key provided for a specific references to classification items (or tables) (code: term), used in the examples here only with Autodesk Revit, it can then be exported as an IfcClassificationReference structure
AR320_MLevelRefDesignation	reference designation consisting of concatenated single-level reference designations (e.g. the door lock belongs to the door, both are construction components, and to refer to the door lock, two codes of the same level separated by a dot are used: QQC01.RLA01); to use the multilevel reference attribute, this component should be separately selectable, and we also depend on whether it is modeled separately or not
AR340_RefDesignation	identifier of a specific object formed with respect to the system of which the object is a constituent, based on one or more aspects of that system (e.g. a component can be assigned as QQA01%QQA10, where QQA01 represents the ComponentID value and QQA10 the component type value, and the % sign marks the beginning of the type identifier)
AR360_UniqueID	collection of two or more reference designations assigned to an object of which at least one unambiguously identifies this object (e.g. if we want to mark the location of a door (building component) in a specific wall (technical system) that belongs to the external wall system (functional system), we can write it: B1001.AD5001.QQC01%QQC10 )

Separators defined in the EN IEC/ISO 81346 standard series are used for combining properties, which have a specific meaning and thus help to navigate more easily when it comes to a combined value.

Character/symbol	Description
.	(dot) is generally used as a separator between two different codes, which individually refer to different tables, either simply as a letter code, with a type number or as an ID (e.g. B.AD – here the functional system code (B) is distinguished from the technical system code (AD) )
=	(equal sign) as related to the functional aspect of the object (e.g. a wall system can be referred to as =B )
–	(minus) as related to the product aspect of the object (construction element)
+	(plus) when related to the host installation aspect of the object (e.g. meeting room +BAB)
++	(2x plus) when related to the location-based aspect of the object (eg if the sofa is in the meeting room BAB, we add the room reference as: ++BAB)
%	(percent) when related to the type aspect of the object (e.g. we refer to a specific window type as %QQA10)
#	(bars) as related to other aspects of the object

If the previously discussed characters/symbols are intended above all to distinguish certain classifiers from each other or to emphasize an aspect of it, then in addition to them, additional reference features/symbols can come into play, which are included primarily in labeling (e.g. views to emphasize what something is presented by the code, because then we don’t have no longer the context of the property, only its value). It is very important to distinguish between the value represented by an attribute and the token that uses that value. These are different things! And as long as the value is a property in itself, you can do “whatever” with it, in other words, mark it with one or another reference identifier according to the information content requirements.

CCI-EE tables are currently marked with a two-letter code (e.g. CO – stands for component). In the CCI-EE guidelines, the examples are given precisely through these codes. If you want to refer to a component, the additional notation is used: <CO>

So, if I add a tag with the code QQA to the plan, it may not tell the user anything, while if I add an additional tag (reference): <CO>QQA in front of it, then I unambiguously determine that it is a window, because such code is used namely the window when viewed from the table of components <CO>.

Character/symbol	Description
/	(slash) is used if you want to mark/refer to two different affiliations (reference identifier) in one data field. For example, <CO>QQA/+<CS>BAA1001 means that we are talking about a window (QQA) that is in space BAA1001 (space reference as <CS>), the slash distinguishes two different reference identifiers, and the + means that we are talking about belonging to another element (see previous table)
< >	is used when you want to refer to a specific table/classifier from which the following code comes from. For example, <CO> represents a table of components. <CS> stands for table of built space. The short codes are from the CCI-EE table worksheets.

CCI-EE uses a two-letter code when referring to a specific table. However, it can also be done in the manner marked by ISO 81346-12, but with certain fundamental differences. Namely, the codes for the following tables are provided there (EN ISO 12006-2 extended view).

Letter code	CCI / CCI-EE table (follows partly EN ISO 12006-2 structure)
A	Actvity space
B	Built space
C	Construction complex
D	Construction aid
E	Construction entity
G	Construction agent
L	Construction element
P	Construction product
R	Construction process
S	Storey
Z	Zone

The following examples currently use CCI-EE, or two-letter codes. However, it doesn’t really matter in the grand scheme of things as long as one or the other is defined in the content requirements and the value of the attribute is kept clean (that is, not with a reference). For example, a value representing the room classifier as BAA and not <CS>BAA or <B>BAA, because these are already additional parts and we use them for example in tagging. Otherwise, this value is described by a very specific attribute.

In addition to the above, other features of the information content may also be included, but again using the CIA-DD code. Some examples can also be found in software templates. When including information content, it is worth taking into account whether its presence is necessary/important in the building information model or whether it is reasonable to include this information in another information system (information content resulting from the specifications, accompanying a specific CCI / CCI-EE component type/subtype, etc.). Accordingly, the scope of information content in the included templates has been kept to a minimum. Of course, the context of the client/participant in the project always comes into play here, which information content is needed!

Following the CCI-EE logic, in addition to the classification of construction elements, the construction resources associated with them can also be defined, or the stage of the project, etc. There are separate attributes to describe this that can be found in the CIA-DD table but are not covered here.

In the following subsections, we will discuss more specific examples in which the previous principles have been applied. Although the software examples are limited, the principles used therein can be applied to any software that a particular user prefers. However, in the more technical part (which follows the more general examples), we will take a closer look at how the software templates presented in this post are structured and how to implement the classification system in specific software.