# Ifc Impl Mvd Export

> Use when exporting an IFC file that must conform to a Model View Definition (MVD): choosing between Coordination View 2.0, Reference View, and Design Transfer View, declaring the matching ViewDefinition string in FILE_DESCRIPTION, and restricting the geometry to the representation types the chosen view permits. Prevents the non-conformant export that declares ReferenceView_V1.2 but still emits CSG or Boolean-clipping geometry, the file that names an MVD whose IFC version does not match FILE_SCHEMA, and the export that fails buildingSMART certification because the ViewDefinition contract is broken. Covers what an MVD constrains, the geometry matrix per view, the ViewDefinition keyword syntax, the Reference-versus-Design-Transfer subset relationship, and the software certification and Validation Service context. Keywords: MVD export, Model View Definition, ViewDefinition, FILE_DESCRIPTION, Coordination View 2.0, Reference View, Design Transfer View, ReferenceView_V1.2, CoordinationView_V2.0, DesignTransferView,

- Skill: `impertio-studio/ifc-impl-mvd-export` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add impertio-studio/ifc-impl-mvd-export`
- Raw SKILL.md: https://api.skillmd.com/api/skills/impertio-studio/ifc-impl-mvd-export/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-impl-mvd-export

---


# Exporting an IFC File to a Model View Definition

The full IFC schema has over 1300 entities; no single exchange uses all
of it. A Model View Definition (MVD) is a standardized subset of the
schema scoped to one exchange scenario. It fixes which entities,
attributes, property sets, and geometry representation types a
conforming exporter is allowed to produce. Exporting to an MVD means two
things ALWAYS done together: declaring the MVD in the file header, and
keeping the actual content inside the subset that MVD allows.

Verified against the buildingSMART IFC4 Reference View specification, the
buildingSMART MVD database, the IFC Header Data Implementation Guide
v1.0.2, and the IFC4.3, IFC4 ADD2 TC1, and IFC2x3 TC1 specifications. See
`references/methods.md` for the MVD registry and geometry matrix,
`references/examples.md` for header strings and a conformance checklist,
and `references/anti-patterns.md` for the export mistakes that break MVD
conformance.

## Quick Reference

### The three main MVDs

| MVD | IFC version | ViewDefinition string | Purpose |
|-----|-------------|-----------------------|---------|
| Coordination View 2.0 | IFC2x3 TC1 | `CoordinationView_V2.0` | clash detection, model federation |
| Reference View | IFC4 ADD2 TC1 | `ReferenceView_V1.2` | one-directional reference models |
| Design Transfer View | IFC4 ADD2 TC1 | `DesignTransferView_V1.1` | editable model transfer (Draft) |

Reference View also has a Final release for IFC4.3 ADD2; its geometry
rules mirror the IFC4 Reference View. Declare the ViewDefinition string
published with that IFC4.3 release.

### What an MVD constrains

An MVD is a contract. Declaring it ALWAYS commits the file to:

1. The entity and attribute subset of the named view.
2. The property sets the view requires.
3. The geometry representation types the view permits.
4. An IFC version: the MVD and `FILE_SCHEMA` MUST agree.

NEVER declare an MVD the content does not actually satisfy: a reader
relies on the declared view to decide what it must implement.

### Geometry permitted per MVD

| Representation | Coordination View 2.0 | Reference View | Design Transfer View |
|----------------|----------------------|----------------|----------------------|
| `SweptSolid` (extrusion, revolution) | yes | yes | yes |
| `AdvancedSweptSolid` | n/a (IFC2x3) | swept disk only | yes |
| `Tessellation` | n/a (IFC2x3) | yes | yes |
| `Brep` | yes | no | yes |
| `Clipping` (Boolean DIFFERENCE) | yes | NO | yes |
| `CSG` (Boolean tree) | yes | NO | yes |
| `MappedRepresentation` | yes | yes | yes |
| `FootPrint` | yes | yes (Grid, Space, SpatialZone) | yes |
| dimension-driven parametric | n/a | NO | yes |

The Reference View deliberately EXCLUDES CSG, Boolean clipping, and
parametric dimension-driven geometry so the originator keeps the
editable parametric model. IFC2x3 has no tessellation entities, so
Coordination View 2.0 never uses `Tessellation`.

### The Reference / Design Transfer subset rule

The Reference View is a true SUBSET of the Design Transfer View. A reader
that imports the Design Transfer View can ALWAYS also import Reference
View data; the reverse is NOT true. The views differ by the level of
parametric information captured, not by level of detail.

## Decision Trees

### Which MVD to export

```
What is the exchange scenario?
├── Clash detection / federation in an IFC2x3 toolchain
│     -> Coordination View 2.0  (FILE_SCHEMA = IFC2X3)
├── Distribute a reference model for coordination, takeoff, viewing,
│   where the receiver only reads and does not edit (IFC4)
│     -> Reference View  (FILE_SCHEMA = IFC4)
│        Geometry MUST be tessellation, simple swept solids, or swept
│        disk solids. NEVER emit CSG or Boolean clipping.
├── Hand a model to another authoring tool that will edit it (IFC4)
│     -> Design Transfer View  (FILE_SCHEMA = IFC4)
│        Full geometry, including CSG and parametric, is allowed.
├── Infrastructure model (bridge, road, rail, alignment)
│     -> IFC4.3 Reference View  (FILE_SCHEMA = IFC4X3)
└── Facility-management handover data, not geometry
      -> COBie / Basic FM Handover ; see ifc-impl-cobie.
