Ifc Agents Model Author

IFC Model Author

This is an orchestration skill. It defines the order in which an IFC model is built and names the syntax, impl and errors skill that owns each step. It does not re-teach those skills: it sequences them.

ALWAYS author an IFC model in dependency order: a step depends on every step above it. NEVER add an element before the project skeleton (project, units, contexts, spatial tree) exists, because an element with no spatial parent and no representation context is invisible to every downstream consumer.

Quick Reference

The authoring sequence

Steps 0 to 6 are the mandatory skeleton: nothing in steps 7 to 11 is valid without them. Steps 8 to 11 repeat per element.

Version differences that change the build

ALWAYS instantiate concrete subtypes (IfcWall, IfcSlab). NEVER instantiate the abstract supertype. See ifc-errors-version-mismatch for the rename detail.

Decision Trees

Step 0 : version and MVD before any entity

What does the model contain ?
  +-- infrastructure (road, rail, bridge, alignment, earthworks)
  |     -> IFC4.3 (token IFC4X3_ADD2). No earlier schema has these entities.
  +-- a building, and the receiver is modern openBIM software
  |     -> IFC4 (token IFC4). The safe default for building models.
  +-- a building, and the receiver is an IFC2x3-only tool
        -> IFC2x3 (token IFC2X3). Accept the limits: no tessellation.

Which MVD does the deliverable target ?
  +-- coordination / clash / viewing  -> Reference View      (IFC4)
  +-- full round-trip / re-editing    -> Design Transfer View (IFC4)
  +-- IFC2x3 deliverable              -> Coordination View 2.0
  -> record the chosen MVD in FILE_DESCRIPTION as the ViewDefinition string.
  -> see ifc-core-mvd and ifc-impl-mvd-export for MVD-conformant export.

The version and MVD are fixed BEFORE step 1. NEVER revisit them mid-build:
changing schema after elements exist forces a full migration.

Build-order dependency check

About to author entity X. Is every prerequisite present ?

  IfcUnitAssignment        requires  IfcProject
  IfcGeometricRepresentationContext  requires  IfcProject
  IfcSite                  requires  IfcProject + IfcRelAggregates
  IfcBuildingStorey        requires  IfcBuilding (or IfcFacility in IFC4.3)
  any IfcElement           requires  a spatial container to contain it
  IfcShapeRepresentation   requires  an IfcGeometricRepresentationContext
  IfcLocalPlacement        requires  the parent placement (or none for the site)
  IfcRelDefinesByProperties requires  the element it defines
  IfcRelAssociatesMaterial requires  the element it associates

  prerequisite missing -> author the prerequisite first. NEVER forward-reference
  a skeleton entity that does not exist yet.

Self-check before declaring the model done

Run ifc-agents-file-validator. Confirm every answer is YES :

  [ ] FILE_SCHEMA token matches every entity used        (ifc-errors-version-mismatch)
  [ ] exactly one IfcProject, and it has a Name           (WHERE rule HasName)
  [ ] IfcUnitAssignment present, one unit per unit type   (ifc-syntax-units)
  [ ] at least one IfcGeometricRepresentationContext      (ifc-syntax-geometry-representations)
  [ ] spatial tree complete, wired with IfcRelAggregates  (ifc-errors-spatial-structure)
  [ ] every element contained exactly once                (ifc-errors-spatial-structure)
  [ ] every GlobalId present and unique                   (ifc-errors-schema-validation)
  [ ] every #id reference resolves                        (ifc-errors-broken-references)
  [ ] geometry sits in a declared context                 (ifc-errors-geometry-issues)
  [ ] no abstract entity instantiated                     (ifc-errors-schema-validation)

  any NO -> fix before delivery. NEVER declare a model done on an unrun check.

Patterns

Pattern 1 : fix version and MVD before authoring anything

The schema version and the MVD target are project-level decisions. They determine the FILE_SCHEMA token, which entities are legal, whether tessellation is available, and what the ViewDefinition string says.

ALWAYS complete step 0 before step 1. NEVER start writing entities and decide the version later: every entity name and attribute layout depends on the schema. Changing schema after elements exist is a migration, not an edit (see ifc-impl-version-migration).

Pattern 2 : the mandatory skeleton precedes every element

An IFC file is not "configured" like software; its skeleton is the minimum structure every valid model needs before any element can exist:

