Ifc Agents File Validator

IFC File Validator (Orchestration)

Drive a complete, ordered validation pass over an IFC file. This is an ORCHESTRATION skill : it sequences the buildingSMART five-stage validation pipeline, walks the fifteen-item anti-pattern catalog, triages every finding by severity, and routes each fault class to the matching ifc-errors-* skill that holds the detailed fix.

This skill answers one question : is this IFC file conformant, and if not, where is the fault and which skill fixes it. It does NOT itself teach the fixes. It is the conductor ; the ifc-errors-* skills are the instruments.

Scope boundary : this skill checks SCHEMA CONFORMANCE (the file obeys the IFC standard). It does NOT check PROJECT INFORMATION REQUIREMENTS (the file carries the data a specific project demanded). Information completeness beyond schema conformance belongs to ifc-agents-quality-checker. Project requirements are expressed in IDS, which is out of this package scope. For the conceptual validation MODEL see ifc-core-validation.

Quick Reference

The five-stage validation pipeline

The buildingSMART validation service runs these stages in order. ALWAYS run them in this order : a later stage assumes the earlier one passed.

Stage 5 (bSDD) is temporarily DISABLED in the public validation service as of service version v0.6.6. ALWAYS report it as disabled, NEVER as pass.

Outcome severities

Five severities : pass, warning, error, not applicable, disabled.

• error invalidates the file. The file is non-conformant.
• warning does NOT invalidate the file. Industry-practice checks only warn.
• pass, not applicable and disabled results are HIDDEN by default in the report. ALWAYS read a check absent from the visible report as PASSED or not run, NEVER as a missing or skipped requirement.

Orchestration rules

• ALWAYS run stage 1 first. If STEP syntax fails, STOP : no later stage can run on a file that does not parse.
• ALWAYS confirm the declared schema version before stage 2 compliance : a compliance check is meaningless against the wrong schema.
• NEVER report a file as "valid" while any stage 1, 2, or 3 finding is an error. NEVER report a file as "invalid" when the only findings are stage 4 warning results.
• ALWAYS route each finding to the owning ifc-errors-* skill rather than improvising a fix here.

Decision Trees

Tree A : "Validate this IFC file"

A validation pass is requested on an IFC file.
|
+-- Stage 1 : Does the file parse as ISO 10303-21 STEP?
|   No : header malformed, string escaping broken, encoding wrong.
|     -> ERROR. STOP the pipeline. Route to ifc-errors-encoding-issues.
|        Report : file rejected before schema check.
|   Yes : continue.
|
+-- Stage 2a : Is FILE_SCHEMA one of IFC2X3, IFC4, IFC4X3_ADD2?
|   No, or it disagrees with the entities used.
|     -> ERROR. Route to ifc-errors-version-mismatch. Continue with the
|        version actually declared.
|
+-- Stage 2b : Schema compliance. Walk anti-patterns 3, 5, 6, 14, 15.
|   Abstract instantiation, WHERE-rule break, cardinality, wrong type,
|   deprecated entity, derived attribute set by hand.
|     -> Each is an ERROR. Route per the anti-pattern map (Pattern 2).
|
+-- Stage 3 : Normative Gherkin rules. Walk anti-patterns 1, 4, 7, 11, 12.
|   Missing spatial containment, geometry with no context, dangling
|   reference, MVD-inconsistent geometry, degenerate geometry.
|     -> Each is an ERROR. Route per the anti-pattern map.
|
+-- Stage 4 : Industry practice. Walk anti-patterns 8, 9.
|   Missing material association, missing project property sets.
|     -> WARNING only. The file stays valid. Route to
|        ifc-agents-quality-checker for the completeness audit.
|
+-- Stage 5 : bSDD. Report as disabled (service v0.6.6+).
|
+-- Aggregate : any stage 1 to 3 error -> file is NON-CONFORMANT.
      No error, warnings only -> file is CONFORMANT with warnings.

Tree B : "Triage a buildingSMART validation report"

A validation report is in hand and the question is what it means.
|
+-- Read the severity of each visible result.
|
+-- Any result with severity error?
|   Yes -> The file is non-conformant. List every error, route each to its
|          ifc-errors-* skill. The file is NOT deliverable.
|   No  -> continue.
|
+-- Only warning results visible?
|     -> The file IS conformant. Warnings are industry-practice advice. Decide
|        with the user whether to address them ; do not block delivery on them.
|
+-- A check the user expected is not in the report at all?
|     -> It passed (pass is hidden by default), or it is not applicable, or it
|        is disabled. NEVER read absence as "the checker skipped my file".
|
+-- The report says the file is valid but the user reports a real defect?
      -> The defect is a PROJECT INFORMATION gap, not a schema fault. Route to
         ifc-agents-quality-checker. Schema validity never proves completeness.

