The OpenBIM Pledge

The OpenBIM pledge is a no-nonsense, step-by-step practical strategy to raise adoption of international, open data standards based BIM. If all companies agree to incrementally implement these principles, we can move towards standardised data across the world, and a strong foundation to build all digital processes, workflows, and future visions of our built environment.

This pledge is inspired by the pledge signed by browser vendors who stopped fighting and instead worked together to implement standards-compliant web technologies. This is a technical document, aimed at a technical audience of digital engineers. Signing this document is entirely voluntary. That said, you'd assume anybody who is a buildingSMART member is probably at least tier 1.

This is a draft. I did a braindump at 1am without holding back and haven't digested anything. Please braindump your own ideas by editing this page and we can collectively polish this.

The following tiers are aimed at both those requesting and providing BIM.

Tier 0

This is basically the participation trophy. It's better than nothing.

• I solemnly swear to require "IFC" (as vague as that is) as part of a deliverable. I will actually check that I've received something, and at least open it to make sure it contains information relevant to the project.

Signatories: your company here?

Tier 1

• I will require and check for a specific IFC schema version (IFC2X3, IFC4, IFC4X3), acknowledging practical differences between IFC versions.
• If I require properties attached to objects, I will specify and check for a property name, property set name and IFC data type (e.g. IfcLabel, IfcIdentifier, IfcPositiveLengthMeasure) of the data.
• I will not penalise any stakeholder from using any software they want, giving them freedom of using the best tool for the job, so long as OpenBIM deliverables are provided.
• If an IFC is not delivered, I will withold payment if it is within my power to do so.

Signatories: your company here?

Tier 2

• All IfcProduct and IfcTypeProducts must be assigned to the correct IFC class. This means that regardless of people's favourite classification flavour of the day, there is a fallback "broad" classification that anybody can use for any process. This does not stop you from using additional classifications on top of IFC's built-in classes. This is also the first step in order to use any sort of standardised property or quantity.
• If I require properties or quantities that already exist as part of a buildingSMART standardised template (i.e. those prefixed with Pset or Qto), I will use that instead of reinventing my own.
• I will specify the applicable IFC class for all properties that I require. This ensures people understand which objects need which properties, and it can be automatically checked.
• I will provide an IDS for simple property requirements so that audits are standardised and there are no ambiguities or nasty surprises.
• I will validate IFCs and report validation bugs to software vendors. This provides a reliable technical foundation that we can build systems upon.

Signatories: your company here?

Tier 3

• If I require anything to be georeferenced, I will require at least IFC4, and correctly implement IfcProjectedCRS and IfcMapConversion following the best practices of the buildingSMART user guide to georeferencing for vertical and horizontal projects. This is the first step to federating across models, GIS environments, and infra projects of the future.
• If anything is named in documentation (drawing, schedule, specification, etc), that name must be stored in the Name attribute (not a property!) of the relevant IfcTypeProduct and/or IfcProduct and/or IfcSpatialElement. This ensures that documentation at least correlates to BIM data (otherwise everything else becomes almost meaningless).
• If any name is not self-explanatory (e.g. a coded naming or numbering system), then a Description attribute (not a property!) must be provided of all IfcTypeProduct and/or IfcProduct and/or IfcSpatialElement (LongName instead of Description). Descriptions should be sufficient so that those reading a schedule of my objects can understand what the object is without visually looking at a 3D model. This provides a strong foundation to any non-graphical scheduling or query.
• If I require an external classification system, it must be stored as a classification reference in an IfcClassification, not as a property. This means that filtering of classifiations can actually benefit from understanding the hierarchical nature of classifications.
• All physical products must additionally have a predefined type assigned. If any user defined values are used, it must be documented and audited. The rules of inheritance and override of predefined types must be followed. This leads to a more granular option of an international classification.
• I will use object types and occurrences effectively using their ability to inherit properties and classifications. I will not explicitly require properties on every single occurrence. This prevents obscene duplication of data where data can be intelligently inherited.
• I will specify the "Category" attribute for all IfcMaterials, using only one of the keywords listed in the IFC documentation. This allows you to identify basic things consistently like "concrete objects" or "steel objects" at a high level.
• If I want quantity data, it must be stored as a quantity set, not as a property. This allows us to separate calculable or geometry-derived data from semantic data so we can recalculate and check quantities and later connect parametrically to costs.

Signatories: your company here?

Tier 4

• I will audit and guarantee that the spatial hierarchy reflects all documentation. This ensures that all documented rooms, storeys, spaces, buildings, infrastructure corridors, etc are also available for analysis in the model. Spatial breakdowns have many usecases.
• I will audit and guarantee that all products are contained in the correct spatial element in the spatial hierarchy. This will ensure that any spatial division or filtering can be reliably performed in the model, critical for any sort of quantification or further breakdown.
• If I require information about the system that a product is part of, I will use IfcSystem classes appropriately, instead of storing this information in a property set. This is the first step to semantically storing useful system connectivity.
• If I have my own invented classifications, properties, or materials, I will submit and maintain a register of the in the bSDD. This allows tools to integrate with my data schemas in a standardised manner.
• If I require COBie 2.4 or COBie 3.0, it must be extracted from the IFC in compliance with the COBie mapping table and COBie IFC class lists, not delivered as a separate spreadsheet. This ensures that IFCs are consistent with facility management data.
• I will not request spreadsheets of information where all that information is stored in the IFC. Instead, I will audit data in IFC directly. This prevents duplication of data, ensures a single source of truth, and does not downgrade smart semantic data to dumb tabular form. You can of course later on generate tabular datasets, but it must not be a primary deliverable.
• I will specify all geometric LOD and clash detection priorities / rules in terms of data in IFC (e.g. IFC classes and predefined types, or IFC classifications) similar to the filter facets available in IDS. This means that geometric reliability and tolerance can be analysed in a standardised manner.
• I will not require any properties that can be derived from counting classes (e.g. total building storeys). This removes duplication of data, possibility of mistakes.
• I will not require any properties on an occurrence (e.g. room number) that can instead by stored on the relating container (e.g. space, storey, etc) or relating system (e.g. distribution system, circuit). This removes duplication of data and is a good first step away from dumb properties and towards intelligent, related semantic objects.

Tier 5

• I will provide any structural analytical models in IFC, using IfcStructuralAnalysisModel. The quality may vary at this tier.
• If I require a cost breakdown structure, I will provide it in IFC, using IfcCostItem and IfcCostValue. The quality may vary at this tier.
• If I require a work breakdown structure, I will provide it in IFC, using IfcWorkPlan, IfcWorkSchedule, IfcWorkCalendar, and IfcTask. The quality may vary at this tier.
• All documentation forming a deliverable will be provided in IFC using IfcDocumentInformation.
• All standardised steel profiles will come from an IFC library managed by my local buildingSMART chapter ideally including critical structural, quantification, and environmental data. This library must at a minimum include standardised names. This ensures highly standardised primary building components can be identified explicitly, and encourages sharing of industry standards.
• I will not require any property that can be derived through traversing port connectivity of system elements. This ensures that systems are not just geometry, but start to represent connected topologies.

... more to come.

Signatories: your company here?

Tier 6

• Smart building schemas such as Brickschema must be derived from IFC. This is the first step towards connecting to smart building sensors, events, and procedures.

Signatories: your company here?

... more to come.