Coulter BIM Information Management

Over the last few weeks, I’ve been rebuilding our Responsibility Matrix to align more closely with IFC 4.3 and the way deliverables are structured in ISO 19650 projects.

Rather than just listing deliverables under Uniclass 2015 System (Ss) codes — such as “Architectural,” “Structural,” or “Mechanical” systems — I’ve started using IFC classes to define each element type, for example IfcBoilerType, IfcFanType, IfcCurtainWallType, and so on.

It’s a much clearer way to show who’s responsible for what.

Why bring IFC into the Responsibility Matrix?

I used to use Uniclass 2015 System (Ss) codes to structure our Responsibility Matrix.
While they’re extremely detailed and useful for classifying design elements, I found them too granular for a matrix format — particularly when you’re trying to assign clear accountability across multiple disciplines.

By contrast, IFC provides a concise and functional layer that’s easier to manage at project scale.
Each Ifc class represents a logical deliverable (e.g. a wall, pump, valve, light fixture), without descending into part-level complexity.

That said, I still use Uniclass PM codes for drawings, documents, and other deliverables, as they work perfectly for those categories and link neatly into TIDPs and MIDPs.

By combining both systems — IFC for physical elements and Uniclass PM for project deliverables — the matrix becomes far more structured and readable.

My format

For example:

IFC Class Subcategories

• IfcActuatorType ELECTRICACTUATOR, HANDOPERATEDACTUATOR, HYDRAULICACTUATOR, PNEUMATICACTUATOR, THERMOSTATICACTUATOR, USERDEFINED
• IfcAirTerminalType DIFFUSER, EYEBALL, GRILLE, IRIS, LINEARDIFFUSER, LINEARGRILLE, REGISTER, USERDEFINED
• IfcBoilerType STEAM, WATER, USERDEFINED
• IfcCurtainWallType USERDEFINED RA
• IfcRailingType BALUSTRADE, GUARDRAIL, HANDRAIL, FENCE, USERDEFINED
• IfcWallType ELEMENTEDWALL, PLUMBINGWALL, POLYGONAL, SHEAR, STANDARD, USERDEFINED
• IfcSpaceHeaterType BASEBOARDHEATER, CONVECTOR, FINNEDTUBEUNIT, PANELRADIATOR, SECTIONALRADIATOR, TUBULARRADIATOR, UNITHEATER, USERDEFINED
• IfcTransformerType CURRENT, FREQUENCY, VOLTAGE, USERDEFINED
• IfcWasteTerminalType FLOORTRAP, FLOORWASTE, GREASEINTERCEPTOR, GULLYSUMP, GULLYTRAP, OILINTERCEPTOR, PETROLINTERCEPTOR, ROOFDRAIN, WASTEDISPOSALUNIT, WASTETRAP, USERDEFINED
• IfcWindowType USERDEFINED

This mapping makes it far easier to see where design responsibility sits when federating models or producing the BEP and TIDP.

Landscape and external works

Landscape deliverables fit surprisingly well into IFC 4.3 — though some assumptions are still needed.
For example:

Fences aren’t their own class — they sit under IfcRailingType.

Kerbs, paths, and paving use IfcSlabType or IfcKerbType.

Planting uses IfcPlantType.

Street furniture (benches, bollards, bins) uses IfcFurnitureType.

Lighting remains IfcLightFixtureType.

Topography is part of the spatial structure via IfcSite.

So a fence line on a landscape drawing would map to:

IfcRailingType | BALUSTRADE, GUARDRAIL, HANDRAIL, FENCE, USERDEFINED | RA

Reflections so far

I’ve found IFC works better for defining model element responsibilities. It provides a common language that aligns with how models are structured, not just how information is classified.

It’s also made the process of checking models, reviewing BEPs, and building validation rules in Excel or Power Query much clearer.

An unexpected benefit is that this process has significantly improved my own knowledge of IFC classes.

I’ll admit, I hadn’t previously studied them in much detail — but once I began mapping them line by line, the logic of the IFC schema started to click.

It’s now much easier to discuss modelling responsibilities with engineers or contractors using a consistent framework.

The next step

The goal is to make the Responsibility Matrix more than a static table — to make it a data-driven link between:

Uniclass (PM / Ss / Pr)

IFC classes

Discipline responsibilities

Model validation and information delivery

Once this logic is consistent, the same data can drive:

TIDPs

BEP appendices

Model check templates

COBie mapping tables

Takeaway

Embedding IFC classes into your Responsibility Matrix is a small but powerful shift.
It connects ISO 19650 deliverables with the actual data being modelled, and it gives everyone — from architects to engineers — a shared, auditable structure.

The trick is not overcomplicating it:
start with the key IFC classes, mark them as RA, and evolve as your project maturity increases.