Patterns

Pattern 1 : Run the pipeline as a stop-on-syntax gate

ALWAYS treat the five stages as a gate, not a parallel scan.

1. Run stage 1 (STEP syntax). On any error, STOP and report. A file that does not parse cannot be schema-checked : reporting later-stage results would be fabricated.
2. Run stage 2 version check, then stage 2 compliance.
3. Run stage 3 normative checks (Implementer Agreements, then Informal Propositions).
4. Run stage 4 industry-practice checks. These never stop the pipeline.
5. Report stage 5 (bSDD) as disabled.
6. Aggregate : the file is conformant if and only if no stage 1 to 3 finding is an error.

The public validation service at https://validate.buildingsmart.org/ runs exactly this pipeline. When a file cannot be uploaded to the service, ALWAYS reproduce the same ORDER locally and state which stages were checked by which tool.

Pattern 2 : The fifteen-item anti-pattern checklist

ALWAYS walk all fifteen. Each maps to a pipeline stage and an owning skill. The full catalog with detection cues is in references/methods.md.

Items 1 to 12 are hard faults : 1, 4, 7, 11, 12 invalidate at stage 3 ; 3, 5, 6, 14, 15 invalidate at stage 2 ; 10 invalidates at stage 1. Items 8 and 9 are stage-4 warnings : real defects, but they do NOT invalidate the file.

Pattern 3 : The Gherkin functional-part coverage map

Stage 3 normative rules are buildingSMART Gherkin rules, grouped under three-letter functional-part prefixes. ALWAYS use the prefix to know which domain a rule code touches and which skill owns it.

A rule code is its prefix plus a number, for example GEM051, SPS001. The prefix is the routing key. The full prefix list and detail are in references/methods.md.

Pattern 4 : Triage findings by severity

ALWAYS classify every finding into exactly one of three buckets before reporting.

• ERROR : a stage 1, 2, or 3 error. The file is non-conformant. It is NOT deliverable until fixed. Route to the owning skill.
• WARNING : a stage 4 industry-practice warning. The file is conformant. The warning is advice. Surface it, do not block on it.
• INFORMATIONAL : a pass, not applicable, or disabled result, usually hidden. It carries no action. NEVER escalate an informational result to a warning or error.

NEVER collapse the three buckets. Treating a warning as an error blocks a valid deliverable ; treating an error as a warning ships a broken file.

Pattern 5 : The validation report structure

A validation pass ALWAYS ends with a structured report, not a verdict word. ALWAYS produce these sections :

1. Header : file name, declared schema, declared MVD (from FILE_DESCRIPTION).
2. Verdict : CONFORMANT or NON-CONFORMANT, derived strictly from Pattern 1 step 6.
3. Errors : one row per error : stage, anti-pattern number, owning skill, one-line description.
4. Warnings : one row per industry-practice warning.
5. Not checked : stages and checks that were disabled or not applicable, stated explicitly so the reader never assumes silent coverage.
6. Next actions : the ordered list of owning skills to invoke.

A worked report is in references/examples.md.

Version Notes

• The validation pipeline, severities, and Gherkin rule layer apply to IFC2x3, IFC4 and IFC4.3 files. The validation service accepts schema identifiers IFC2X3, IFC4 and IFC4X3_ADD2.
• Gherkin rules carry version tags (for example @version2) and an MVD Background. ALWAYS check that a rule applies to the file's schema and MVD before treating its result as binding.
• Anti-pattern 6 (deprecated entities) is version-specific : IfcWallStandardCase and the *StandardCase family are removed after IFC4 ; IfcBuildingElement is renamed IfcBuiltElement in IFC4.3. Route version faults to ifc-errors-version-mismatch, which holds the rename matrix.
• Stage 5 (bSDD) is disabled in the public service as of v0.6.6. This is a service state, not a schema-version property.

Reference Links

• references/methods.md : the five-stage pipeline in full, the fifteen-item anti-pattern catalog with detection cues, the complete Gherkin functional-part prefix table, severity semantics, and how to run a single Gherkin rule.
• references/examples.md : a worked validation run and a worked report.
• references/anti-patterns.md : mistakes in the validation PROCESS itself.

Official sources (see SOURCES.md) :

• buildingSMART validation service : https://validate.buildingsmart.org/
• Validation service user guide : https://buildingsmart.github.io/validate/
• IFC Gherkin normative rules : https://github.com/buildingSMART/ifc-gherkin-rules
• IFC 4.3 specification : https://ifc43-docs.standards.buildingsmart.org/