openBIM field guide

IFC layers

IFC is organised in layers so generic geometry and units do not have to be redefined for every wall, pipe or bridge segment. The Resource layer holds geometry, dates, measures and materials. The Core layer defines identity, ownership, products, processes and controls. Interoperability adds shared building concepts such as walls, spaces and systems. Domain layers add discipline-specific classes.

Event mapping: the layer usually stays implicit. We record the schema version, entity type and stable GlobalId; consumers can derive the layer from the IFC schema.

Core IFC entities

Property and quantity sets

Property sets carry alphanumeric information. Standard sets use names like Pset_WallCommon; quantities use names like Qto_WallBaseQuantities. Custom sets are valid, but they need stable naming and documentation or they become tool-specific noise.

BIM-CVP events should never flatten properties into arbitrary text. Reference the IFC file, the element GUID, the property set name, the property name and, where possible, a bSDD URI.

MVDs

A Model View Definition is a constrained use of IFC for a specific exchange. The pinned implementation profile is IFC 4.3.2.0 with Reference View 1.2 where a lightweight, coordination-safe model is enough. Legacy projects still need IFC2x3 Coordination View support on the read path.

Event mapping: record the MVD as a tag on the IFC file reference when it is known, for example ["mvd", "Reference View 1.2"].

BCF-XML

BCF-XML is the portable file shape of BCF: a .bcfzip with topic folders. Each folder contains markup.bcf, optional viewpoint files and snapshots. It is good for exchange and archiving, but weak for live concurrent editing.

Event mapping: a BCF-XML import becomes a signed topic event, viewpoint events, comment events and file-reference events for snapshots.

BCF-API

BCF-API exposes projects, topics, comments, viewpoints and authorizations over HTTP. Version 3.0 is the target; 2.1 remains important because many tools still implement it. The useful idea for BIM-CVP is per-entity authorization: a user may read a topic but not close it.

Event mapping: the API resource becomes a signed event, and permission decisions become project membership, role and authorization tags.

openCDE initiative

openCDE is buildingSMART's API family for vendor-neutral CDE integration. Foundation defines discovery, auth, errors and common conventions. Documents API handles document upload, download and metadata. BCF-API connects issue workflows.

BIM-CVP should treat openCDE as an adapter boundary: signed events are the internal record, openCDE is how classical platforms are pushed or mirrored.

LOIN

LOIN is Level of Information Need, standardised as EN 17412-1. It defines the required geometry, alphanumeric information and documentation for a purpose, actor and project phase. It prevents the common failure mode "more detail" by asking "what information is needed for this decision".

Event mapping: use kind:30811 for LOIN definitions and link them to IDS specifications and project phases.

PIR / EIR / AIR / OIR

IDM

IDM is Information Delivery Manual, standardised as ISO 29481. It describes who delivers which information at which process step. IDS checks data; IDM describes the process context around that data.

Event mapping: IDM steps become process references on EIR, IDS, BCF and approval events, not a competing data schema.

WIP / Shared / Published / Archive

Event mapping: use a cde-state tag and separate approval events. Writing a file and approving it are different powers.

BIM roles

ISO 19650 separates appointing party, lead appointed party, appointed parties and task teams. Local markets add titles such as BIM manager, BIM coordinator, information manager and CDE manager. Do not encode those as one flat role list.

Event mapping: membership events should carry both discipline and authority: for example MEP + reviewer, architect + approver, client + appointing-party.

RBAC + ABAC

RBAC answers "what role does this key have". ABAC answers "is this action allowed on this object in this state". BIM needs both: a coordinator role is not enough to publish a WIP file, and a reviewer may comment on one topic but not close it.

Event mapping: roles live on project membership events; attributes live on the target object: discipline, phase, state, package, topic status and visibility.

bSDD

bSDD is the buildingSMART Data Dictionary. It provides multilingual identifiers for classes, properties, materials and classification concepts. It is not a file format; it is a reference service for stable meaning.

Event mapping: add bSDD URIs to properties, PDTs, IDS requirements and material records instead of translating labels by hand.

