| name | ifc-core-mvd |
| description | Use when choosing which Model View Definition to target for an IFC export, reading the ViewDefinition string from an IFC file header, or deciding whether a model carries enough geometry for the receiving tool to edit it. Prevents exporting the entire IFC schema instead of a scoped subset, mismatching an MVD to the exchange scenario, expecting parametric or editable geometry from a Reference View file, and hand-authoring mvdXML. Covers what an MVD is, Coordination View 2.0 (IFC2x3), Reference View and Design Transfer View (IFC4 and IFC4.3), COBie as an FM-handover subset, the geometry each MVD permits, and the FILE_DESCRIPTION ViewDefinition header string. Keywords: MVD, Model View Definition, ViewDefinition, Coordination View 2.0, Reference View, Design Transfer View, COBie, FILE_DESCRIPTION header, IFC subset, mvdXML, which MVD should I use, what view definition, my IFC file has no geometry, model is not editable after import, clash detection export, IFC export settings, reference model vs design transfer, conformance class.
|
| license | MIT |
| compatibility | Designed for Claude Code. Requires IFC IFC2x3, IFC4, IFC4.3. |
| metadata | {"author":"OpenAEC-Foundation","version":"1.0"} |
IFC Core : Model View Definitions (MVD)
The full IFC schema is intentionally huge (over 1300 entities, roughly 2500 properties,
over 750 property sets in IFC4.3). No single software exchange uses all of it. A
Model View Definition (MVD) is a standardized, formally documented subset of the
IFC schema, scoped to one exchange scenario. The MVD names exactly which entities,
attributes, property sets, and geometry types a conforming exporter must produce and a
conforming importer must read. This skill covers which MVD to target, how each MVD is
declared in the file header, and what geometry each one permits.
Quick Reference
What an MVD is, and is NOT
- An MVD IS a documented subset of the IFC schema for a specific exchange use case.
- An MVD IS the contract that makes certification and validation testable : it
scopes "correct IFC" down to a finite, checkable set of entities and rules.
- An MVD is NOT a separate file format. An MVD file is still a normal IFC file in a
standard encoding (STEP Physical File, ifcXML, ifcJSON). The MVD only restricts
which entities appear.
- An MVD is NOT a version. IFC2x3, IFC4, IFC4.3 are schema versions; MVDs are
subsets layered on top of a version.
- The machine-readable description language for MVDs is mvdXML. Authoring mvdXML is
out of scope for this package : ALWAYS treat mvdXML as a published artifact to read
about, NEVER hand-write it.
The MVD catalog (the load-bearing four)
| MVD | IFC version | Status | Purpose | Editable target |
|---|
| Coordination View 2.0 | IFC2x3 TC1 | Final | Multi-discipline design coordination, clash detection | No |
| Reference View | IFC4 ADD2 TC1 ; IFC4.3 ADD2 | Final | Reference models, one-directional distribution | No |
| Design Transfer View | IFC4 ADD2 TC1 | Draft | Hand a model to another authoring tool to edit | Yes |
| COBie (Basic FM Handover View) | IFC2x3 TC1 | Final | Facility-management handover data | n/a (data, not geometry) |
Other registered MVDs (Quantity Takeoff View, Energy Analysis View, Structural
Analysis View, Space Boundary Add-On View, IFC4Precast) exist; see
references/methods.md for the full list.
Geometry each MVD permits
| MVD | Geometry permitted | Geometry excluded |
|---|
| Coordination View 2.0 | SweptSolid, Clipping, Brep, MappedRepresentation | (IFC2x3 has no tessellation) |
| Reference View | Tessellation (triangulated/polygonal face sets), SweptSolid (extrusion and revolution), AdvancedSweptSolid limited to swept disk solids, 2D FootPrint for IfcGrid/IfcSpace/IfcSpatialZone | CSG / Boolean clipping, parametric dimension-driven geometry |
| Design Transfer View | Full swept solids, CSG, Clipping, Brep, AdvancedBrep (NURBS) | (none : editable superset of Reference View) |
| COBie | none required (non-graphic FM data) | n/a |
The MVD declaration in the file header
ALWAYS declare the MVD in the first string of FILE_DESCRIPTION, in the HEADER
section. Verified syntax (IFC Header Data Implementation Guide v1.0.2) :
FILE_DESCRIPTION(('ViewDefinition [CoordinationView]'),'2;1');
- The keyword is
ViewDefinition, followed by [, a comma-separated value list, ].
implementation_level (the second string) is always 2;1 for IFC files.- The verified IFC2x3 base keyword for design coordination is
CoordinationView;
exporters commonly suffix a version, for example CoordinationView_V2.0.
- IFC4 base keywords are
ReferenceView and DesignTransferView; files commonly carry
ReferenceView_V1.2 and DesignTransferView_V1.0.
- ALWAYS match a header by the base keyword prefix (
ReferenceView), NEVER by an
exact version suffix : the suffix convention varies by exporter.
Decision Trees
Which MVD to target
What is the exchange scenario?
|
+-- Multi-discipline coordination / clash detection on an IFC2x3 toolchain
| --> Coordination View 2.0
|
+-- Distribute a reference model (coordination, takeoff, sequencing, IFC4+)
| the receiver only needs to view and measure, NEVER edit
| --> Reference View
|
+-- Hand a model to another authoring tool so it becomes the editable basis
| --> Design Transfer View (IFC4)
|
+-- Facility-management handover (spaces, components, types, jobs, spares)
| --> COBie / Basic FM Handover View
|
+-- Scenario not covered by a registered MVD
--> agree an Exchange Requirement with the receiver before exporting;
NEVER export the full schema "to be safe".
Read the MVD from an existing file
Open the HEADER section ; read FILE_DESCRIPTION's first string.
Find the substring starting with 'ViewDefinition ['.
|
+-- contains CoordinationView --> IFC2x3 coordination model (view-only)
+-- contains ReferenceView --> IFC4/IFC4.3 reference model (view-only)
+-- contains DesignTransferView --> IFC4 transfer model (editable target)
+-- contains FMHandOverView --> FM-handover data model (COBie family)
+-- no 'ViewDefinition' string --> MVD undeclared
treat geometry coverage as UNKNOWN ;
do not assume the model is complete.
Can the receiver edit the model?
Does the receiving tool import the Design Transfer View?
|
+-- YES --> it can ALSO import Reference View datasets
| (Reference View is a true subset of Design Transfer View).
|
+-- NO, the tool imports Reference View only
--> it CANNOT import Design Transfer View datasets.
Send Reference View ; expect view-and-measure use, NOT editing.
Patterns
Pattern : Declare the MVD in the file header
ALWAYS write the ViewDefinition keyword into the first FILE_DESCRIPTION string when
producing an IFC file. A missing ViewDefinition leaves consumers unable to know which
subset they received.
ALWAYS keep implementation_level as 2;1 : IFC files use ISO 10303-21 conformance
class 1 and never the complex-entity features that would require class 2.
To declare more than one view, list them comma-separated inside one bracket, or repeat
the keyword in separate strings :
FILE_DESCRIPTION(('ViewDefinition [CoordinationView, QuantityTakeOffAddOnView]'),'2;1');
NEVER put two keyword sets in a single unseparated string : each ViewDefinition set is
one element of the description LIST OF STRING. See references/examples.md.
Pattern : Pick the MVD from the scenario, not from file size
ALWAYS choose the MVD by the exchange scenario and the receiver's capability.
NEVER choose an MVD to make the file smaller : the three coordination MVDs differ by the
level of parametric information captured, not by level of detail.
- Reference View keeps the originator's parametric "intellectual engineering property"
with the originator : the receiver gets tessellated, non-parametric geometry.
- Design Transfer View hands over editable, parametric geometry so the receiver can
continue authoring.
Pattern : Reference View geometry is tessellated and not editable
ALWAYS expect Reference View geometry to be tessellation-based (triangulated or
polygonal face sets), plus simple swept solids and swept disk solids.
NEVER expect CSG, Boolean clipping, or dimension-driven parametric geometry in a
Reference View file : the Reference View specification deliberately excludes them.
The intent is one-directional exchange : the receiver views, measures, clashes, and
sequences, then requests changes via BCF rather than by editing the file. If a workflow
needs the receiver to edit the geometry, Reference View is the wrong MVD.
See ifc-syntax-geometry-tessellation for the face-set entities and
ifc-syntax-geometry-swept-solid for the permitted swept solids.
Pattern : Design Transfer View is a superset of Reference View
The Reference View is a true subset of the Design Transfer View. The relationship is
asymmetric :
- A tool that imports the Design Transfer View MUST also correctly import Reference View
datasets.
- A tool that imports the Reference View only CANNOT import Design Transfer View
datasets.
ALWAYS confirm the receiving tool's import capability before sending a Design Transfer
View file. The Design Transfer View is still Draft status : verify the receiver
supports it rather than assuming.
Pattern : COBie carries FM data, not geometry
COBie (Construction-Operations Building Information Exchange) is an MVD subset focused on
facility-management handover data : spaces, zones, components, types, systems,
spares, resources, jobs, documents, and attributes. It captures the non-graphic data an
owner needs to populate an asset-management system.
- The IFC2x3 binding is the buildingSMART Basic FM Handover View MVD (Final). Its
header keyword is
FMHandOverView.
- COBie is exchanged as an IFC STEP file or ifcXML for large projects, and as a
spreadsheet for small projects.
ALWAYS treat COBie as a data exchange : a valid COBie deliverable needs the FM entity
set populated, NOT geometry. For the COBie export workflow and spreadsheet duality, see
ifc-impl-cobie.
Pattern : NEVER hand-author mvdXML
mvdXML is the machine-readable language used to define MVDs (concept templates, Root
Concepts, semantic and geometric constraints). It is published by buildingSMART for each
MVD.
NEVER hand-write mvdXML to "configure" an export : real exporters implement MVD support
internally and expose it as an export preset. ALWAYS select the MVD through the
exporting tool's settings, and verify the result by reading the ViewDefinition string
back from the produced file. mvdXML authoring is excluded from this package.
Reference Links
references/methods.md : the full registered-MVD catalog, the file_description
EXPRESS entity, the description-field BNF grammar, the predefined ViewDefinition
keyword list, and per-MVD geometry rules.references/examples.md : verified header strings for each MVD, reading an MVD from a
header, multi-view headers, and the Option keyword.references/anti-patterns.md : the failure modes this skill prevents, each with the
reason it fails.
Official sources
Related skills
ifc-impl-mvd-export : the workflow for producing an MVD-conformant export.ifc-impl-cobie : the COBie handover workflow and spreadsheet duality.ifc-syntax-step-physical-file : the STEP Physical File HEADER and DATA sections.ifc-core-standards-overview : the IFC versions, certification, and validation.ifc-core-version-evolution : version-by-version schema changes.
