Other people's models

There is no central model.

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 is worth understanding why it is not, because the reasoning turns out to be about professional responsibility rather than about software.

Two questions are tangled together in that, and they have different answers. Working alongside other organisations is this page. Working alongside your own colleagues, on one model, is a page away.

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 sharing only goes one way. What each party publishes is a view of a model that lives somewhere else, in a format they cannot edit and would not be allowed to. Federation is the only thing available, because the alternative - actually editing somebody else’s model - is not on offer.

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

So why keep them separate anyway?

Because the boundaries are real, and they are not 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 one the industry has been using, and it survives the removal of the technical constraint. A reader arriving from a central-model system tends to assume the separation is a limitation being worked around. It is a professional arrangement being expressed accurately.

It also explains the shape of the tools. A linked model comes in read-only, and not because the software is not clever enough to write to it. Nothing stops you opening somebody’s file outright if they have sent it to you. What linking gives you is the arrangement that matches where the responsibility sits: you can see their work, and you cannot quietly change it.

Inside one office there is no such boundary

Which is the other half of the same reasoning, and it is worth being explicit about, because the first half is easily over-read.

Between organisations the separation is real and worth keeping. 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 - which is Revisions, and is the arrangement software developers have used on shared work for decades.

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 is not a central model, and the difference is worth having exactly: 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 survives both halves. Federate across a boundary of responsibility, and merge within one.

Linking

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.

Two details are worth knowing. 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 - the same one from Finding things - so you can pull in only the structural frame from a model that also contains every bolt.

What replaces the central model is therefore a folder of files and an understanding of who owns which. That is less magical and considerably easier to reason about, particularly at the point where somebody asks who changed something.

Issues travel separately

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

A BCF issue is a topic with a title, a description, a status, an author and a comment thread, and crucially a viewpoint: a camera position, and a note of which objects it is about. 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. Bonsai handles both the file form, which you can email, and the server form, for teams running an issue-tracking service.

This is also the honest qualification on the carrier bag in The model is a graph of standard objects. 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, where they collide, and where they come closer than a clearance you have specified. The elements are chosen with the query language again, so “structural columns against ductwork” is a thing you can state rather than a selection you have to make by hand. Results group related clashes together, so that a duct crossing forty joists is one problem rather than forty, and they come out as BCF - which is to say, as issues you send to whoever owns the model that is in the way.

Two kinds of checking, kept apart

It is worth ending on the distinction this page shares with the last one.

Clash is several models disagreeing about space. Checking the model asks something else entirely - whether one model holds what somebody specified. Both get described as having checked the model, and a project that has done one has not thereby done the other.

And both are separate again from how one model changes over time, and how several people change it together. Those are Revisions.

Last updated 5 September 2026.