BIM Object specification

Building Information Modelling produces detailed digital representations of a structure, but a standard BIM model does not by itself prevent code violations — a model can be geometrically complete and still fail a jurisdiction's requirements, discovered only when a compliance check runs after the fact. A BIM Object is the platform's term for a building-element specification designed to carry its applicable code and performance requirements with it from the moment it's placed, so a violation is caught in the design itself rather than at a later inspection.

Why it matters: the substrate exists to make a class of defect structurally impossible to place, not merely easier to catch — the difference between a specification unit and a checklist.

What distinguishes a BIM Object

A BIM Object differs from the building blocks it might be mistaken for. It is not a raw IFC entity type (which defines a data shape but carries no jurisdiction-specific requirements). It is not a proprietary, vendor-locked model-authoring format. It is not after-the-fact facility-management data captured once a model is complete. It combines three things at once: what the element is, what regulatory requirements it must satisfy in its jurisdiction, and what performance requirements it must meet for its climate zone — bundled into one reusable specification unit rather than checked separately after design.

Primitive categories — the substrate

Every BIM Object belongs to one of a small, fixed set of primitive categories — spatial elements such as sites and storeys, physical elements such as walls and doors, materials, assemblies, building systems, performance thresholds, climate-zone requirements, and identity codes. Grouping objects this way means a category tells a practitioner what kind of thing an object describes before they open its full specification.

Each category anchors to the same open standards already used across the AEC industry: the IFC entity hierarchy for what an element is, Uniclass 2015 for how it is classified, and buildingSMART's Data Dictionary (bSDD) for a stable, tool-independent definition.

Why it matters: anchoring to open standards rather than a proprietary schema means an object's meaning does not depend on any one BIM authoring tool remaining in business — the specification stays legible and verifiable however long the building stands, and however many software vendors come and go over its life.

Three composition layers

A BIM Object carries three layers of information at once: Specification, Regulation, and Climate Zone. None of the three is a choice a designer makes at design time. A building element has a fixed type, sits in a fixed jurisdiction, and performs in a fixed climate, so the object reflects all three as facts about its physical context rather than as user preferences.

Layer	What it carries
Specification	The object's permanent identity — what kind of element it is, independent of where it is built
Regulation	The jurisdiction-specific legal requirements that apply where the building actually sits
Climate Zone	The performance requirements that follow from the building's physical climate, sourced from the applicable energy code

Regulation and Climate Zone are each authored as a growing table of every registered requirement rather than a single value, because a jurisdiction or a climate zone is a fact about the site, not a setting a user selects. Regulatory requirements vary by jurisdiction and change as codes are updated; climate performance requirements vary by zone and change as energy codes are revised. Keeping these as separate layers, rather than folding them into a single number, means each concern can be tracked, sourced, and updated independently without disturbing the other two.

Why it matters — the composition rule: where a regulatory requirement and a climate-zone requirement both constrain the same property, the stricter of the two governs. Both layers express performance minimums, so the binding requirement is always whichever minimum is higher — a straightforward most-restrictive-wins rule, not a negotiated tradeoff.

Where the specification lives

The full field-level schema, jurisdiction overlay structure, delivery format, and current implementation status behind this substrate are maintained directly at bim.woodfinegroup.com.

See also

• Building Design System — the coordination layer this substrate is one of two layers of
• AEC interface conventions — the shared interface vocabulary a BIM-capable surface exposes this substrate through
• Asset-anchored BIM vault — the archive that stores each BIM Object as a hash-addressed object
• Flat-file BIM leapfrog — the architectural constraints the whole BIM substrate is built on