Executive summary

The classic case for openBIM was interoperability: opening a model without depending on a vendor. That's correct, but incomplete — and it's why many organizations still treat it as a minor technical concern. The real shift is different: the IFC + IDS + BCF + bSDD stack has become a verifiable control mechanism over what gets delivered. With IDS approved as a standard in June 2024 [3], there is for the first time a reproducible way to express information requirements and automatically check whether a model meets them, with identical results in any verification software. For an owner or a general contractor, that turns a contractual requirement into something auditable instead of debatable.

The real problem and what's changing

An EIR written in Word demands "models with sufficient information for maintenance." Six months later, no one can objectively prove whether that was met. The dispute gets resolved through negotiation, not verification. That gap — unverifiable requirements — is what current openBIM closes.

Four pieces are worth separating, since they tend to get conflated:

IFC is the data schema, an open international standard under ISO 16739-1:2024 in its 4.3 version [1][2], which in this edition extended coverage to infrastructure: bridges, roads, railways, waterways, and port facilities [2].
IDS defines, in a machine-readable form, what information a model must contain; it's tightly bound to the IFC schema and allows unambiguous interpretation with identical results across every verification tool [3]. Its scope is alphanumeric — properties, quantities, classifications, materials, and relationships — not geometric [3].
BCF carries the issues: topics referenced to specific elements via their IFC GUIDs, with a viewpoint, comments, status, and an assigned owner, available both as a file format and via a REST API [4].
bSDD distributes the definitions — classifications, properties, values, units — that IFC and IDS can reference [5].

The difference from the openBIM discourse of a decade ago is that the point is no longer "being able to open the file," but being able to prove compliance.

Why now

First, because the normative scaffolding is complete: IFC 4.3 was ratified as an ISO standard in 2024 [1][2] and IDS reached official standard status in June 2024 [3]. Before that, requirements were shared in machine-unreadable formats like spreadsheets or PDFs.

Second, because vendor-independent verification infrastructure now exists. The IFC Validation Service issues a conformity ruling on a file against the standard — STEP syntax, schema, and normative rules — and serves as the basis for downstream checks, though on its own it doesn't verify a specific project's requirements [6]. Aggregated metrics also generate public scorecards on each tool's real-world behavior, built only from files uploaded by users, not by vendors [7].

Third, contractual pressure: once a client can verify automatically, the requirement becomes enforceable.

How it works and where it applies

The control cycle has a stable shape: the client defines information requirements under the ISO 19650 framework [8] → those requirements are expressed as one or more IDS files referencing bSDD classifications and properties [3][5] → the project team uses them during production, not just at the end → the model is exported to IFC and first passes conformity validation against the standard [6], then verification against the IDS → non-compliances are communicated as BCF topics assigned to specific owners [4] → the corrected model is re-verified and the result is logged.

Concrete applications:

Milestone deliverable verification: replacing manual review with a reproducible conformity report.
Subcontractor qualification: requiring their models to pass the project's IDS turns a commercial promise into objective proof.
Documented MEP coordination: issues travel as BCF referencing GUIDs, so the history of who found what and when survives a software change [4].
Handover to operations: the owner defines in IDS the information they need for maintenance and verifies it before acceptance, instead of discovering gaps a year later.
Tool selection: scorecards allow evaluating real IFC support with usage data, not marketing material [7].

Business and team impact

For the owner, the effect is a risk shift: what used to be accepted on trust now gets checked. For the contractor and the BIM consultant, the effect is double-edged: the bar rises, but whoever knows how to operate the mechanism can demonstrate delivery quality instead of just asserting it.

On teams, verification stops being a closeout task and becomes continuous control during production, and the BIM Manager starts drafting and maintaining IDS specifications — a different skill from configuring templates. Platform independence shifts from an ideological argument to a negotiating clause: if deliverables are verifiable in an open format, switching software stops being a traumatic event.

Barriers, risks, and maturity level

The first barrier is version ambiguity: IFC 4.3 (ISO 16739-1:2024) coexists with IFC 4 ADD2 TC1 and IFC 2x3, both still widely used [1]. A contract that demands "IFC4" without specifying the revision invites conflict, since versions differ in entities, property sets, and serialization rules. The second is IDS scope, which covers alphanumeric information and not geometric aspects [3]: relying on it to verify constructibility or tolerances would be a methodological error. The third is uneven software implementation, which is why the validation service and scorecards exist [6][7]. Add to that organizational resistance — openBIM forces agreements many companies prefer to keep implicit — and the upfront cost of defining requirements previously written in vague language.

Maturity: consolidated in certain markets, growing elsewhere. The evidence: a complete normative base ratified by ISO [2], public validation infrastructure [6][7], and markets with systematic contractual enforcement — but IDS adoption is still recent, since the standard is barely two years old.

How to prepare

Specify the schema version in the contract (e.g., IFC 4.3 per ISO 16739-1:2024), never "IFC" alone [1][2].
Turn the EIR into at least one working IDS file, even if it only covers a critical subset of elements; a partial, actually-used IDS is worth more than an exhaustive, theoretical one [3].
Reference bSDD properties and classifications instead of defining undocumented proprietary naming [5].
Integrate validation into the production cycle, starting with the IFC Validation Service as a baseline check and adding IDS verification afterward [6].
Standardize BCF for issues, with defined statuses and owners, so the coordination history stays independent of the platform [4].

Future outlook and conclusion

The likely evolution is that machine-verifiable requirements become standard contractual practice on public projects and large private clients, the same way IFC delivery went from exception to standard clause. It's reasonable to expect verification to combine with AI assistance for drafting and interpreting specifications, while the deterministic mechanism remains the final authority. The IFC5 timeline, still in alpha [9], remains speculative.

The conclusion reverses the usual framing: openBIM isn't a concession to the community or a technical preference, it's the only available mechanism for an information requirement to be enforceable without depending on whoever's verifying it. Whoever masters IDS, BCF, and IFC validation isn't being a purist — they control the definition of "delivered and compliant." In a sector where much of the contractual conflict stems from unverifiable expectations, that control has direct economic value.

Frequently asked questions

Does openBIM mean giving up Revit or other native authoring software? No. It means deliverables and their verification rely on open formats. The authoring tool remains each team's own decision.

Does IDS replace the BIM execution plan? No. The BEP still defines processes, roles, and responsibilities under the ISO 19650 framework [8]; IDS expresses the part of the information requirements that can be checked automatically [3].

Does a model valid in the IFC Validation Service meet the contract? Not necessarily. That service verifies conformance with the IFC standard and serves as a basis for downstream checks, not as verification of a specific project's requirements [6].

Sources and references

[1] buildingSMART International. "Industry Foundation Classes (IFC)" — official versions and IFC 4.3 / IFC5 status.

[2] ISO. ISO 16739-1:2024 — Industry Foundation Classes (IFC), Part 1: Data schema (edition adding infrastructure coverage).

[3] buildingSMART International. "Information Delivery Specification (IDS)," official standard since June 1, 2024.

[4] buildingSMART International. "BIM Collaboration Format (BCF)" and the BCF-API specification (OpenCDE family).

[5] buildingSMART International. "buildingSMART Data Dictionary (bSDD)."

[6] buildingSMART Technical. "IFC Validation Service" — conformance criteria and scope.

[7] buildingSMART International. "Software Certification Program" — scorecards generated from user-uploaded files.

[8] ISO. ISO 19650-1:2018 and ISO 19650-2:2018 — Information management using BIM.

[9] buildingSMART International. IFC5-development repository (alpha status).