BIM Collaboration Format

What is BCF and why does it matter?

BCF (BIM Collaboration Format) is an open standard for exchanging coordination issues between BIM tools without sending entire model files. Instead of emailing a 500 MB model, one party sends a small package: a camera viewpoint, a list of component IDs, a comment thread discussing the clash, a status code, and optionally a snapshot image and assigned owner. The recipient's software jumps directly to that spot in their own model, where they can measure, modify, and reply.

The core insight is that BCF exchanges the issue, not the model. A clash between a duct and a beam is one piece of information; the entire building model is something else. This separation enables collaboration across software boundaries without any party losing control of their authoring environment.

What does a BCF issue contain?

A BCF "topic" contains a viewpoint (saved camera position and component IDs), a snapshot image showing the problem, a timestamped comment thread, and a status field (open, in progress, resolved, closed), plus priority and assignment. The entire package is stored as BCF-XML (an archive with XML documents) or synced live via BCF API between two servers.

The viewpoint uses component globally unique identifiers (GUIDs) that most BIM platforms can interpret. This lets the recipient understand the issue even if their software version differs. Because both parties reference the same model geometry by GUID, they can collaborate without sharing files.

How does BCF fit into the openBIM ecosystem?

OpenBIM uses open, non-proprietary standards for data exchange. IFC standardizes the model itself; BCF standardizes the conversation about the model. Together, they allow a practice using Revit, a structural firm using Tekla, and an MEP consultant using ArchiCAD to coordinate without anyone changing tools.

BCF is maintained by buildingSMART (the body behind IFC) and works across Revit, ArchiCAD, Tekla, and third-party viewers. This openness is why BCF is now expected in professional coordination; without it, all parties would be locked into one software ecosystem.

What are the two ways to transport BCF?

BCF can travel by two mechanisms, each suited to different team structures.

For small single-family houses with two consultants meeting weekly, file-based BCF is sufficient. For multi-storey projects with daily coordination and multiple stakeholders, API-based BCF ensures no one works from an outdated issue list.

How does BCF fit into clash detection and coordination?

Clash detection automatically scans the federated model and flags spatial conflicts. The detection tool generates a report of hard clashes (overlapping volumes), soft clashes (insufficient clearance), and query points. This report is converted into individual BCF topics, each with a camera view, component IDs, and a question or suggested clearance.

Topics are circulated: the architect moves an element, the structural engineer moves a beam, the MEP consultant reroutes a duct. As each party responds, status changes from open to in progress to resolved, and the comment thread records decisions. BIM coordination is this entire iterative loop, with BCF as the mechanism that holds distributed teams together.

What is the practical value for Slovak practices coordinating with engineers?

For a solo architect designing a single-family house alone, BCF is overkill. A quick phone call is often faster than formalizing coordination into BCF topics.

BCF becomes essential once the practice coordinates with a separate structural engineer and MEP specialist using different software. At that scale, BCF ensures a conflict message is precise, repeatable, and permanently recorded, rather than buried in email chains and screenshots. On a passive-house project with complex ductwork, underfloor heating, and a tight structural grid, unresolved coordination clashes often become thermal bridges or air leakage defects on site. A formal BCF workflow catches these problems during design when they are cheap to fix, not after construction starts.

What are the real limitations of BCF?

BCF is powerful but not a version-control system or complete project archive. First, both parties must use the same model version. If the architect adds a wall and changes component GUIDs, old BCF issues may reference components that no longer exist. Unlike code repositories, BCF has no automated merge; teams must manually coordinate model versions by declaring a coordination freeze.

Second, BCF records issues at a moment but does not preserve design history. If a clash was resolved by moving a beam, then the architect later recreates that clash elsewhere, BCF does not inherit the previous solution. For genuine design archiving, a project needs a proper version-control system in addition to BCF.

Third, BCF lives inside a Common Data Environment, whose accessibility depends entirely on platform longevity. If the server shuts down, issues become inaccessible unless explicitly exported. Ask for a final BCF export as a project deliverable.

When should a project adopt BCF?

The decision depends on team size, software diversity, and project complexity. On a small home with a coordinated team, formal BCF workflows can feel like bureaucracy. On a complex multi-storey project with consultants in different cities using different tools, BCF keeps coordination asynchronous and auditable.