```

### Reference View geometry: substitute, never emit

```
Does the model contain Boolean / CSG geometry (a wall with an opening
cut by IfcBooleanClippingResult, a CSG solid)?
├── YES, and the target is the Reference View
│     ALWAYS bake the result before export:
│       - evaluate the Boolean and emit the result as Tessellation, OR
│       - emit it as a plain SweptSolid if the shape allows.
│     NEVER write the IfcBooleanClippingResult itself.
└── YES, and the target is the Design Transfer View
      Emit the Boolean geometry as-is: the view permits it.
```

## Patterns

### Pattern 1: declare the ViewDefinition in FILE_DESCRIPTION

The `FILE_DESCRIPTION` first argument carries the ViewDefinition:

```
FILE_DESCRIPTION(('ViewDefinition [ReferenceView_V1.2]'),'2;1');
```

The keyword sits inside `ViewDefinition [ ... ]`. Multiple view keywords
are comma-separated inside one string. `implementation_level` is ALWAYS
`'2;1'`. ALWAYS write the keyword that matches the MVD column in the
table above, exactly.

### Pattern 2: pair the MVD with FILE_SCHEMA

```
Coordination View 2.0  -> FILE_SCHEMA(('IFC2X3'));
Reference View         -> FILE_SCHEMA(('IFC4'));
Design Transfer View   -> FILE_SCHEMA(('IFC4'));
IFC4.3 Reference View  -> FILE_SCHEMA(('IFC4X3'));
```

The MVD names an IFC version. `FILE_SCHEMA` MUST name the same version.
NEVER declare `CoordinationView_V2.0` in a file whose `FILE_SCHEMA` is
`IFC4`: Coordination View 2.0 is defined only for IFC2x3.

### Pattern 3: a Reference View export

For a Reference View file, ALWAYS, before writing:

1. Set `FILE_SCHEMA(('IFC4'))` and the `ReferenceView_V1.2`
   ViewDefinition.
2. Convert every Boolean / CSG solid to tessellation or a plain swept
   solid.
3. Emit `Body` geometry only as `Tessellation`, `SweptSolid`, or
   `AdvancedSweptSolid` (swept disk).
4. Keep `MappedRepresentation` for repeated type geometry; it is
   permitted.
5. Verify no `IfcBooleanResult`, `IfcBooleanClippingResult`, or
   half-space solid remains in any representation.

### Pattern 4: a Design Transfer View export

The Design Transfer View permits all geometry. ALWAYS still:

1. Set `FILE_SCHEMA(('IFC4'))` and the `DesignTransferView_V1.1`
   ViewDefinition.
2. Keep parametric and Boolean geometry intact so the receiving tool can
   edit it.
3. Treat the file as a superset of a Reference View export: a Reference
   View reader must still be able to consume the Reference-View parts.

### Pattern 5: verify before claiming conformance

After export, ALWAYS upload the file to the buildingSMART Validation
Service. It checks STEP syntax, the EXPRESS schema, and the normative
rules. Export certification scorecards are built from real user files
uploaded this way. A file that declares an MVD but fails validation is
not conformant regardless of the header string.

## Reference Links

- `references/methods.md`: the MVD registry, the ViewDefinition keyword
  syntax, the geometry matrix, and the certification context.
- `references/examples.md`: complete header strings per MVD and a
  Reference View conformance checklist.
- `references/anti-patterns.md`: the export mistakes that break MVD
  conformance.

### Related skills

- `ifc-core-mvd`: the MVD concept, concept templates, and Root Concepts.
- `ifc-syntax-geometry-tessellation`: the tessellation entities a
  Reference View export relies on.
- `ifc-syntax-step-physical-file`: the `FILE_DESCRIPTION` and
  `FILE_SCHEMA` header syntax.

### Official sources

- IFC4 Reference View specification:
  https://standards.buildingsmart.org/MVD/RELEASE/IFC4/ADD2_TC1/RV1_2/HTML/schema/views/reference-view/index.htm
- buildingSMART MVD database:
  https://technical.buildingsmart.org/standards/ifc/mvd/
- buildingSMART software certification:
  https://www.buildingsmart.org/compliance/software-certification/
- buildingSMART Validation Service:
  https://www.buildingsmart.org/users/services/validation-service/