# Ifc Core Mvd

> 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, c

- Skill: `impertio-studio/ifc-core-mvd` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add impertio-studio/ifc-core-mvd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/impertio-studio/ifc-core-mvd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: MIT
- Author: Impertio-Studio (https://skillmd.com/u/impertio-studio)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/impertio-studio/ifc-core-mvd

---


# 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

- MVD database : https://technical.buildingsmart.org/standards/ifc/mvd/mvd-database/
- IFC4 Reference View MVD : https://standards.buildingsmart.org/MVD/RELEASE/IFC4/ADD2_TC1/RV1_2/HTML/schema/views/reference-view/index.htm
- IFC Header Data Implementation Guide v1.0.2 : https://standards.buildingsmart.org/documents/Implementation/ImplementationGuide_IFCHeaderData_Version_1.0.2.pdf
- IFC schema specifications : https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/

### 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.