bSDD URIs

A URI is useful because it remains stable across languages and display names. "Fire rating", "Brandschutzklasse" and an Italian label can point to the same concept. Store the URI, display the local label.

["bsdd", "https://identifier.buildingsmart.org/uri/..."]

Classification systems

Classification systems serve different markets. Uniclass is common in the UK, OmniClass in North America, eBKP-H in Switzerland, ETIM in product and MEP contexts, and regional price-book codes are common in public procurement.

Event mapping: record both the system and the code, for example ["classification", "ETIM", "EC011023"].

buildingSMART International

buildingSMART International is the upstream source for the openBIM standard family. BIM-CVP treats it as the normative base: IFC defines model data, BCF defines issue coordination, IDS defines machine-checkable requirements, bSDD defines stable terminology, and openCDE defines API patterns for CDE interoperability.

The implementation rule is simple: do not fork the standard. Store original IFC, BCF, IDS and document payloads as files with hashes, then publish signed Nostr events that point to those payloads and add workflow state, approval and audit metadata.

Detailed source map: buildingSMART International.

Regional profiles

Regional guidance is useful, but it is not the product frame. The technical core stays buildingSMART International plus ISO 19650. Country-specific material should be implemented as profile metadata: role labels, naming conventions, procurement references, accepted classification systems and client-specific exchange gates.

That keeps the event model portable while still allowing a Swiss, German, Austrian, Italian or UK project to feel native at the contract and user-interface layer.

Switzerland

Switzerland is a useful example profile: KBOB-style appendices, BIM Abwicklungsmodell, LOIN material, AIM guidance and BIM2FM data fields. It gives enough structure for a real adapter without locking the technical core to one country.

Swiss projects are useful for an early BIM-CVP profile because the market already connects public-client guidance, ISO 19650 language, national glossary work and operations handover. In event terms this means: project setup must carry the applicable KBOB/BAP references, issue events must stay BCF-native, and handover events must be traceable to AIM/BIM2FM fields instead of generic "model delivered" statements.

Detailed source map: buildingSMART Switzerland.

Germany

Germany maps ISO 19650 into AIA, BAP, DIN and VDI practice. For BIM-CVP the important part is the procurement language: requirements must be clear enough to become IDS and LOIN, not only PDF prose.

Austria

Austria's ÖNORM A 6241 family gives a strong normative BIM frame. For practical event mapping, keep the same technical core and add Austrian naming, role and exchange-package conventions as profile tags.

Italy

Italy adds UNI 11337, ACDat language, the Capitolato Informativo and CAM Edilizia 2025. CAM is strategically important because it turns maintenance, deconstruction, LCA and LCC evidence into public-procurement requirements.

AIM

AIM is the Asset Information Model: the information set that remains useful after handover. It is not the same as the design model. It contains the verified asset records required for operation, maintenance, compliance and renovation.

BIM2FM

BIM2FM is the handover bridge from planning into facility management. The Swiss data-field catalogue is a practical starting point: it names the fields FM teams actually need instead of asking for "the full BIM model".

Building logbook

A building logbook is the long-lived record of a building: base data, models, products, maintenance, energy information, renovations and proof documents. EPBD recast makes this direction politically unavoidable in Europe.

Event mapping: generate the logbook from signed source events; every statement should point back to the model, document, approval or diary entry it came from.

Digital Product Passport

The Digital Product Passport under ESPR is the product-side equivalent of building traceability. Construction products will need material, origin, maintenance, reuse and compliance data. BIM-CVP should reference product passports, not duplicate them.

Tag mapping

BCF on Nostr

BCF maps cleanly because it is already event-like: a topic has a current state, comments are append-only, viewpoints reference files and IFC GUIDs, and status changes need an audit trail. Nostr supplies signatures and ordering without a single CDE owning the conversation.

kind:30900  BCF topic
kind:30901  BCF viewpoint (immutable by profile)
kind:1170   BCF comment
kind:1171   BCF audit event