What is in the file
One IFC file, named schema, named model view definition. Below is what a BIM manager opens it to find: the spatial spine, the entity and the geometry authored for each of the 8 element classes, the property sets carried on every element, and the rule that decides an element’s identity. The counts are read from the sample package on this page, not asserted.
Schema and view definition
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [ReferenceView_V1.2]'),'2;1');
FILE_NAME('Larch Annex','2026-01-01T00:00:00',('Structura'),('Structura'),'structura-pipeline','structura-pipeline','none');
FILE_SCHEMA(('IFC4'));
ENDSEC; Read from the committed sample at build time. The timestamp is pinned, not a wall clock: writing the same model twice yields byte-identical files.
The view definition is the part most conversions leave blank.
Structura declares one and holds to it: geometry is explicit, every element is a real IFC entity of its own class, and nothing depends on a proprietary extension to be read. A receiving tool can validate the file against the named view rather than against whatever the exporter happened to emit.
- Schema
- IFC4
- Length unit
- MILLI · METRE
- Area · volume unit
- SQUARE_METRE · CUBIC_METRE
Project, site, building, storey
- IfcProject
- └ IfcSite
- └ IfcBuilding
- └ IfcBuildingStorey
- └ elements
- └ IfcSpace
Elements hang off their storey with IfcRelContainedInSpatialStructure . Rooms cannot: an IfcSpace is itself a spatial element, so it extends the spine through IfcRelAggregates instead. Storey placements are relative to the building, so the storey elevation is applied exactly once.
Storeys in the sample building, parsed from its elevation sheets
Larch Annex| Storey | Elevation | Height |
|---|---|---|
| L00 | 0 mm | 4200 mm |
| L01 | 4450 mm | 3400 mm |
| L02 | 8100 mm | 3400 mm |
| L03 | 11750 mm | 3400 mm |
| L04 | 15400 mm | 3400 mm |
| L05 | 19050 mm | 3000 mm |
6 storeys reconstructed from 8 sheets, with 75 recorded assumptions travelling beside the model.
Entity, geometry, count
| Class | PredefinedType | Representation · Body | In the sample |
|---|---|---|---|
| IfcWall | SOLIDWALL | SweptSolid — the rectangle length × thickness_mm extruded to height_mm, placed on the centreline; every hosted opening subtracted with IfcOpeningElement + IfcRelVoidsElement | 72 |
| IfcDoor | DOOR · SINGLE_SWING_LEFT | SweptSolid — a box width_mm × wall thickness × height_mm sitting in its opening with the sill on the storey floor, joined by IfcRelFillsElement | 55 |
| IfcWindow | WINDOW · SINGLE_PANEL | SweptSolid — the same box lifted sill_mm above the storey floor, joined to its opening by IfcRelFillsElement | 48 |
| IfcColumn | COLUMN | SweptSolid — a circle of diameter_mm extruded height_mm upward from the storey floor at its centre | 24 |
| IfcSlab | FLOOR or ROOF | SweptSolid — the outline polygon extruded thickness_mm, top at the measured elevation when the mesh route supplies one, otherwise derived from the storey | 7 |
| IfcStair | STRAIGHT_RUN_STAIR | SweptSolid — one tread box per riser tiling the run, so the flight lands exactly on the storey above | 5 |
| IfcRoof | GABLE_ROOF | Tessellation — the pitched panels as one IfcPolygonalFaceSet sharing ridge and eave vertices, Closed = False: four panels are a shell, not a solid | none here |
| IfcSpace | SPACE · CompositionType ELEMENT | SweptSolid — the outer boundary polygon extruded height_mm from the storey floor, aggregated onto its storey with IfcRelAggregates | 54 |
Counts are instances of that entity in the committed sample, which is a flat-roofed building: it carries no IfcRoof . Pitched roofs come from the mesh route and are authored as a tessellated shell — the class is in the file format, just not in this building.
What else the file carries
- IfcProject 1
one, with the unit assignment
- IfcSite 1
one
- IfcBuilding 1
one
- IfcBuildingStorey 6
one per storey, Elevation from the elevation sheets
- IfcOpeningElement 103
one per hosted door and window
- IfcPropertySet 265
one Structura_Params per element
- IfcElementQuantity 54
one Qto_SpaceBaseQuantities per room
- IfcRelVoidsElement 103
opening cut into its host wall
- IfcRelFillsElement 103
door or window filling its opening
- IfcRelAggregates 9
site, building and the rooms on each storey
- IfcOwnerHistory none
omitted — optional in IFC4, and it would carry a wall clock
The data attached to every element
- el_id IfcText
- the element id — the key review, eval and the schedule read
- cls IfcText
- the canonical class, identical to the authored entity
- confidence IfcReal
- the detector score that decided whether the element was flagged for review
- params_json IfcText
- the element as the canonical model holds it, keys sorted — dimensions, placement, host, source sheet
- Height IfcQuantityLength
- room height in millimetres
- GrossFloorArea IfcQuantityArea
- boundary area in square metres
- NetFloorArea IfcQuantityArea
- the same polygon — omitted entirely when an interior hole was discarded, rather than overstating the room
- GrossPerimeter IfcQuantityLength
- boundary perimeter in millimetres
- GrossVolume IfcQuantityVolume
- area × height in cubic metres
{"cls":"IfcWall","confidence":96,"height_mm":4200.0,"id":"W-L00-001","kind":"ext","opening_ids":["WN-L00-001","WN-L00-002","D-L00-001","WN-L00-003","WN-L00-004"],"p1":[0.0,0.0],"p2":[30000.0,0.0],"source":"plan2d","source_sheet":"A-101 \\u00b7 Plan L00","storey":"L00","thickness_mm":240.0} The canonical record of the element as the pipeline reconstructed it — dimensions, endpoints, hosted openings, and the sheet it was read from.
One rule decides every GlobalId
Every GlobalId is a uuid5 of the building’s identity plus the element’s class, storey and quantised placement — never a random value, never a sequence number — so an element nobody edited keeps the same GlobalId across every re-export, and an element that genuinely moved gets a new one.
That rule is the difference between a model you can re-issue and a model that breaks every downstream link each time it is regenerated. It is recorded as decision D-005 and held by an automated test: the same model authored twice yields identical GlobalIds, a dimension edit keeps them, and moving a wall re-identifies that wall and nothing else. Reclassifying an element does change its GlobalId — a reclassified element is a different IFC entity type, and pretending otherwise would be the lie.
element W-L00-001 IfcWall storey L00 GlobalId 1mQsOZrUTNyQgt3jh$aBTB
- FR-7
- GUIDs stable for unedited elements across versions, verified by test.
- tests/unit/test_ifc_guid_stability.py
- Authors the same model twice, edits dimensions, then moves an element, and asserts which identifiers may change.
- Distinct GlobalIds
- 265 for 265 elements. The writer refuses to author a file at all if two elements ever collapse onto one identity.
Open the real output
The Larch Annex fixture, converted and exported by the product — not a mock-up. Every file below is regenerated by the repository’s own demo generator and is byte-identical across runs; the checksum beside each one is recorded at build time from the file this page links to.
- larch-annex.ifc Download
The IFC4 Reference View model
sha256 9a2611d9bdf5e5c7… - schedule.xlsx Download
Element schedule, Excel workbook
sha256 0f1c77e8243ee937… - schedule.csv Download
Element schedule, comma-separated
sha256 66afec4349db8ea9… - assumptions.json Download
Assumptions register — every default the pipeline applied
sha256 fddecc4b761c535a… - model.json Download
The canonical model the IFC was authored from
sha256 f5940667a9082b39… - summary.json Download
Package summary: storeys, sheets, class counts
sha256 ec7106d6401658f4…
Not yet in the file
Owner-side systems ask for four things this file does not carry yet. They are named here rather than discovered during a handover. Each is roadmap: no date, no commitment, and nothing on this page counts it as shipped.
-
IFC type objects
RoadmapEvery element is authored as an occurrence. There is no type layer, so a receiving tool cannot group occurrences by a shared type definition or attach type-level properties.
IfcWallType · IfcDoorType · IfcTypeObject
-
Standard Pset_*Common property sets
RoadmapThe model data travels in one custom set, with the full element record inside a JSON string. A mapping file in an asset-management system cannot address fields inside that string; the standard common sets it does know are not written.
Pset_WallCommon and family
-
Classification references
RoadmapNo classification system is attached to any element, so a specification that requires a classified model has to add it downstream.
IfcClassification · IfcClassificationReference
-
COBie handover
RoadmapStoreys and rooms exist in the model, but there is no COBie export and no type or contact layer to build one from.
Facility and Floor exist; Space, Type and Contact do not