Limitations of IDS

It's important to understand the scope of IDS. The first version of IDS (at the time of writing) is intentionally limited to basic information presence and simple relationships. IDS is not meant for complex rule checking such as geometric reasoning or cross-element computations . For example, IDS cannot directly check:

• Geometric conditions (e.g. "no clashes between beams and pipes" or "walls must be at least 3m from the site boundary") .
• Aggregated totals or calculations (e.g. "the total area of all office spaces must exceed 300 m²") .
• Uniqueness or cross-checks (e.g. "all door type names must be unique within the model") .
• Dependencies on external data or sequences (e.g. "all pumps must have a manufacturer provided in an external database", or schedule sequences) .
• Performance or metadata about the model itself (e.g. "the model file size must be under X MB" or "the model must open within 3 minutes") .

Such checks typically require more advanced model checking tools or manual QA processes. IDS focuses on properties, classifications, and simple relationships that are explicitly present in the IFC data. It's meant to cover common data deliverable requirements (like "each element has certain properties filled out") across disciplines. If your requirements go beyond what IDS can express (for instance, involving geometry or complex logic), you will need to use IDS in combination with other checking methods.

With an understanding of facets, you should be able to interpret an IDS file's logic or start creating your own. Remember that a well-structured IDS uses:

• Descriptions and metadata to clarify each requirement,
• The appropriate facets in Applicability to target the right elements,
• The appropriate facets in Requirements to state the needed info,
• Possibly Complex Restrictions for values when flexibility is required,
• And overall, keeps within the scope of what IDS is best at (don't try to force IDS to check things like geometry or uniqueness – use other tools for that).