The first lesson in this module drew a boundary: IDS checks whether specified information is present, correctly typed, and correctly located. It does not check what happens to that data once its presence is confirmed. Every lesson since has built toward showing that boundary in full, on one real file, checked completely. This is that walkthrough.
A real Revit 2021 IFC2X3 structural project, 1,484 elements. Ten IDS specifications were run against it, covering rebar attribute presence, element naming across four categories, column material, column spatial placement, and footing quantities.
| Specification | Elements Checked | Result |
|---|---|---|
| Rebar NominalDiameter | 1,252 | 1,252 PASS |
| Rebar CrossSectionArea | 1,252 | 1,252 PASS |
| Rebar BarLength in Pset | 1,252 | 0 PASS |
| Column Name | 91 | 91 PASS |
| Column Material C25 | 91 | 0 PASS |
| Column PartOf Storey | 91 | 91 PASS |
| Beam Name | 52 | 52 PASS |
| Slab Name | 46 | 46 PASS |
| Footing Name | 18 | 18 PASS |
| Footing NetVolume | 18 | 0 PASS |
Seven of ten pass completely. Three fail completely, zero partial results anywhere in the run.
Two of these three are patterns already covered in this module, and reading them correctly here means recognising the pattern rather than re-diagnosing it from scratch. The BarLength failure is the Property-facet location error from the third lesson: in this IFC2X3 file, BarLength is a direct Attribute on IfcReinforcingBar, not a Property inside Pset_ReinforcingBarCommon. The specification was structurally correct and still returned zero, because it checked the wrong place. The Material failure is the exact-string-match case from the second lesson: the file's real value carries a dash, "Concrete, Cast-in-Place - C25", the specification's value doesn't, and IDS's exact-match design turns one character into a complete failure. Neither of these means the model is broken. Both mean the specifications, as written, don't match where or how this particular file's data is actually structured.
The third failure is different, and it's the one true positive in this run. Every one of the 18 footings in this file carries zero Base Quantities, NetVolume included. This is a documented Revit IFC2X3 exporter behaviour: foundation-level elements have historically not received quantity data through this export path regardless of export settings. Here, IDS is doing exactly what it exists to do. It found a real absence, forced it into view, and gave whoever produced this file a concrete, specific thing to fix in their export configuration.
This is the section the rest of the module has been building toward. All 1,252 reinforcing bars in this file carry a NominalDiameter. All 1,252 carry a CrossSectionArea. Both specifications pass completely, at full scale, across the entire rebar population in the file. By every measure this module has covered, this file's rebar data is IDS-compliant. Presence: confirmed. Correct type: confirmed. Correct location: confirmed, on both counts that were checked.
A separate, real reading of that same file's steel content, downstream of these checks, reported a total of 20,906 kg. The corrected figure, traced back through the same file's data, was 2,409.84 kg. A 767% error, on data that had just passed both rebar presence checks completely, at full population, with nothing partial about either result. Not because a diameter was missing. Not because a value was malformed. The data behind every bar was exactly where it needed to be, exactly the type it needed to be. What went wrong happened after presence was already confirmed, in how that confirmed, correctly-typed data was actually used to arrive at a number.
Ten specifications, three failures, seven passes, and the single largest error connected to this file's rebar data, a 767% steel total error, doesn't appear anywhere in this table at all. That's not a gap in how the specifications were written. Every one of the ten did precisely what an IDS specification is built to do: check presence, type, and location, and report accurately on all three. The NominalDiameter and CrossSectionArea checks didn't fail to catch a downstream error. They were never designed to look for one. Checking whether a confirmed, correctly-typed, correctly-located value gets used correctly afterward is a different question entirely, one this whole module has been naming as IDS's boundary since its first lesson, and this run is that boundary made concrete, on one real file, checked in full.
Comments use a free GitHub account — takes under a minute to create, and keeps discussions spam-free and permanently archived.