Using other people's models

There is no central model.

Working in Bonsai, your project is an IFC file in a folder, and so is everybody else’s. If you have worked in Revit’s worksharing or ArchiCAD’s Teamwork, nothing here corresponds to them: no authoritative copy of the project that everybody else takes a local file from, no elements to reserve before you are allowed to edit them, and no moment at which somebody else’s work arrives in yours because a synchronise button was pressed.

To anybody trained on a system built around a shared database, that will read as a list of missing features. It isn’t one, and the reason turns out to be about professional responsibility rather than about software.

This page is about working alongside other organisations. Working alongside your own colleagues, on one model, is a different question, covered under revisions.

Why models are separate in the first place

The ordinary Open BIM arrangement looks like this: the architect, the structural engineer and the services engineer each work in their own tool, each exports an IFC of their own model, and everybody assembles the exports to look at the building as a whole.

That assembling is what federation means: you bring the file somebody else produced into your own session read-only, so their building and yours occupy the same space and you see the whole thing at once. Several models, one view of the project, each part still belonging to whoever made it.

In that arrangement the sharing only goes one way. Each party’s real model lives in their own software, in that software’s own format, and the IFC they send out is an export of it: you can edit the export, but nothing you do to it reaches the model it came from. So federation is the only thing on offer.

Working natively in IFC removes that constraint. The file everybody has is the file, and anybody holding it can edit it.

So why keep them separate anyway?

Because the boundaries are real, and they aren’t technical.

The structural engineer’s model is a separate file because the structural engineer is answerable for it. It carries their name, their decisions and their professional liability, and none of those things become yours because your software could open their file. The separation between federated models is an ownership boundary drawn in the place where responsibility actually changes hands.

That is a better reason than the industry’s usual one, and it survives the removal of the technical constraint.

It also explains the shape of the tools. A model you link into your session comes in read-only, not because the software isn’t clever enough to write to it - nothing stops you opening somebody’s file outright - but because read-only matches where the responsibility sits: you can see their work, and you can’t quietly change it.

Inside one office there is no such boundary

Between you and the colleague at the next desk there is no boundary of responsibility to express: you are answerable for the same model, to the same client, under the same appointment. So federation is the wrong shape for that job. You work on the one model, all of you, and the work is brought together by merging.

There is very likely a server in that arrangement, since the usual way to do it is a shared repository that everybody sends their work to. A repository isn’t a central model, and the difference is exact: it keeps the history of the project rather than the live document, everybody holds a complete copy of both, and nothing is reserved or checked out. It is somewhere to send revisions, not somewhere the model lives.

The rule of thumb: federate across a boundary of responsibility, and merge within one.

Linking is how you federate

The two words are one thing seen from two ends: federation is the arrangement, linking is what you do to get it, and the mechanism is ordinary. You reference somebody else’s .ifc into your session and it loads in the background, read-only. You can see it, snap to it, check yourself against it, hide it when it is in the way, and reload it when they send a new one. Link three consultants’ files and you have federated the project; there is no further step, and no combined file is produced.

Linked models only line up if the files agree about where the building is. Each file states its own origin and its own georeferencing, so that agreement is something to settle with the other parties at the start; a linked model that turns up a long way from yours is two files disagreeing about coordinates, not a broken link.

Two practical details. Links can be stored as relative paths, so a project folder full of models can be moved or handed on as a unit without every reference breaking. And a link can carry a query, written in the same selector syntax you use to find things, so you can pull in only the structural frame from a model that also contains every bolt. The documentation’s guide to large and federated models covers the practicalities.

What replaces the central model is a folder of files and an understanding of who owns which - less magical, and considerably easier to reason about when somebody asks who changed something.

Issues travel separately

The thing federation still needs is a way of talking about the building that isn’t a phone call, and that is BCF - the BIM Collaboration Format.

A BCF issue is a topic with a title, status, author and comment thread, and crucially a viewpoint: a camera position, and a note of which objects it is about, each named by its GlobalId, the identifier an object keeps in whichever file it turns up in. Open somebody’s issue and your view moves to where they were standing and highlights what they were pointing at. It is the difference between “the duct clashes with the beam near the stair” and being taken to it.

BCF is a standard rather than a Bonsai feature, so issues raised in one program can be answered in another. What travels is a file - a .bcf you email, or drop in the project folder beside the models. Reading and writing that file is the whole of what Bonsai does here.

This is also the honest qualification on the carrier bag: not everything about a project is inside the .ifc. The conversation about it travels alongside, deliberately, because an issue is frequently about two models at once and belongs to neither.

Clash

Once you have several models in one place, the obvious question is whether any of them are trying to occupy the same space.

Clash detection takes sets of elements - within one model or across several - and reports where they intersect, or come closer than a clearance you have specified. The elements are chosen with the selector syntax, so “structural columns against ductwork” is a thing you can state rather than a selection you have to make by hand. Related clashes are grouped, so that a duct crossing forty joists is one problem rather than forty, and they come out as BCF - as issues you send to whoever owns the model that is in the way.

It also runs from a command line, as ifcclash, over a folder of consultants’ models at a time.

Clash detection isn’t checking the model: that measures one model against a written requirement, and this finds several models disagreeing about space.

Last updated 8 October 2026.