IFC, IDS, and BCF solve different BIM exchange problems
buildingSMART publishes IFC model schemas, IDS requirement artifacts, and BCF collaboration formats as distinct standards families. A project should select from the governed object and workflow, then name the exact version, status, participants, and acceptance evidence.
Editorial figure by Contractor Systems Index. Source context: buildingSMART International Standards Server.
Select the standard from the governed exchange object
| Workflow object | Minimum selection evidence | Boundary to preserve |
|---|---|---|
| Model exchange | IFC version and lifecycle status, model view or profile, schema form, authoring source, recipient, and acceptance test | A readable file does not establish complete or correct project information |
| Information requirement | IDS version, requirement author, applicability, required properties and values, model population, and validation rule | A machine-check result does not establish contractual acceptance |
| Collaboration issue | BCF version, XML or API profile, linked model context, issue identity, viewpoint, owner, status, and closure authority | An exchanged issue does not change the underlying model or approve work |
| Combined workflow | Link among model version, requirement version, validation result, issue record, correction, retest, and accepted baseline | Using three standards does not create one authoritative record |
| Software support | Exact product build, import and export scope, tested artifacts, exception behavior, and retained evidence | A standards-support claim does not prove conformance or interoperability |
Choose from the object that must cross the boundary
The direct answer is to select IFC when the governed exchange object is model data, IDS when the project needs a machine-readable information-requirement artifact and check, and BCF when the governed object is a collaboration issue linked to model context. These artifacts can work together, but they are not substitute file extensions. Record the business question, project stage, sender, recipient, authoritative model or requirement, intended decision, and evidence of acceptance before selecting a standard. [1] [2] [3]
The official server makes the separation visible. IFC has its own versioned HTML, EXPRESS, XSD, and download records; IDS has versioned XSD records; BCF has versioned XML and API releases. A requirements file does not carry the complete model, an issue package does not become the corrected model, and a model exchange does not by itself state every required information check or issue disposition. [1]
Name version, status, and profile instead of saying openBIM
The server exposes final, in-development, withdrawn, and retired lifecycle labels across the listed artifacts. A project record should preserve the exact standard family, version, status at selection time, schema or API artifact, model view or agreed profile, extensions, identifiers, units, coordinate and classification assumptions, required properties, and sender and recipient obligations. The label IFC, IDS, or BCF alone is not an implementation contract. [1]
Treat software support as a testable claim. Ask each tool to import and export the exact agreed artifact, preserve stable identity and context, expose validation errors, retain rejected or unmapped information, handle revisions, and reproduce the same result across the named product builds. A successful demonstration with one file or endpoint establishes only that tested path and version.
Link the model, requirement, check, and issue without collapsing them
In a combined workflow, preserve the IFC model identity and revision, the IDS requirement set and version, the validation engine and result, the BCF issue identity and viewpoint, the responsible participant, the proposed correction, the resulting model revision, the retest, and the party authorized to accept or close. Each transition needs its own timestamp and evidence so a later export cannot silently erase the reason for a change. [1]
Test a missing required property, a property with the wrong value, an object outside the IDS applicability rule, a BCF issue linked to a superseded model element, a viewpoint the recipient cannot reproduce, a corrected model that creates a new failure, and an issue closed without retest. The workflow passes only when reviewers can reconstruct the governing requirement, observed result, communication, correction, and accepted baseline.
Keep the selector distinct from an IDS validation guide
A detailed IDS review asks how selected information requirements become checkable records and where machine validation stops. This selector answers the earlier architecture question: whether the project is exchanging model structure, expressing requirements, communicating issues, or joining all three. Preserve the separate object and authority for each layer so validation, collaboration, design, contract, and acceptance claims remain distinguishable. [1] [3]
Contractor Systems Index freshly reviewed the exact buildingSMART standards server in a normal browser on October 12, 2026. Strict retrieval returned HTTP 403, so the registry now contains a source-specific exact-page receipt and the refreshed site gate passes. The page rendered substantive IFC, IDS, and BCF records and version statuses; it does not prove project adoption, software conformance, interoperability, contractual sufficiency, or acceptance. [1]
Limitations and unknowns
- No project's exchange information requirements, contract, BIM execution plan, IFC profile or model view, IDS requirement set, BCF profile, classification, coordinate, or acceptance rule was reviewed.
- No authoring, checking, coordination, common-data-environment, import, export, XML, API, identity, viewpoint, correction, or interoperability behavior was independently tested.
- Software conformance, model completeness, requirement correctness, issue resolution, professional sufficiency, contractual acceptance, cost, schedule, safety, quality, and project outcomes remain unverified.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Contractor Systems Index will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.