1. Exactly one IfcProject. IfcProject has no explicit attributes of its own; it inherits from IfcRoot and IfcContext. The HasName WHERE rule makes Name mandatory.
2. One IfcUnitAssignment, referenced by IfcProject.UnitsInContext, declaring exactly one unit per unit type (length, area, volume, plane angle). A model with no units is ambiguous by 1000x (see ifc-errors-property-set-mistakes).
3. At least one IfcGeometricRepresentationContext with ContextType set to 'Model' and CoordinateSpaceDimension of 3, referenced by IfcProject.RepresentationContexts. Sub-contexts (Body, Axis, FootPrint) are IfcGeometricRepresentationSubContext instances.
4. An IfcOwnerHistory: mandatory in IFC2x3, optional in IFC4 and IFC4.3 but expected by many importers.

ALWAYS author the skeleton top-down: project, then units and contexts, then the spatial tree. NEVER attach an element to a half-built skeleton.

Pattern 3 : two relationships, two jobs

The spatial tree and element containment use different relationships. Confusing them is the most common authoring fault.

• IfcRelAggregates builds the spatial hierarchy itself: IfcProject aggregates IfcSite, IfcSite aggregates IfcBuilding or IfcFacility, that aggregates IfcBuildingStorey or IfcFacilityPart, that aggregates IfcSpace. Attributes: RelatingObject (the whole), RelatedObjects (the parts).
• IfcRelContainedInSpatialStructure places a physical element into one spatial level. Attributes: RelatingStructure (one IfcSpatialElement), RelatedElements (a set of IfcProduct). WHERE rule WR31: a spatial element is never a RelatedElement here; spatial nesting uses IfcRelAggregates.

ALWAYS contain every physical element exactly once with IfcRelContainedInSpatialStructure. NEVER use IfcRelAggregates to put a wall on a storey, and NEVER use IfcRelContainedInSpatialStructure to nest storeys. In IFC4.3 the spatial tree can use IfcFacility and IfcFacilityPart; IfcBuilding and IfcBuildingStorey are re-parented under them.

Pattern 4 : geometry and placement attach per element

Each element repeats the same four-part attachment:

1. IfcProduct.Representation points to one IfcProductDefinitionShape.
2. The shape holds one or more IfcShapeRepresentation. Each has a RepresentationIdentifier (Body, Axis, FootPrint) and a RepresentationType (SweptSolid, Brep, Tessellation, and others).
3. IfcShapeRepresentation.ContextOfItems MUST point to an IfcGeometricRepresentationContext (or a sub-context). The WHERE rule requires the context to be a geometric representation context.
4. IfcProduct.ObjectPlacement points to an IfcLocalPlacement, chained to the parent placement through PlacementRelTo. The site placement has no parent.

ALWAYS put geometry items in a declared context and chain the placement to the spatial parent. NEVER emit geometry with no context: a viewer cannot scale or position it (see ifc-errors-geometry-issues).

Pattern 5 : semantic enrichment is the last layer

Properties, quantities, materials and classifications attach to elements that already exist, are placed and have geometry:

• IfcPropertySet linked by IfcRelDefinesByProperties.
• IfcElementQuantity linked by IfcRelDefinesByProperties.
• IfcMaterial and the layer, profile and constituent set families linked by IfcRelAssociatesMaterial.
• IfcClassificationReference linked by IfcRelAssociatesClassification.

ALWAYS enrich after the element, its placement and its geometry exist. See ifc-impl-data-enrichment for the enrichment workflow and ifc-errors-property-set-mistakes for the reserved Pset_ prefix and type-versus-occurrence traps.

Pattern 6 : self-validate before delivery

A model is done only when it passes validation, not when the last element is written. Run ifc-agents-file-validator and the self-check decision tree above.

ALWAYS validate before declaring the model done. NEVER deliver a model on the assumption that "it opened in one viewer": a viewer is lenient, the buildingSMART validation pipeline is not (see ifc-core-validation).

Reference Links

• references/methods.md : the full step-by-step authoring procedure, the owning-skill map, and the version-specific build differences.
• references/examples.md : a minimal valid IFC4 file built in sequence, and the per-element repeat block.
• references/anti-patterns.md : every authoring-orchestration failure mode.

Cross-references:

• ifc-impl-authoring-file : the hands-on file-authoring workflow.
• ifc-impl-spatial-decomposition : building the spatial tree correctly.
• ifc-impl-data-enrichment : attaching properties, materials, classifications.
• ifc-impl-mvd-export : exporting a model conformant to an MVD.
• ifc-agents-file-validator : the validation orchestration this skill calls.
• ifc-errors-version-mismatch, ifc-errors-spatial-structure, ifc-errors-geometry-issues, ifc-errors-schema-validation : the failure modes the self-check guards against.

Official sources (verify before asserting any entity or attribute):

• IFC4.3 specification: https://ifc43-docs.standards.buildingsmart.org/
• IFC4 ADD2 TC1: https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/HTML/
• IFC2x3 TC1: https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/