Turn BIM Information Needs into Exchange Requirements with IDS
“Include all information” is difficult to deliver and even harder to verify. A useful exchange requirement says which objects are in scope, which classifications and properties they need, what values or units are allowed, and which project purpose those requirements serve.
Requirement, schema, support, and acceptance are different
Keep four questions separate:
- Requirement: What information must the sender deliver?
- Schema: Which representation can carry that information?
- Implementation: Can the selected authoring, exporting, checking, and receiving tools produce and interpret it?
- Acceptance: Does this delivered model satisfy the project’s stated requirements?
An Information Delivery Specification (IDS) addresses the first question in a computer-interpretable form. It complements an IFC release and model-view scope; it does not replace them. It also does not prove that a tool can generate the requirement or that a delivered model passes it.
What IDS can describe
buildingSMART describes IDS as a machine-readable document for model-based exchange requirements. The stated requirement targets include:
- objects or object categories;
- classifications, including additional or national/company classifications;
- properties, including IFC or additional property definitions;
- required values; and
- units.
The requirements can be localized to a use case or project. The buildingSMART technical page presents validation as a use of IDS, but “enables checking” must not be expanded into an automatic acceptance decision for every delivery.
IDS 1.0 gives that model a more exact shape. Each specification separates a description, the applicable subset of the IFC model, and the requirements for that subset. Its facets include Entity, Attribute, Classification, Property, Material, and Parts. Entity constraints depend on the selected IFC schema and can include a predefined type; property facets identify a property set and base name and can constrain values or data types. Required, Optional, and Prohibited cardinalities express different delivery expectations.
The same manual limits the claim. IDS 1.0 measure values are compared using SI units, but IDS cannot require the model’s display unit. The manual also places geometry checks, dynamic or calculated values, data outside the IFC model, and several domain-specific relationships outside its first-version scope. Use complementary checks for those concerns.
The buildingSMART IDS repository identifies version 1.0 as a final buildingSMART Standard. Always attach the version to an actual requirement and verify the implementation context; adoption and interpretation remain tool- and version-dependent.
Implementation validity has layers too. The buildingSMART IDS developer guide on the repository’s development branch separates XSD validation from fuller IDS auditing, expects authoring software to preserve valid information when loading and saving, and points checkers to the repository’s IFC/IDS test suite. A checker should disclose when it cannot parse the IFC version nominated by the requirement. These expectations do not establish that a particular product complies.
From a reader need to a checkable requirement
Start with the task, not with a list of every property a schema happens to contain. For example, a coordination handoff might need structural and mechanical equipment objects to be classifiable and placed in the right project structure. A facilities handover might need maintainable assets, identifiers, manufacturer information, and service properties. These are different information needs.
A requirement should make its scope explicit:
| Requirement dimension | Example question |
|---|---|
| Applicability | Which objects, types, systems, or spatial areas are covered? |
| Object/class | What object or class must be present? |
| Classification | Which system, edition, identifier, or class reference is required? |
| Property | Which named property and property-set context must exist? |
| Value | Is there an allowed value, pattern, range, or enumeration? |
| Unit | Which unit applies to a measure-valued property or quantity? |
| Context | Which IFC release, model view, coordinate context, and project purpose govern interpretation? |
The following is a conceptual example, not a valid IDS XML file:
purpose: facilities-handover
ifc_release: "exact release agreed by the project"
model_view: "exact view or profile, if applicable"
applicability: "maintainable mechanical equipment"
requirements:
- object_class: "equipment class agreed by the project"
classification: "named system and fixed version"
properties:
- name: "asset identifier"
required: true
- name: "service interval"
unit: "unit agreed by the project"
allowed_values: "range or enumeration"
exclusions:
- "parametric authoring history"
The value of this exercise is the explicit scope. The syntax, version, and implementation support must be confirmed against the IDS specification and the tools used for the project.
Pair IDS with the exchange scope
An IDS requirement does not identify the complete delivery by itself. Pair it with the IFC exchange scope: exact IFC release and status, model view or profile, direction, sender and recipient versions, coordinate context, delivery encoding, and intended use.
The requirement can say that a property or unit is expected; the exchange scope says which representation and purpose frame the expectation. Without both, a sender may satisfy a requirement in a form the recipient cannot use, or a recipient may reject a useful delivery because the expected scope was never declared.
Version external vocabularies deliberately
buildingSMART’s bSDD guidance shows how dictionaries, classes, materials, and properties can be referenced from IFC and IDS by URI. It also distinguishes resource versions. A latest URI can resolve to the most recent active or preview version and may change when another version becomes available. For a contractual requirement, record a specific dictionary version and resource identifier rather than relying on a mutable latest reference.
This makes the requirement more reproducible; it does not guarantee that a selected application resolves the URI or preserves the reference in an exported model. Check those behaviors with the exact tool, release, IDS version, IFC version, and test model.
What IDS does not decide
IDS does not choose a project’s CRS, origin, model view, acceptance tolerance, or business purpose. It does not establish exporter/importer support, semantic preservation, editability, or project acceptance. Those decisions require the project agreement and evidence from the chosen implementation and delivery.
The official buildingSMART mvdXML page identifies mvdXML 1.1 as its latest official publication, reports implementation/documentation limitations, and recommends IDS for defining information requirements for IFC datasets. Community-developed mvdXML 1.2 and 1.3 are separately described as outside the buildingSMART process and standards-committee approval. Keep those statuses distinct when comparing requirements artifacts.
The buildingSMART software directory is useful for finding candidates, but its entries are vendor self-reports that buildingSMART says it does not verify and are not a certification list. Treat an entry as a lead for exact product and version follow-up, not as evidence that the tool authors, exports, checks, or preserves the requirement.
Hand the requirement to acceptance
For each IDS requirement, decide in advance what evidence will show compliance: the exact delivered file and version, a structured report, a manual review for context that cannot be checked automatically, and any independent spatial or geometric comparison needed by the task. IDS makes expectations more precise; the validation category owns the acceptance process and decision.