Model checking

Model checking means testing models against agreed rules before relying on them. It goes well beyond clash detection.

Layers of checks

1. File and naming — is the container named correctly, in the right format and schema? See information container naming.
2. Model structure — storeys, spatial containment, correct IFC classes, no duplicates, sensible element counts.
3. Information — are the required properties present and filled with valid values? Increasingly written as IDS files.
4. Geometry and coordination — clashes, clearances and duplicates between and within disciplines. See clash detection types.
5. Requirements and regulations — rules derived from codes or client standards, such as escape distances or accessibility.

Who checks what

• Each task team checks its own model before sharing it — the "check" step of the CDE workflow.
• The coordinator checks the federated model, focusing on interfaces between disciplines.
• The client side may audit models against the information requirements at milestones.

Making checks routine

• Start with a small set of rules everybody understands, and grow it.
• Run the same checks every cycle so results are comparable over time.
• Report results as issues with owners and due dates, not as long PDF reports nobody reads.