Coverage

How much of a real IFC model goifc tessellates, and how loose its bounds are against IfcOpenShell. Measured against the public corpus only (parity.Public). Generated by make parity-report — do not edit by hand.

The OBB rate is the number with real signal: it is the share of elements that produced geometry but fell back to a bounding box instead of a tessellated shape. The looseness columns compare goifc's world AABB to IfcOpenShell's world AABB — not to the true solid, which the oracle does not store. Those two boxes are near-identical for any element both engines tessellate. For one that fell back to goifc's own OBB path, the box is built from the IfcCartesianPoint coordinates reachable from the element's representation, so it coincides with the true solid's world AABB only where those points reach the solid's extremes. Where they do not — a revolved or otherwise curved sweep has extremes that no point in the file names — the fallback box can come out either looser than the true solid (a pitched roof's OBB can hold twice its volume) or, the failure that actually hurts a consumer, tighter than it. Gate 1 is precisely what catches the tighter case — and an under-reporting bound wherever else one arises. All 2 of the shortfalls recorded below are Gate 1 firing on a different cause, not on a fallback box: those elements tessellate through the extrusion path, and parity/knownviolations.go attributes their shortfall to how goifc bounds a stepped solid along that path. (IfcOpenShell has no OBB fallback of its own — its oracle boxes come from an exact-solid tessellation.) So a ratio of 1.00 here is nearly blind to fallback quality by construction — read it as "box vs. box", not as "goifc matches IfcOpenShell". Ratios are printed to four decimal places so "exactly 1" and "very close to 1" are distinguishable. Collapsed is elements excluded from the ratio columns because goifc's own box has zero volume — flat, inverted, or empty. Their ratio would be exactly 0, a well-formed number for the worst possible outcome, which would drag p50 and p90 toward 1.0 and read as an improvement. Gate 1 fails on them; this column is here so the page cannot quietly disagree with the gate.

Model	Elements	Extrude	Brep	OBB	Empty	OBB rate	Collapsed	AABB ratio p50	p90	max
ifcopenhouse	40	34	0	0	6	0.0%	0	1.0000	1.0000	1.0000
duplex_a	218	146	0	69	3	32.1%	0	1.0000	1.0000	1.1156
fzk_haus	85	16	64	2	3	2.4%	0	1.0000	1.0000	1.0334

What falls back, and how often

Representation-item types that have no tessellation path at all. Closing the top of this list buys the most accuracy.

Counts are OCCURRENCES, not distinct entities: an IfcMappedItem is resolved to the items it maps, and each resolution is counted again — once per element that reaches it. A family placed many times via one IfcRepresentationMap costs accuracy every time it is placed, so it must rank every time, not once. This means a type's count can legitimately exceed the number of entities of that type in the file. Keys are the upper-case STEP keyword as parsed (IFCFACEBASEDSURFACEMODEL, not IfcFaceBasedSurfaceModel); nothing here changes that casing.

Occurrences here and the OBB column above are different quantities, and neither converts into the other. This table counts representation ITEMS, once per element that reaches one; the OBB column counts ELEMENTS. Two different units: where a model's two figures land close together that is coincidence, not agreement. Do not subtract them.

This list is also not exhaustive of what falls back. It names only types that tessellateItemDepth has no case for at all, looking through the two wrappers that would otherwise hide one — an IfcMappedItem is resolved to the items it maps, and a boolean to its operands. An element becomes a box just as readily when a dispatched path IS attempted and declines partway: an extrusion whose profile cannot be built, a brep whose shell cannot be closed. None of that class appears here. Nor do presentation entities (IfcStyledItem and the like), which this diagnostic excludes as appearance rather than shape so a colour assignment cannot outrank a missing solid — they still reach the same fallback, so if one ever does yield a box this list will not name it either. So a type's absence from this table is not evidence that it never falls back, and the counts below are a lower bound on the causes.

In this corpus, every model that has a fallback element also reports at least one unhandled item type below.

Item type	Occurrences
IFCFACEBASEDSURFACEMODEL	65
IFCPOLYGONALBOUNDEDHALFSPACE	11

Known Gate 1 violations

Gate 1 asserts that goifc's AABB contains IfcOpenShell's oracle box for every element the oracle and goifc's scene both know. A bound that under-reports is always a bug, never a legitimate fallback — an OBB fallback box is allowed to be larger than the solid it stands for, never smaller. The violations below are real, currently open goifc geometry gaps, tracked in parity/knownviolations.go's knownViolations allowlist so CI stays green on this known state while still failing on any new or worsened violation.

Across the public corpus the gate compares 331 elements, of which 329 are contained.

Against ifcopenhouse, the gate compares 34 elements, and all 34 are contained.

Against duplex_a, the gate compares 215 elements. 213 are contained; 2 are not:

GlobalID	Axis	Shortfall	What it is
1oKjKg9PD3fP1iIwXLh3lK	min-y	0.009927508 m	IfcStairFlight, Revit instance 151086 of "Stair:Residential - 200mm Max Riser 250mm Tread" (16 risers / 15 treads)
3KMJUyUe9DfQ2FOCd5ZoiN	max-y	0.009927222 m	IfcStairFlight, Revit instance 198878 of "Stair:Residential - 200mm Max Riser 250mm Tread" (16 risers / 15 treads)

Against fzk_haus, the gate compares 82 elements, and all 82 are contained.