IDS Validation Workflow: From IFC Requirements to Correction

An IDS validation workflow starts with project information requirements expressed in an Information Delivery Specification. The delivered IFC model is checked against those requirements so reviewers can identify missing or invalid properties on the applicable objects. This project-specific IDS check is different from general IFC schema and conformance validation.

Most teams can produce a validation result. The hard part is deciding what to do with it before the exchange window closes. If fifty doors all fail the same property rule, the issue is not the count. The issue is whether the workflow can push a controlled correction back into the model fast enough.

A failed requirement needs review before it becomes an issue. The team should inspect the affected objects, group repeated failures and decide which findings require action. BCF can carry the useful model viewpoint, element references and requirement context into coordination. The loop breaks when checking and correction live too far apart or when every machine result becomes an undifferentiated report item.

A practical setup keeps IDS review, failure grouping and BCF issue context in ExyViewer, then moves into ExyRev when the workflow genuinely needs model-side correction. IDS Spec supports the rule and checking side; IDS_Map supports the part where wrong or empty values have to be corrected against those expectations. The corrected source model can then produce the next IFC delivery for revalidation.

The loop closes only when the corrected model is exported again and checked against the same reviewed IDS and scope. Someone still has to own the requirements, approve the corrections and interpret the result. Revalidation confirms whether the agreed information issue was resolved; it does not turn IDS into an automatic project approval.