Model view definition vs IDS: who uses which (2026)
An MVD scopes an IFC exchange for software implementers; an IDS states a project's information requirements in a machine-checkable file. IDS 1.0 became a buildingSMART standard on 1 June 2024.
A Model View Definition (MVD) is a formally specified subset of the IFC schema that scopes one exchange use case, defining which entities, property sets, and geometric representations a compliant export contains. buildingSMART positions MVDs as the tool for software implementers and the Information Delivery Specification (IDS) as the tool for end users and projects. IDS 1.0 became a buildingSMART standard on 1 June 2024.
Key numbers at a glance
| Metric | Value |
|---|---|
| MVD file format | mvdXML |
| MVDs in the table below | 3 (Coordination View 2.0, Reference View, Design Transfer View) |
| IDS 1.0 standard date | 1 June 2024 |
| Software certification scope | Per exchange scenario (MVD), not the full IFC schema |
What is a model view definition and why does it exist?
A Model View Definition answers one question: what must a valid IFC export contain for a specific exchange? IFC describes everything a building model can contain. Without a scoping mechanism, “send me your IFC” is ambiguous, because the receiving tool must guess which entities, property sets, and geometry are present. An MVD specifies, for one exchange scenario, what a compliant export contains, and software can be tested and certified against it. Software certification is therefore tied to an MVD, not to the full IFC schema. Check your tool’s current IFC export settings, since the default MVD varies by product and version.
AEC market trends, new project opportunities, and AI insights
You're in. Check your inbox.
Something went wrong. Please try again.
✓ You're subscribed. Thanks.
What are the main MVDs?
Three MVDs are well established. Coordination View 2.0 is bound to IFC2x3. Reference View and Design Transfer View are bound to IFC4. Reference View carries a model for reference and coordination. Design Transfer View targets exchange for continued design work. buildingSMART maintains further MVDs and drafts for other exchanges (for example structural analysis, FM handover and energy analysis); we have not verified their current status, so check buildingSMART’s MVD page before specifying one. This table has no IFC4.3 binding; do not assume one exists for your tool.
| MVD | IFC base | Purpose |
|---|---|---|
| Coordination View 2.0 | IFC2x3 | Architecture, structure and MEP coordination |
| Reference View | IFC4 | Model reference and coordination |
| Design Transfer View | IFC4 | Exchange of model data for continued design |
A certification against Coordination View 2.0 is a certification against IFC2x3 only, not IFC4.
How do MVD and IDS differ?
IDS (Information Delivery Specification) is a computer-interpretable document that defines exchange requirements: how objects, classifications, materials, properties, and values should be delivered in an IFC model. It is an XML format, readable by people and machines, and its purpose is automatic compliance checking of IFC models, with the same result in any checking software. IDS is tied to the IFC schema: it states what is required among what IFC can express. buildingSMART describes the ecosystem for end users as IFC, IDS, and the buildingSMART Data Dictionary (bSDD); bSDD is a shared library of properties that can be used when preparing an IDS. MVDs, by contrast, are written by data modellers and software implementers to define what software must implement.
In practice: the MVD says what an exporting tool should be able to produce for an exchange scenario; the IDS says what this project needs in the delivered file and lets any checker verify it. They address different audiences, and some community sources call IDS a replacement for MVD. buildingSMART’s own wording is the one to follow: check its pages for the current position before telling a client either is obsolete.
What are the common mistakes in specifying IFC exchanges?
Three mistakes recur.
1. Treating IFC export as a single setting. Exports are configured to a schema version and a view definition. A team that never changes the default may export an older schema than the receiving tool expects.
2. Specifying “IFC exchange” without naming the schema version, the MVD or an IDS. Without that, the receiving team cannot validate what arrives, and checking cannot be automated.
3. Confusing the MVD with the IFC schema version. IFC4 is a schema version. Reference View is an MVD that uses it for one exchange. Specify both.
Frequently asked questions
What is a model view definition in IFC?
An MVD is a formally defined subset of the IFC schema targeting one exchange scenario, such as coordination. It gives software vendors a testable definition of correct output. Certification against an MVD means a tool meets the requirements for that exchange, not that it supports the whole IFC schema.
What is the difference between an MVD and IDS?
An MVD scopes what software must be able to export for an exchange and is written in mvdXML. An IDS is a machine-readable document that states what a given project needs in the IFC file and enables automatic checking. buildingSMART frames IDS as the end-user tool and MVDs as the implementer tool.
Which MVD should I specify in a BIM Execution Plan?
Name the IFC schema version and the MVD your tools support for the exchange, for example IFC4 Reference View or IFC2x3 Coordination View 2.0, and name any IDS file that the delivered model must pass. Without these, the receiving team cannot validate what arrives.
Is Coordination View 2.0 still valid?
Coordination View 2.0 is bound to IFC2x3. Whether to use it depends on what the receiving application supports. Its current status is not covered here; check buildingSMART’s MVD page.
When did IDS become a standard?
IDS 1.0 became an official buildingSMART standard on 1 June 2024. Further versions are in planning.
Related Insights
Published by DataDrivenAEC. Evidence basis: technical assurance. This legacy article has not completed the source-and-edition review used for newer technical guides; verify important claims against their named sources.