A useful IDS example explains the project intention, the objects involved, the information being requested and the expected result. The three examples below show different ways to make a requirement more precise. All project names, custom fields and sample values are illustrative.
Use them to discuss the structure of your own requirements, then create and test the specifications in the software used by your team.
Example 1: Record fire rating information for walls
Project intention: A reviewer needs the agreed fire rating information for the walls included in a design delivery.
| Decision | Example definition |
|---|---|
| Objects in scope | Wall occurrences represented as IfcWall |
| Property set | Pset_WallCommon |
| Property name | FireRating |
| Data type | IFCLABEL in the IDS property facet |
| Information rule | A populated property value is required |
| Value restriction | None in this first example |
The property and its data type are described in the buildingSMART property facet guide.
Because this example does not restrict the value, it only asks for the agreed property to be populated. Before using it on a project, decide whether the review also needs an approved list of values. A populated but unsuitable label would require an additional rule to reject it.
Also decide whether walls are expected to exist in this delivery. A specification that permits no applicable objects needs to be interpreted differently from one that requires them.
Example 2: Use an agreed naming convention for doors
Project intention: The coordination team wants door names in a consistent project format.
For this hypothetical convention, the Name attribute must contain the prefix DR- followed by exactly three digits. The rule would be expressed with an attribute facet and a text pattern suitable for IDS.
| Sample name | Intended outcome under this convention | Reason |
|---|---|---|
DR-014 | Meets the convention | Correct prefix and three digits |
DR-7 | Does not meet the convention | Only one digit |
Door 014 | Does not meet the convention | Different prefix and format |
DR-014A | Does not meet the convention | Additional character |
A naming rule should be agreed with the people producing and consuming the information. It is most useful when the convention supports an actual workflow, such as locating items in a schedule.
Example 3: Record a project's room-use category
Project intention: The briefing team wants spaces assigned one of three project categories for a pilot review.
| Decision | Example definition |
|---|---|
| Objects in scope | Spaces represented as IfcSpace |
| Custom property set | Compass_SpaceBrief |
| Custom property | UseCategory |
| Expected data type | IFCLABEL |
| Allowed values | Teaching, Office, Support |
Compass_SpaceBrief and UseCategory are invented project fields, not buildingSMART standard definitions. A space with Office would satisfy the described value rule; a space with Administration would require review because that value is outside the illustrative list.
Before adopting a custom field, check whether an existing standard property or classification already expresses the intended meaning. Record any mapping your delivery team needs. The pilot's short list is a design choice for this example, not a recommended classification for all buildings.
How to adapt an example
Write down the purpose, confirm the scope and replace the sample values with the project's agreement. Include passing, failing and out-of-scope objects in a small test. Document what you expect before running the checker.
The result should help the next person understand both the rule and the reason for it.
Follow the creation guide, review applicability and requirements, or organise your specifications in IDS Compass.