ifc-impl-mvd-export

name	ifc-impl-mvd-export
description	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, tessellation export, geometry restriction, CSG excluded, IFC certification, Validation Service, export scorecard, which MVD should I use, my IFC export is not conformant, how do I export a reference model, what is an MVD.
license	MIT
compatibility	Designed for Claude Code. Requires IFC IFC2x3, IFC4, IFC4.3.
metadata	{"author":"OpenAEC-Foundation","version":"1.0"}

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/