openBIM, IFC, BCF, IDS, and bSDD: What They Mean

Information only — not legal advice.

openBIM is an approach to digital built-asset information that favors open standards, transparent exchange, and collaboration across different software tools and organizations. It is not a single file type and it is not a single product. It is a way of making information usable beyond one vendor, one discipline, or one project phase.

The main idea is control of information. A project team should be able to create, exchange, check, discuss, and reuse built-asset information without forcing every participant into the same proprietary environment. That matters because built assets are designed, built, maintained, refurbished, and operated by many parties over many years.

buildingSMART describes openBIM as a way to enable data sharing and collaboration across platforms and stakeholders. In practice, openBIM depends on agreed standards, clear exchange purposes, consistent terminology, and a disciplined information process. The standards do not replace project management; they make project management less dependent on private file formats.

IFC: structured model information

IFC means Industry Foundation Classes. It is the best-known openBIM standard and describes built-asset information in a vendor-neutral way. IFC is not only a file extension. It is primarily a data schema: a structured way to describe objects, properties, relationships, classifications, systems, spaces, processes, resources, and other built-environment concepts.

An IFC exchange may appear as an IFC file, but the file is only one way of serializing the IFC data. The important point is that IFC gives different tools a common language for model information. A design authoring tool, coordination viewer, checking tool, analysis tool, asset system, or archive can use IFC for a specific information exchange.

IFC is powerful, but it is not magic. An IFC export should be prepared for a purpose. A model for design coordination may not contain the same information as a model for energy analysis, quantity support, construction planning, or asset handover. If the exchange purpose is unclear, the IFC may be technically valid but practically disappointing.

As of 27 September 2026, buildingSMART lists IFC 4.3.2.0, commonly referred to as IFC 4.3, as the latest official IFC version and lists IFC 4.4 and IFC 5 as under development. This is the source-check date for the version statement, distinct from the later editorial update. Confirm the required version and tool support for each exchange.

BCF: issues and model-based communication

BCF means BIM Collaboration Format. BCF is for model-based communication about issues, topics, comments, viewpoints, and coordination matters. It helps teams discuss a problem in context without sending a full model every time.

A BCF topic can point to a model location, selected elements, a viewpoint, snapshots, comments, assignments, status, and other issue metadata. That makes it useful for clashes, design queries, quality observations, change questions, review comments, and coordination decisions.

BCF is not the same as IFC. IFC exchanges model information. BCF exchanges issue communication around model information. The two often work together: the model is exchanged or viewed through IFC, while issues about that model are exchanged through BCF.

BCF can be used through file-based exchange or through a web service/API workflow. In modern coordination, the API approach is often more practical because issue status, comments, assignments, and resolution history can stay synchronized in a shared issue environment.

IDS: testable information requirements

IDS means Information Delivery Specification. IDS is a buildingSMART standard for defining information requirements in a computer-interpretable form. In plain language, IDS lets a team specify what data should be present in an IFC model and then check whether the model satisfies that specification.

An IDS can require certain objects, classifications, properties, values, materials, or relationships. For example, a project may require doors to carry fire rating information, spaces to have classification codes, or selected equipment to include maintainable asset data. The value of IDS is that the requirement can be checked automatically instead of only being described in a PDF or spreadsheet.

IDS is closely tied to IFC. buildingSMART describes IDS as a way to specify how objects, classifications, properties, and values should be delivered in an IFC model. IDS is especially useful when a client or lead appointed party wants clearer exchange requirements and repeatable validation.

As of 27 September 2026, buildingSMART describes IDS 1.0 as an approved final standard. This dated version statement is separate from the worked example added on 22 October 2026; software support and later releases require their own check.

bSDD: shared definitions

bSDD means buildingSMART Data Dictionary. It is a service for shared definitions of built-environment terms, classes, properties, allowed values, units, translations, and relationships. The point is semantic consistency: different people and tools should understand the same term in the same way.

