BIM-CVP must not invent a BIM standard. BIM-CVP should implement the buildingSMART standards faithfully and add only the missing signed-record and value-evidence layer around them.
Contents
What buildingSMART owns
buildingSMART International is the organisation behind the core openBIM standards and services. Its standards page groups the ecosystem around IFC, IDS, BCF, bSDD, the IFC Validation Service, openCDE and Use Case Management. The important point for us is responsibility: buildingSMART defines interoperable exchange semantics; BIM-CVP defines how a project records, signs, discovers and audits those exchanges.
| Question | buildingSMART answer | BIM-CVP answer |
|---|---|---|
| What is the model? | IFC schema and documentation. | Hash and reference the IFC file; never mutate it. |
| What must be delivered? | IDS, LOIN and exchange requirements. | Sign requirement specs and validation results. |
| How are issues exchanged? | BCF XML and BCF API. | Map topics, comments, viewpoints and audits to events. |
| How do terms stay stable? | bSDD URIs, classifications, dictionaries. | Store URI references in tags/content, not local synonyms. |
| How do CDEs interoperate? | openCDE APIs: Foundation, BCF, Documents, Dictionary. | Build adapters, not a closed platform. |
Product framing
This is the clean market position: buildingSMART International defines the openBIM objects and exchange semantics; BIM-CVP defines the portable record layer around those objects. The product should therefore be explained as implementation infrastructure for buildingSMART workflows, not as a regional BIM profile and not as a competing CDE.
| buildingSMART layer | What stays standard | What CVP adds |
|---|---|---|
| IFC | The model file, schema version, GlobalIds and property data. | Signed file references, hashes, provenance and approval state. |
| BCF | Topics, comments, viewpoints, snapshots and project value lists. | Signed event graph, authorship, relay discovery and audit events. |
| IDS | Machine-checkable delivery requirements for IFC data. | Versioned requirement records and signed validation results. |
| bSDD | Stable concepts, properties, classifications and multilingual terms. | URI references inside events instead of local label forks. |
| openCDE | Foundation, BCF, Documents and Dictionary API boundaries. | Adapters that sync signed records with existing CDE products. |
| UCM / IDM | Use cases, process steps and information exchange needs. | Traceable reasons for why an event exists and who needs it. |
Standards map
| Standard / service | Official role | Our event family | Do not confuse with |
|---|---|---|---|
| IFC | Digital description of built assets, ISO 16739. | 1063, 30904, ifc tags. | Native authoring file. |
| BCF | Issue management and coordination via file exchange or web service. | 30900, 30901, 1170, 1171. | General chat or task management. |
| IDS | Computer-interpretable requirements for checking IFC data. | 30810, 1180. | PDF requirement list only humans can read. |
| bSDD | Terms, classifications and properties with stable identifiers. | classification-uri, bsdd-uri tags. | Project-local spreadsheet vocabulary. |
| openCDE | API portfolio for CDE interoperability. | Adapter targets for export/import. | One central storage product. |
| Validation Service | IFC validation and implementation feedback. | Validation report files and 1180 events. | Project approval. |
| UCM | Use Case Management for openBIM workflows. | Use-case references in project setup. | A runtime workflow engine. |
International openBIM workflow
buildingSMART describes openBIM workflow as flexible rather than one universal process. That is exactly why the BIM-CVP workflow page is explicit: it fixes one implementable profile while staying exportable to normal IFC, IDS and BCF artifacts.
Define requirements -> IDS / LOIN / use case -> signed requirement events Author information -> native tools produce IFC / documents -> files get hash and metadata events Coordinate -> BCF topics, comments, viewpoints -> signed BCF event graph Validate -> IDS checking and IFC validation -> signed validation results Approve / publish -> ISO 19650 state transition -> signed approval event
BIM-CVP event policy
For implementation, this page sets the boundary: every event must either carry a buildingSMART object, reference a buildingSMART object, or record the workflow decision around such an object.
| Rule | Why | Example |
|---|---|---|
| Use official version names. | Compatibility depends on exact schema. | IFC4X3_ADD2, BCF 3.0, IDS 1.0. |
| Keep original GUIDs. | Round-trip depends on BCF/IFC identity. | Topic GUID in d and bcf-guid. |
| Link files by hash. | Storage location can change; bytes must not. | kind:1063 with x SHA-256. |
| Prefer URI references for vocabulary. | Local terms drift. | bSDD or national classification URI. |
| Export always remains possible. | OpenBIM is the escape hatch. | Events to BCFZIP, IFC references, IDS reports. |
Implementation impact
Module code
Forms should ask for standard fields first: status, type, priority, IFC GUID, viewpoint, file reference.
Validation
Client-side schema checks should reject events that cannot round-trip to the matching standard.
Wiki
Every explanation page should end with implementation mapping and direct source links.
Adapters
Adapters target buildingSMART artifacts and APIs, not proprietary data models first.
Read on
- Pinned standards — current implementation baseline
- Workflow model — concrete process profile
- BCF to Nostr events — detailed mapping
- BIM and openBIM — plain-language primer