# Ifc Agents Model Author > Use when authoring a complete, coordinated IFC model from scratch and you need the correct build order, or when an IFC file you produced is rejected, opens empty in a viewer, or loses its elements, properties or geometry downstream. Prevents adding elements before the project skeleton exists, skipping units or representation contexts, wiring the spatial tree with the wrong relationship, attaching geometry with no context, and declaring a model done without validating it. Covers the end-to-end authoring sequence (version and MVD decision, STEP header, IfcProject, units, representation contexts, owner history, spatial tree, elements, geometry, placement, properties, materials, classifications), which syntax and impl skill owns each step, the IFC2x3 versus IFC4 versus IFC4.3 differences that change the build, and the self-check before delivery. Keywords: IFC model authoring, build a complete IFC file, IfcProject setup, IfcUnitAssignment, IfcGeometricRepresentationContext, spatial structure, IfcRelAggregates, Ifc - Skill: `impertio-studio/ifc-agents-model-author` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add impertio-studio/ifc-agents-model-author` - Raw SKILL.md: https://api.skillmd.com/api/skills/impertio-studio/ifc-agents-model-author/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - License: MIT - Author: Impertio-Studio (https://skillmd.com/u/impertio-studio) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/impertio-studio/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 | # | Step | Key entities | Owning skill | |---|------|--------------|--------------| | 0 | Decide version and MVD | (none) | `ifc-core-version-evolution`, `ifc-core-mvd` | | 1 | STEP header | `FILE_SCHEMA`, `FILE_DESCRIPTION` | `ifc-syntax-step-physical-file` | | 2 | Project root | `IfcProject` | `ifc-impl-authoring-file` | | 3 | Units | `IfcUnitAssignment`, `IfcSIUnit` | `ifc-syntax-units` | | 4 | Representation contexts | `IfcGeometricRepresentationContext` | `ifc-syntax-geometry-representations` | | 5 | Owner history | `IfcOwnerHistory` | `ifc-impl-authoring-file` | | 6 | Spatial tree | `IfcSite`, `IfcBuilding`, `IfcBuildingStorey`, `IfcSpace`, `IfcRelAggregates` | `ifc-impl-spatial-decomposition` | | 7 | Elements | `IfcWall`, `IfcSlab`, `IfcRelContainedInSpatialStructure` | `ifc-syntax-building-elements` | | 8 | Geometry | `IfcProductDefinitionShape`, `IfcShapeRepresentation` | `ifc-syntax-geometry-representations` | | 9 | Placement | `IfcLocalPlacement` | `ifc-syntax-geometry-placement` | | 10 | Properties and quantities | `IfcPropertySet`, `IfcRelDefinesByProperties` | `ifc-syntax-property-sets` | | 11 | Materials and classifications | `IfcMaterial`, `IfcRelAssociatesMaterial` | `ifc-syntax-materials` | | 12 | Self-validate | (none) | `ifc-agents-file-validator` | 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 | Concern | IFC2x3 | IFC4 | IFC4.3 | |---------|--------|------|--------| | `FILE_SCHEMA` token | `IFC2X3` | `IFC4` | `IFC4X3_ADD2` | | `IfcRoot.OwnerHistory` | mandatory | optional | optional | | Element supertype | `IfcBuildingElement` | `IfcBuildingElement` | `IfcBuiltElement` | | Tessellated geometry | not available | available | available | | Top spatial container | `IfcBuilding` | `IfcBuilding` | `IfcFacility` / `IfcBuilding` | 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/