Types and occurrences

Bonsai keeps your model as IFC, a published open standard that defines what a type is: a wall type and a wall are two different objects. The wall standing in your building is an IfcWall, and a relationship entity in the file says that this wall is an occurrence of an IfcWallType - IFC calls an occurrence what other software calls an instance.

Fifty walls with the same construction are fifty occurrences pointing at one type definition. Change the type definition and you have changed the construction for all fifty.

The type carries whatever is true of the construction rather than of any particular wall - properties, and materials. The occurrence keeps what is unique to the wall itself: where it stands, what it is called, which storey it is on, and any additional properties you have attached to that one wall.

Three kinds of type

A wall’s thickness and a stair’s number of treads both belong to the type. What the type delegates to each occurrence is different, because the word type covers three arrangements.

A type can be a reusable block. The traditional CAD idea: the type carries geometry, and every occurrence is that geometry, placed somewhere. A chair, a bollard, a light fitting. Bonsai’s parametric objects work this way too - a window, a door, a stair - and the consequence is the one people trip over. The parameters belong to the type, not to the occurrence. A stair type holds one number of treads, one going and one rise, and its occurrences take their geometry from it. If you want a stair with a different number of treads, what you want is a second type.

A modular building made entirely of prefabricated components will be mostly this kind of type.

A type can be a definition of a construction. Here the type carries no explicit geometry at all. It carries a material layer set - the layers, their materials and their thicknesses, in order - or a material profile set, which is a cross-section, possibly a composite one.

Examples would be a 300mm cavity wall type, or a 254x146x31 Universal Beam type.

Most buildings use this second kind of type.

Here the type fixes the section, not the extent. Every wall of that type has that build-up and therefore that thickness, while each is its own length and its own height. The type says what it is made of; the occurrence says how much of it there is.

It is why a door type carries a full set of dimensions while a wall type carries rather less: the wall’s remaining dimensions aren’t missing, they belong to each wall.

A type can be a bare label. Carrying no geometry and no material, it constrains nothing: a name with some properties attached, whose occurrences are free to be any shape, or none at all. Two occurrences of such a type can look nothing like each other and the file isn’t wrong.

So look at the type before assuming what it does. Nothing in its name tells you which of the three you have, and they behave completely differently.

Where the family analogy stops

If you are coming from Revit, types are the nearest thing to families, and the analogy is close: definition separate from instance, edit the definition and the instances follow. It differs in two ways. One is the three kinds of type above; the other is this:

A type is optional. A wall with no type is a perfectly legal wall: it carries its own properties and its own materials and stands there being a wall. This is unlike the Revit world, where everything is of a family whether you like it or not, and it explains a model that arrives with no types: it may genuinely have none.

The other thing called “type”

Two different ideas in IFC are both called type in ordinary conversation.

The predefined type is the second half of an object’s classification - an IfcWall may be PARTITIONING or SHEAR, from a list the schema publishes. It is an attribute of the object, and part of the standard vocabulary.

A type object, by contrast, is what this page describes: a separate entity in the file, which other objects point at. An IfcWall can perfectly well have a predefined type of PARTITIONING and reference no type object at all.

Where content comes from

There is no vendor content library inside Bonsai and no marketplace you have to buy into. Two things fill the gap.

The first is that you build the types, which for the parametric kinds is quicker than it sounds - a wall type is a stack of layers with thicknesses, a door type is a set of dimensions.

The second is that you append them from another IFC file, because a library in Bonsai is just another IFC file. There is no separate content format to be locked into, no proprietary container, nothing to convert: the file is the document, and a library is a model you already know how to open. You point Bonsai at a .ifc file, browse what is in it, and bring across the types you want - one at a time, by a query, or grab the lot.

One condition: the library and your project have to be written to the same version of the schema. Point an IFC4 project at an IFC2X3 file and Bonsai declines to load it rather than converting it quietly. That is a decision you took on day one turning up months later.

Bonsai ships with libraries of its own, such as steel sections, furniture, entourage and landscape.

So, your last project is also a library. So is the model a consultant sent you, and so is a manufacturer’s IFC model of their product. You can also mark up types in your own file as library items and save it out for the office to share - the standard office library that most practices spend years failing to build is, here, a file on a shared drive.

Last updated 6 October 2026.