I remember as if it had been yesterday. One of those early days on the New Stavanger University Hospital project, when I still felt like a guest at the grown-ups’ table.
My boss called me and discussed project challenges. Afterwards presented me with a long to-do list. Most of them were data validation exercises.
And, as usual on big projects, nobody had enough time – yet the deadlines didn’t care.
I opened Solibri with the confidence of someone who thought data validation was just another checkbox on the list. I still vividly remember staring at 140 IFC models and thinking: “Well, how hard can it be?”
A few hours later I learned the answer.
Fifteen different checking rules checking only five properties. Rules overwriting one another, sometimes even contradicting one another. Multiple issue results generated on the same element — for no logical reason.
It was like walking through the dense jungle. I couldn’t figure out what is right and what is wrong. And the clock was ticking – the model has to be checked by Friday.
I was not a seasoned BIM coordinator back then, but I did my best to present a professional face while quietly panicking inside. That first week taught me a painful truth: a good IFC data validation process simply did not exist. And for big projects with strict data requirements this gap becomes brutal.
Why Our IFC Data Workflows Keep Failing
Let’s be brutally honest for a moment. Our industry still treats data as something optional, something we “deal with later”.
I have two biggest annoyments here I want to share with you:
- Creating data requirements is unforgivingly tedious – industry and national standards are largely non-existing or inconsistent.
- Data validation process is neglected – very few tools can actually perform reliable IFC data validation, and even fewer make it pleasant.
Raise your hand if any of this sounds familiar:
- Requirements live in ten different files and no one knows which one is the latest.
- Designers deliver models that appear correct at first glance… until you check what’s inside the IFC.
- Validation software screams about errors that make no sense.
- Property names vary depending on who exported the model.
- Two people reading the same requirement interpret it differently.
What makes it even more frustrating is that we all try to do things properly. Designers do their best. Coordinators do their best. Even the client does their best.
Yet the workflows we depend on are built on:
- PDFs and spreadsheets meant for humans, not machines
- Excel sheets maintained by three different people
- Requirements that contradict each other
- Half-manual validation processes that drain hours every week
As a matter of fact, the bigger the project, the worse it gets. Each discipline has their own understanding of requirements. Multiply that by dozens of IFCs per week, and you get a level of chaos no rule set can survive.
We don’t lack effort. We lack structure. And this lack of structure is exactly what turns small issues into full-blown project complications.
What This Looked Like in Practice
1. Creating Data Validation Rulesets
I use Solibri for data validation. It’s one of the very few tools on the market that can actually do it.
But its standard validation library is extremely thin. I spent countless hours fine-tuning rulesets trying to achieve two things:
- Reliable results
- No flood of false positives
It was cumbersome, required endless testing, and still produced disappointing outcomes:
- Multiplying the same issue across one component
- Reporting correct data as wrong due to missing requirement functionalities
And the worst part? Every time I improved one rule, two others broke. It felt like debugging spaghetti code written by five different people on five different days.
2. Manual Work Before Every Validation
Before each model check there was a long preparation routine. I had to:
- Download IFC
- Load rule sets
- Adjust filters
- Reset context
- Run checks
- Go through thousands of issues, many duplicated
- Separate real issues from noise
- Create presentation
- Export BCF
- Notify disciplines
I could automate some of these steps, but even after doing that, sometimes by the time I finished, the designers had already uploaded a new version. It honestly felt like chasing a bus you can never catch: the moment you think you’re close, it pulls away again.
3. Copy–Paste Requirements Disaster
When the new SUS phase began, we thought it was going to be easy-peasy and we could just reuse requirements from phase 1.
We were wrong.
Adjusting requirements from the previous phase resulted in:
- A massive property auditing job
- Changes in shared parameters file for all disciplines
- Assessing the duplicates and naming convention
- Conflicting logic
- Long communication loops with all stakeholders creating data
Two full weeks of cleaning. Only to reach a point where we could start fixing the actual problems.
And in the meantime designers had to design – so they were using the data requirements from the previous phase – hence we ended up wasting time to align them afterwards.
At that moment one thing became clear: Our workflows were too fragile to survive in the long run.
| Property name | Object Type | Description | Requirement | Data format | Example | Project stage | |||
|---|---|---|---|---|---|---|---|---|---|
| Early Design | Detailed Design | Construction | Operation | ||||||
| Name | IfcBuilding | Building code | Must | [NN] | 81 | X | X | X | X |
| Name | IfcBuildingStorey | Floor number | Must | [NN] | 01 | X | X | X | X |
| IsExternal | All walls, columns, slabs | Defines if the object is external or internal | Must | True/False | True | X | X | X | X |
| Drop | Ducts, pipes | Defines drop of the element | Can | N.N | 0.2 | X | X | ||
| AirflowMin | Air Terminals, ducts, flow dampers | Minimal value for designed airflow rate | Must | [NN] l/s | 100 l/s | X | X | X | |
An extract from IFC requirement table created as a PDF document.
There Had To Be a Better Way
Before I reveal what finally made this manageable, let me emphasise this:
The problem was never the designers. The problem was the system.
At some point, not long ago, having in mind my data validation “adventure” and endless copy–paste archaeology with updated requirements, I realised something had to change.
We needed a way to make requirements clearer, easier to check, and less open to interpretation.
Not another PDF.
Not another Excel.
Not another rule set that collapses when you sneeze near it.
We needed:
- A method that finally brings order into that madness.
- A method that removes interpretation.
- A method that designers can validate before exporting IFC.
- A method that makes federated checks predictable instead of painful.
And yes — such a method exists.
But explaining it here would not do it justice.
You need to see it.
Invitation to the Workshop
If you feel that your OpenBIM workflow is full of chaos, unclear requirements and unpredictable data checks, you are not alone. I’ve been there. Many times. As a matter of fact, I still flinch when I see a folder called “properties analysis”.
Bear in mind – we don’t solve these problems with more effort. We solve them with better structure.
If you want to finally understandIFC data validation should work in a real OpenBIM workflow – without turning this article into a 5000‑word lecture – join our free workshop.
Join the Live IFC Masterclass
📅 Date: Tuesday, November 25, 2025
🕓 Time: 16:00–18:00 CET
💻 Location: Online (Free Registration)
What you will see live:
- What is IFC schema and how information is structured
- How unclear requirements actually break in real projects
- A live demonstration of a structured requirement format (the one that saved my sanity).
- How to export model to IFC with correct data structure
- How can we validate model data.
- An example of communicating the issues
If any of this sounds interesting, join us – and bring your most painful OpenBIM headache with you.
We’ll tackle it together.
If the button doesn’t work, register here.
