Lesson 3.2Lesson 3.2 · The Model & Its Objects
Geometry + Data: What an Object Carries
Every object is two things — and only one of them survives to run the building
Two doors are modelled identically. One has empty data fields. Only one is worth anything in ten years.
Look at two door objects side by side in a model. Same geometry, same appearance, same everything you can see. But open their properties: one carries its fire rating, material, manufacturer, cost and maintenance interval; the other has those fields blank. On screen they are twins. In reality one is a BIM object and the other is a shape pretending to be one.
We met this idea in lesson 1.1 — that the information is the point. Now we go inside the object to see *exactly* what it holds. Every BIM object is two things bolted together: geometry, which you see, and data, which you query. The geometry gets the design built. The data is what runs the building long after the geometry has become a real wall you can touch.
You can see the geometry. You have to go looking for the data. Guess which one clients pay for.
The two halves of every object
Open any object in a BIM model and it splits cleanly in two. The geometry is the shape and its placement — the size, form and position that let it draw itself into plans, sections and 3D views, and clash against its neighbours in space. The data is everything non-geometric the object knows about itself: its properties (fire rating, U-value, acoustic rating, finish), its cost, its manufacturer and model, its warranty and maintenance interval, its identity and classification.
Both halves matter, but they serve different masters. The geometry serves *coordination and construction* — getting the building designed and built without things colliding. The data serves *scheduling, analysis and operation* — counting, pricing, analysing, and eventually running the building. A pretty object with rich geometry and empty data can be drawn and coordinated, but it cannot be trusted to answer a single question about the building — which is the whole reason BIM exists.
What the data actually is: properties, identity, classification
The data an object carries falls into a few honest categories. Properties describe how it performs and what it is made of — a fire door's rating, a wall's thermal value, a pump's flow rate. Identity pins down which real thing it is — its type mark, its manufacturer and model, its serial or asset number once installed. Classification places it in a shared, industry-standard filing system — schemes such as Uniclass or OmniClass in the wider world, and the structured fields that COBie asks for at handover — so that everyone's 'door' means the same thing and software can group, count and exchange objects reliably.
In the open world these travel as property sets on the IFC object (Module 4), which is how the data survives moving between different software. The key idea is that this data is *structured* — it lives in named fields with expected values, not in a free-text note — because structure is what lets you query it: 'list every 60-minute fire door on level 3 by manufacturer' is only answerable if 'fire rating' and 'manufacturer' are real fields, filled reliably, on every door.
Geometry gets it built. Data gets it counted, costed, analysed — and, in ten years, repaired.
Empty fields are the silent failure
Here is the honest trap. A model can look complete and be hollow. Objects modelled to perfect geometry, beautifully coordinated, clash-free — and with their data fields blank or wrong. Nothing on screen warns you, because the failure is invisible: an empty 'fire rating' field looks exactly like a filled one until you try to schedule it.
This is the operational form of 'garbage in, garbage out'. Blank data means the schedule is short, the quantity is missing, the analysis is starved, and the facility manager who inherits the model at handover finds a beautiful geometric shell with nothing to operate. And data that is *wrong* is worse than data that is *absent*, because absent data announces itself as a blank while wrong data is trusted. This is precisely why the information must be required (the client states what data they need — the EIR of Module 5), assigned (whose job is it to fill which field), and checked (validated before anyone relies on it). An object is only as valuable as the data it actually carries — not the data it has fields for.
Three altitudes on the same idea
Read the band that fits you — or all three.
Learn the two halves. Every BIM object = geometry (the shape you see, used to draw and coordinate) + data (the non-geometric facts: properties like fire rating and U-value, identity like manufacturer and mark, and classification that files it in a shared system). The geometry gets the building designed and built; the data lets it be counted, priced, analysed and operated. Remember the twist: two objects can look identical while one has all its data fields filled and the other has them blank — and only the filled one delivers what BIM is for.
Fill the fields that will be used — and only those. Your job is not to stuff every object with every possible property; it is to carry the data the project actually needs, structured and reliable. Know which properties, identity fields and classification your deliverables and handover require, put them at the right level (type vs instance, from lesson 3.1), and fill them as you model rather than in a panic before handover. Watch for the silent failure: geometry that looks done but data that is blank or wrong. A validated object with the right fields filled beats a gorgeous one with empty properties every time.
Specify the data, then verify it. The value of a model at handover is its data, so the data cannot be left to chance. Define what information each object must carry (properties, identity, classification) against the project's actual uses and the operator's needs — this is the substance of the information requirements (EIR) and the classification standard you adopt. Assign responsibility for filling fields and build validation to catch blanks and errors before they are trusted. A model whose objects have the right fields, filled and checked, is an asset; the same model with empty fields is an expensive picture that happens to be coordinated.
“If the model is fully modelled and looks complete, its data is complete too.”
Do it yourself
Interrogate one real object as if you were the facility manager who inherits it.
- 1Pick a single component near you — a door, a light fitting, an air-conditioning unit. Write down its geometry: size, shape, position. That is the half you can see.
- 2Now write its data in three groups: properties (rating, material, performance), identity (manufacturer, model, a tag/asset number), classification (what family of thing it is, in plain words).
- 3Ask a query that needs the data, not the shape: 'how many of these are there, who made them, and when are they next due for service?' Notice that the geometry cannot answer any of it — only the data can.
- 4Finally, blank out one field in your mind — say the service interval. Note that nothing about the object *looks* different, yet the facility manager can no longer plan its maintenance. Write one line: why is an empty data field a silent failure, and whose job is it to have filled it?
The one line to carry out
If an object is geometry plus data, a fair question is: how good does each half have to be, and when? Answer it wrong and you either over-model or mislead. Next: Level of Development — the field's most-confused idea, and it is not about detail.
The author
Amogh N P
Architect, interior designer, and creative polymath. Studio Matrx began in his notebooks — his vision of design made honest, useful, and open to everyone. Its Academy is written and taught in his memory, and free, forever.
More about Amogh →