bSDD is not a project file store and it is not a replacement for IFC. It is a shared vocabulary service. It can help teams choose consistent names and definitions for information requirements, properties, classifications, product data, and model checks.

The relationship between IDS and bSDD is especially important. IDS can define what information must be delivered. bSDD can provide consistent definitions for the terms used in that requirement. Together, they help reduce ambiguity in model data.

How the standards work together

A simple openBIM workflow might look like this. The client defines information needs. The delivery team translates those needs into exchange requirements and, where useful, IDS checks. Model authors create information in their chosen tools. The team exchanges model data through IFC for specific purposes. Reviewers communicate model issues through BCF. Shared terms and properties are aligned through bSDD where suitable.

The workflow only works when the team agrees the purpose of each exchange. IFC should not be treated as a general dump of everything inside an authoring model. BCF should not become an unmanaged message archive. IDS should not be introduced only at the end when the model is already difficult to correct. bSDD should not be used as decoration; it should support agreed terminology.

A useful way to remember the difference is this: IFC carries structured model and asset information, BCF carries model-based issues and communication, IDS defines and checks information requirements, and bSDD helps define the terms used in the information. openBIM is the wider principle that connects them.

What open standards do not guarantee

There are common misconceptions. One is that using IFC automatically means openBIM success. It does not. A poor export, unclear exchange purpose, missing properties, wrong coordinate setup, or weak acceptance process can still fail. Another misconception is that openBIM means avoiding native files entirely. Many projects still use native files for authoring and open standards for agreed exchanges, checking, coordination, archive, and handover.

Another misconception is that open standards remove the need for a CDE or information governance. In reality, open standards make governance more important. Teams still need to know which file is current, what status it has, who accepted it, what issue remains open, which requirement it satisfies, and what information was delivered at each milestone.

Choose a standard for a defined task

For project teams, the practical question is not which acronym sounds modern. The practical question is what problem each standard solves. IFC helps exchange model data. BCF helps discuss model issues. IDS helps define and test requirements. bSDD helps align meaning. A BEP or information management plan should say when each one is used.

A workspace platform can support openBIM-adjacent work by keeping records, issue decisions, delivery dates, responsibility registers, review tasks, and handover evidence organized around the model exchange process. The platform does not need to author the model to support the information trail around it.

Worked example: checking fire-door information

Consider an illustrative handover requirement: every fire door in the agreed scope must have a stable identifier, location, specified fire rating and a reference to its supporting product document. The project's responsible designer defines the required performance; the exchange rules define how it is recorded.

A validation report finds 12 doors without the required value. The coordinator groups the findings by responsible team and returns a BCF topic with the relevant model revision. The author corrects the source model, exports again and reruns the agreed IDS check. The reviewer compares the changed data with the design requirement and product evidence before accepting the exchange. A passing property check alone cannot establish that the installed door achieves the required fire performance.

A practical exchange checklist

• Agree the IFC version and exchange scope that both tools actually support.
• Test a sample containing typical objects and an awkward edge case.
• Check coordinates, units, identifiers and property mapping after export.
• Define which requirements are automated and which need professional review.
• Return issues with an owner, exact revision and useful viewpoint.
• Recheck corrected information and retain the report with the accepted package.

WorkStudio Records can keep the issue decision, responsible person and evidence connected to a project using the connected-information guide. Model export and IDS validation remain tasks for the appropriate BIM software; packages and available services.

Sources and related reading

Useful references: buildingSMART openBIM, buildingSMART IFC, buildingSMART BCF, buildingSMART IDS, buildingSMART bSDD.

Related: What Is BIM?, BIM Execution Plan, Model Coordination and Clash Detection, Information Requirements in BIM.

Important information

This article provides general information and does not constitute legal advice or replace a qualified professional's assessment of your circumstances. Laws, official guidance, standards and product features can change. Check current primary sources and the requirements applicable to your jurisdiction, contract and project before making decisions. Examples illustrate the discussion; they are not official rulings or instructions for a particular case. For legal decisions, consult a qualified lawyer; for technical or other specialist matters, consult the responsible professional.