This file came first. Before the benchmark series. Before the validation pipeline was complete. A real residential reinforced concrete frame in Kenya — submitted while the extraction engine was still being built.
The first delivery failed.
StructBOQ steel — 20,906 kg · Correct steel — 2,409 kg · Error — 767%
The issue was not missing data. The data was fully present in the IFC. The system simply did not read it. Every validation method documented in studies 01–06 — rebar geometry extraction, layer decomposition, BASESLAB reclassification, NetVolume policy — was built in direct response to what went wrong here.
- 1,484 total IFC elements
- 209 concrete structural elements
- 122.801 m³ validated concrete volume
- 91 columns — 2 section types, 2 height variants
- 52 beams — 3 types
- 41 pad footings — IfcSlab exported as BASESLAB
- 18 strip footings — no BaseQuantities
- 4 concrete slabs — incl. 3-layer ground floor
- 2 stair flights with landings
- 18 masonry walls — excluded
- 1,252 IfcReinforcingBar — fully modeled rebar system
The rebar model was complete. Every bar individually modeled. Not one diameter missing. Not one length absent. 1,252 IfcReinforcingBar elements. NominalDiameter present. BarLength present. CrossSectionArea present on all 1,252.
The initial engine defaulted to concrete volume ratio method because rebar extraction was not implemented. The data was present. The extraction path was not. Correct computation — CrossSectionArea × BarLength × 7850 kg/m³ per bar.
| Bar Type | Count | Mass |
|---|---|---|
| T8 | 457 bars | 348.47 kg |
| T10 | 657 bars | 1,572.51 kg |
| T12 | 114 bars | 242.33 kg |
| T16 | 24 bars | 246.54 kg |
| Total — all 1,252 bars | 2,409.84 kg |
Ground floor slab — Floor: 150mm Solid Slab With A142 Mesh. IFC NetVolume — 60.2249 m³. Actual build-up — 100mm concrete structural, 50mm sand blinding, 300mm earth subgrade. Total modeled thickness — 450mm. The entire 450mm was interpreted as concrete.
46.842 m³ of sand and earth incorrectly priced as concrete from one slab. One family. One unchecked assumption. This pattern appears in residential construction worldwide. Any ground floor family modeled with blinding, sand, or subgrade layers carries this risk. The engine now detects IfcMaterialLayerSetUsage, identifies the structural concrete layer, and extracts only that layer's volume.
18 strip footings. No BaseQuantities exported. This is a known Revit IFC exporter limitation — foundation elements do not receive BaseQuantities regardless of export settings. Initial engine applied uniform defaults — 4.00m length, 0.60m width, 0.30m depth — to all 18 elements identically.
The geometry was in the file. It was being ignored entirely. IfcExtrudedAreaSolid representations present on every footing. Lengths ranging from 0.049m connector pieces to 18.275m perimeter runs. Some footings with up to 11 separate extrusion segments. Element name says 600×200mm Strip Footing — engine was applying default depth of 300mm. Wrong by 50%.
41 pad footings exported as IfcSlab with PredefinedType BASESLAB. The Revit modeler used the Floor category instead of the Footing category. When exported, Revit assigned the slab class.
Two distinct sizes confirmed by script. B1 — 9 elements — 1200×1200×300mm — 0.432 m³ each. B2 — 32 elements — 1000×1000×300mm — 0.300 m³ each. PredefinedType combined with name-based override reclassified all 41 to footing before any steel ratio or cost logic was applied. This pattern repeats across multiple Revit datasets. It is not a Revit bug. It is a modeling practice. The detection must be in the engine.
Multiple elements show corrupted GrossVolume. BASESLAB B1 — GrossVolume 432.0 m³, NetVolume 0.432 m³ — factor of 1000. Spandrel beams — GrossVolume mismatch approximately 260×. NetVolume is consistent across all affected elements. GrossVolume is unreliable in specific IFC2X3 Revit exports.
This is a systematic export bug, not a modeling error. NetVolume used exclusively throughout. GrossVolume ignored unless cross-validated against geometry. Any workflow that defaults to GrossVolume on IFC2X3 Revit files carries this risk silently — no warning is issued and the corrupted number looks plausible.
Full re-analysis after first delivery failure. Every element, assumption, and extraction path reviewed. 209 concrete elements validated in Bonsai/BlenderBIM. 1,252 bars extracted by individual geometry.
These are the actual StructBOQ outputs generated from this IFC file. No data has been modified. Cost figures use default rates (€120/m³ concrete, €1.2/kg steel) and are indicative only — not market rates. Download and open to inspect the full element-level breakdown, confidence scoring, and validation findings.
Generated by StructBOQ v3.3 · shabirbim.com · Outputs are unmodified engine results
18 strip footings extracted from IFC geometry due to missing BaseQuantities. Confidence 85%. Verify against structural drawings before procurement.
One ground beam — GBM:1818908 — had NetVolume = 0.0. Volume reconstructed from Pset length and name-parsed dimensions. Confidence 70%. Verify against structural drawings.
Steel quantities are exact for all 1,252 modeled bars. No estimation applied.
The failure was not data absence. It was unread data. 1,252 bars fully modeled but ignored. 46.842 m³ of non-structural layers counted as concrete. Strip footings replaced by uniform assumptions. Pad footings accepted under the wrong IFC class. GrossVolume trusted where it should not have been.
Nothing failed visibly. Everything looked correct. The BOQ was wrong anyway.
IFC errors are rarely missing data problems. They are detection and interpretation failures. And in real delivery environments, speed of correction matters as much as correctness itself — because wrong numbers that arrive confidently still become decisions.