openBIM glossary

The standards are published by buildingSMART International, a non-profit body that maintains IFC, BCF and IDS among others.

The point is practical rather than ideological. A construction project involves architects, structural engineers, MEP designers, contractors and clients, and they will never all buy the same software. openBIM is what lets a structural engineer using one application and an architect using another exchange a model and argue about it productively.

IFC is standardised internationally. IFC4 is published as ISO 16739-1:2018, and IFC4.3 was approved as ISO 16739-1:2024.

An IFC file describes not just shapes but what each shape is — a wall, a door, a duct — along with its properties, materials and relationships to other elements. That is what separates IFC from a plain 3D format such as OBJ or glTF: a 3D shape tells you an object exists, while IFC can tell the receiving software that the object is a load-bearing wall with a two-hour fire rating.

The practical consequence is that an IFC model stays queryable. You can ask it which walls are load-bearing, filter by storey, or check whether every door has a fire rating — none of which is possible with geometry alone.

IFC2x3 dates from 2006 and remains the workhorse. IFC4 was released in 2013 and standardised as ISO 16739-1:2018. IFC4.3 extended the schema to infrastructure — roads, bridges, rail and ports — and was approved as ISO 16739-1:2024.

Newer is not automatically what you will be sent. Many established export presets were configured around IFC2x3 years ago and never revisited, so IFC2x3 files still arrive routinely on live projects. A viewer that only reads the newest schema is of limited use in practice.

Bimlyte opens IFC2x3, IFC4 and IFC4x3.

A BCF file carries the comment, the status and the exact camera position in the model, but references the model rather than containing it. That is the whole design: instead of emailing a 500 MB model back and forth to point at one column, you send an issue that says which column, seen from where, and what is wrong with it.

The result is a file small enough to attach to an email, which is why BCF became the practical currency of BIM coordination rather than a specification nobody used.

BCF 2.1 was released in October 2014 and BCF 3.0 in June 2021. In 3.0, project values such as statuses and priorities are stored as ordinary data instead of in an XSD extension schema, and required fields, documents and viewpoints are defined more precisely.

Because tools across a single project rarely agree on a version, converting between them is an ordinary chore rather than an edge case. Converting downward can mean data that has nowhere to go; converting upward can mean fields that must be filled in first.

The filename tells you nothing — both use the .bcf extension. A bcf.version file inside the archive declares which schema the package actually uses.

A topic carries a title and description, a status and priority, a type, an assignee and a due date, a thread of comments, and one or more viewpoints showing where in the model it applies.

Most tools call this an "issue" in their interface, while the BCF specification itself calls it a topic. They are the same thing, and the mismatch trips up people reading the spec for the first time.

A BCF file is essentially a container of topics — exporting "a BCF" means exporting a set of them.

Alongside the camera position it records which elements were visible or hidden, any section planes in use, and which elements the issue actually refers to.

This is what makes BCF useful rather than merely descriptive. Opening a viewpoint puts you in the same place in the model as the person who raised the issue, so "the clash near the stair core" stops being a guessing game across a 40-storey model.

A single topic can hold several viewpoints — useful when a problem is only clear from more than one angle.

It is the part of BCF that survives contact with people outside the BIM team. A client, a site manager or a subcontractor can look at a snapshot in a PDF report and understand the problem, with no software and no training.

Snapshots can be marked up with arrows, text, shapes and highlights, so the specific point being made travels with the issue instead of living in a separate email.

It answers the question "did we get what we asked for?" without a human opening the model and checking property by property. A specification written as IDS can be run against a delivered IFC automatically, producing a pass or fail per requirement.

The problem it solves is real and expensive: information requirements have traditionally lived in PDF documents that nobody could check mechanically, so compliance was discovered late or not at all.

IDS support is in development in Bimlyte.

Nothing is merged. The architectural, structural and services models stay under their own authors, and federation is simply the act of loading them into the same coordinate space and looking at them together.

That is where most clashes surface, because a duct passing through a beam is invisible while each model is viewed alone. It is also why coordinate systems and shared origins matter so much: models that do not align produce clashes that are not real and hide ones that are.

For BIM this matters commercially, not just philosophically. If a model never leaves the device there is no upload to justify to a client, no third-party server holding NDA-covered geometry, and no account for anyone to audit or breach.

It also changes what happens when things go wrong in either direction: the tool keeps working when the network does not, but nobody can restore your work for you either, because no copy exists anywhere else.

The storage is isolated from other sites and invisible to the rest of your file system — a site can only reach its own OPFS area, and nothing else on your machine.

It is what makes handling a large IFC model in a browser practical rather than theoretical, because the model can live on your device between sessions instead of being re-parsed from scratch every time.

Because that storage belongs to the site on your device, clearing the site’s data deletes it. This is exactly why an exported package is the right way to keep a copy of anything you care about.

It can optionally be protected with a password, and the recipient needs no BIM software and no account: the package opens in a browser.

The distinction from IFC or BCF is scope. IFC carries the model and BCF carries the issues; neither is meant to restore a working session, with its saved views, selections and viewer state intact.

It is also the practical way to move a project between devices, since local-first storage does not sync on its own — and the right way to back one up.

That independence is the point: reviewing a model should not require a licence for the tool it was designed in, which on a project with five disciplines would mean five licences for anyone who needs to look.

A browser-based IFC viewer goes a step further by needing no installation at all. This matters on locked-down work machines where installing software requires an IT request, and on macOS or Linux where many desktop BIM viewers simply do not run.

The distinction from a viewer is that a manager writes as well as reads: it produces standard BCF files other tools can consume, and it handles comments, statuses, attributes and viewpoints as editable data.

In a working coordination loop that is the difference between participating and observing. A viewer lets you see what someone else raised; a manager lets you answer, reassign, close it and send the result back.