Define information requirements
Replace requests such as 'include all BIM data' with a list of decisions and the information needed for each one. For each required field, identify the responsible source, applicable objects and review method. Unnecessary fields make delivery larger and exceptions harder to see.
Distinguish an empty value, an unknown value and a value that does not apply. Agree how each state should be represented. Do not insert invented identifiers, dimensions or performance values merely to make a completeness check pass.
Specify where the value belongs
IFC property sets group named values and may be assigned to object occurrences or types. Standard property sets use the Pset_ naming convention; user-defined sets should not use that reserved prefix. Check the applicable schema definition before choosing a standard property.
- Use the exact agreed property-set and property names, including spelling and capitalisation.
- Specify the value type and unit where relevant. A number stored as arbitrary text may not be usable by a numeric rule.
- Decide whether the field belongs to a shared type or an individual asset.
- Document the mapping from source fields to delivered fields and identify any transformation.
- Avoid multiple conflicting fields that appear to describe the same fact.
Official references
Example asset information schedule
| Project field | Applies to | Requirement | Reviewer |
|---|---|---|---|
| NB_Asset.AssetCode | Equipment selected for maintenance handover | Non-empty text; unique within the agreed asset register | Asset information lead |
| NB_Asset.ServiceZone | The same equipment scope | One of the project's approved zone codes | Discipline coordinator |
| NB_Asset.MaintenanceRequired | The same equipment scope | Boolean value from the approved maintenance schedule | Operations representative |
| NB_Asset.SourceReference | The same equipment scope | Reference to the approved source record | Delivery author |
For each row, add the source field, delivery stage, exception handling and rule identifier. Test one correct item, one missing value and one deliberately invalid value in an authorized test model. Confirm that the checker reports each condition as intended.
Information Delivery Specification (IDS)
Information Delivery Specification (IDS) is a buildingSMART standard for expressing information requirements in a computer-interpretable form. It can describe which objects a requirement applies to and required information such as classifications, materials and properties. Supported tools can use it to check IFC deliveries.
Start with an approved human-readable schedule, then implement the expressible rules in an IDS-capable tool. Keep the IDS file, version and checker report with the delivery. Check which requirements the tool actually covers; do not assume a field-completeness result establishes geometric correctness or the truth of a value.
For the example above, presence and allowed-value rules may fit an information check, while uniqueness across a separate asset register needs an additional check. Assign every requirement to a verification method instead of forcing all review work into one tool.
Official references
Resolve failures at their source
Confirm applicability
Verify that the failed object belongs to the required scope. A rule applied too broadly can create misleading failures.
Check the source value
Distinguish missing source information from a mapping or export defect. Ask the responsible author to resolve the underlying issue.
Repeat the check
Export the corrected revision, rerun the same rule set and compare outcomes.
Record exceptions
Keep an owner, reason and agreed disposition for each accepted exception. Never treat a waived check as a passed check.