An IFC File Can Be Valid and Still Miss the Information Your GPU Project Needs

Start with the information the recipient needs

Suppose the recipient of a GPU cabling model needs to join the proposed pathway objects to a route schedule. The agreed link is a customer-defined RouteKey property. A visible tray shape answers neither whether that property exists nor whether its value identifies the intended schedule record.

Before buying a service described as IFC validation, ask which of those questions its return will answer. Standard conformity concerns the file's relationship to IFC. Information checking concerns a stated requirement for a stated object population. Schedule reconciliation concerns the relationship between two identified information sets. One engagement can include all three, with a separately described output for each.

The buyer's useful question is concrete: will the return show which intended pathway objects lack the agreed information, and which schedule relationships remain unresolved? Define that result before comparing prices for a validation report.

Read standard conformity with its stated scope

buildingSMART describes its IFC Validation Service as checking STEP physical-file syntax, the referenced IFC schema's formal constraints and other normative IFC rules. It also reports non-normative industry-practice findings as warnings. Treat those warnings separately from errors affecting validity.

The service checks bSDD references too. Beyond constraints encoded there, its mandate excludes project, national and organization-specific rules. Geometric visualization is outside its scope; some errors are invisible in a viewer. Opening a file therefore cannot substitute for the stated conformity checks.

Ask what a purchased conformity check actually covers. The named service's documented scope does not describe every product marketed as an IFC validator. A result should identify the file, schema and checks performed, with unresolved findings.

References: [B1]

Separate the IDS population from its requirements

IDS means Information Delivery Specification. buildingSMART's user manual describes a machine-readable way to specify and check simple information requirements in IFC models. Within each specification, applicability identifies the objects to examine; requirements describe what those objects should or should not have. Facets such as entity, classification and property supply the selection and checking criteria.

For the route-key task, the applicability needs to find the intended pathway population. The requirement then asks for the agreed property. Review these two decisions separately with the information recipient. Selecting objects because they already have RouteKey would answer a narrower question than finding missing RouteKey values across all intended pathways.

A property rule needs more than a display label. Identify its property set, property name, expected data type and any value restriction. The property-facet documentation permits project-defined properties and explains how presence, type and value constraints differ. A rule requiring a populated text field is a different purchase from a rule restricting that field to agreed codes.

References: [B2][B4]

Work through three objects and two applicable results

Fictional example EX-IV183 contains three visible objects: pathway segments T-21 and T-22, and cabinet K-9. The example stipulates an IFC issue that satisfies the agreed standard-conformity checks. No actual file, customer model or validator run is represented.

The invented project classification system ExampleScope assigns the reference GPU-PATHWAY to T-21 and T-22. K-9 is outside that classification. The proposed IDS specification selects objects with that classification and requires RouteKey in the custom property set ExampleRouteData, with data type IFCLABEL and a non-empty value. It does not restrict the value to particular route codes. These names and the requirement are invented for the example; RouteKey is not presented as a standard IFC obligation.

T-21 has the stipulated IFCLABEL value RT-21 in ExampleRouteData.RouteKey. T-22 lacks that property. Under this example rule, two objects are applicable: T-21 satisfies the information requirement and T-22 does not. K-9 is outside this check. Its visibility supplies no third result.

The correct return is one satisfied and one unsatisfied requirement among two applicable objects, plus one object outside this specification. It is not two failures among three objects, and it is not a fully accepted three-object model. The stipulated conformity result and the missing custom property can coexist because they answer different questions.

Suppose the recipient later asks whether RT-21 actually matches the intended route schedule. The presence rule has not answered that question. If that schedule lacks RT-21, T-21 can still satisfy the stated property rule while the requested join remains unresolved. Commission the reconciliation against the identified schedule separately.

References: [B2][B4]

Look for selection gaps behind a clean report

Now change only the fictional applicability: require both the GPU-PATHWAY classification and an already populated ExampleRouteData.RouteKey. T-22 no longer enters the selected population. T-21 still meets the requirement. A report can now contain one satisfied result and no unsatisfied property results, while the buyer's intended two-pathway question remains unanswered. No missing property has been supplied; the selection changed.

Ask for object identities and counts per specification, then compare that population with the intended scope. An intentionally excluded cabinet and a pathway accidentally filtered out need different explanations. Classification-based selection also deserves scrutiny: if a required pathway lacks the selecting classification, it can be missed just as an object lacking RouteKey can be missed. Reconcile the selected objects with an independently defined population rather than trusting the selector to prove its own completeness.

Cardinality adds another distinction. The cited specification manual explains that a required applicability population must have at least one match; an optional population may have none. Neither setting establishes that both intended example pathways were included. Define how an unexpectedly empty population will be reported, and investigate it against the brief instead of interpreting zero unsatisfied objects as complete coverage.

References: [B3][B4]

Check the rule file as well as the model

There are two different files to evaluate. buildingSMART's developer guide describes IDS as XML with an XSD schema, and points out that full IDS validity needs more than bare XML-schema compliance. Request the stated IDS validation or audit scope separately from the result of checking an IFC model against that IDS.

A technically valid requirement file can still encode the wrong buyer intent. In EX-IV183, an otherwise valid rule that selects only objects already carrying RouteKey would preserve the selection gap. The recipient must review the population, required information and intended use; file validation cannot make those project decisions.

Identify the IDS issue and supported version used for the model check. The guide also calls for users to be informed when software cannot parse the nominated IFC version. An unsupported or unevaluated check needs that explanation, rather than being counted as a satisfied requirement. The sources here are development-branch guidance checked on the stated date, not a declaration of the latest released IDS version.

References: [B5]

Keep information results within their useful boundary

The cited IDS specification manual places geometry checks and checks referring to data outside the IFC model beyond the capability it describes. That matters directly to the route-schedule question: checking a stored property is useful, but comparing it with an external schedule needs its own method and return. A supplied schedule or a screenshot does not extend the IDS rule automatically.

Likewise, neither a conformity result nor a satisfied information requirement establishes clash clearance, cable-assembly length or physical installation suitability. Those decisions require the applicable geometry, equipment and site evidence and the responsible project review. This article explains what checking work to commission and how to interpret it; it is not a field procedure or permission to perform physical work.

References: [B3]

Buy returns that explain the result

Ask each proposal to distinguish IFC conformity checking, preparation or review of the information requirements, and model checking against those requirements. Include external schedule reconciliation when that relationship is needed. The work can be bundled commercially while its outputs remain identifiable.

For the conformity return, require the exact IFC issue and actual check scope. For the requirement file, require its identified issue, applicable IFC and IDS versions, selection rationale and information rules, together with the agreed audit return. For the model-against-IDS report, require the same IFC and IDS issues, checker identification, applicable object population, per-specification findings and explanations for checks that were excluded or could not be evaluated. A corrected model needs a result attributable to that corrected issue.

Use EX-IV183 to compare the proposed deliverables. A conformity-only offer supplies no answer about T-22's RouteKey. An information-checking offer becomes useful when it includes both intended pathways and exposes the missing property. An offer covering the schedule join must additionally show whether the returned keys reconcile with the agreed schedule. Compare the work required for the next decision, rather than the number of green indicators.

Leviathan's Physical Infrastructure Planning and CAD service is the existing route for discussing layouts, routing coordination, point-to-point schedules and agreed documentation. Use the related service link or project inquiry to describe the recipient's information task and available authorized inputs. The engagement must confirm its actual authoring tools, production resources and supported outputs, and identify the party responsible for any specialist IFC or IDS checking.