IFC quality review works best when each finding can be traced to a defined check, a model revision, and an affected object. Copilot for IFC can help investigate the results and organize follow-up work. A conversational response alone is not evidence that a model satisfies every schema or project requirement.
Choose the checks the exchange requires
Keep three types of review distinct:
- File and schema checks: validate the file syntax, referenced IFC schema, and applicable specification rules.
- Information requirements: check the properties, classifications, and values required by the receiving party.
- Design and coordination review: assess geometry, interfaces, and engineering decisions using the appropriate discipline tools and reviewers.
The buildingSMART IFC Validation Service documents checks for syntax, schema, normative rules, and industry practices. If you use that service, account for its file-upload process in your project data handling requirements.
Information Delivery Specification (IDS) provides a machine-readable way to express supported information requirements. Passing an IDS check establishes the result for those requirements; it does not establish that every aspect of the model or design is correct.
Use Copilot for a bounded investigation
Flinker’s Copilot documentation describes property checks, extraction, visual analysis, and controlled edits to copies. Specify the model scope and the evidence you want returned. For example:
Find IfcDoor elements without the property required by this project check. Return their GlobalIds, names, and storeys. Separate absent properties from empty values. Do not edit the file.
Review a sample of the reported objects in the viewer. Confirm that the property path, units, and applicability match the requirement. A property that is irrelevant to an element should not be reported as missing solely because it is absent.
Record findings that another person can reproduce
For each issue, retain the source revision, check or rule version, element identifier, observed value, expected condition, and review outcome. Distinguish confirmed errors from warnings and matters requiring design judgment.
Where a workflow or script is generated, inspect its selection logic and any proposed writes before running it. Retain the checked workflow with the results so that the same investigation can be repeated.
Correct at the appropriate source
Prefer correcting the authoring model when the problem originates there. If an exchange-file correction is necessary, work on a copy and record the change. Missing geometry or relationships require an informed decision; inserting a plausible placeholder can conceal the original defect.
Assess references before changing GlobalIds, since linked issues and downstream records may depend on them. Repeat the relevant validation after correction and open the revised model in the receiving application. Close the issue only when the agreed acceptance check passes.