Recall, precision and correctness: the three numbers a BIM model from a scan needs

We score every model our pipeline produces with three numbers, and we publish all three because any one of them alone will mislead you. This article defines them precisely, shows with real figures how two of them can be perfect while the model is wrong, and gives you the recipe to compute them on your own building.

The setup: a reference, and pairs

Scoring needs a reference model: an independent model of the same building, usually a surveyor’s hand-modelled IFC from the same scan. Both models are lists of elements with a class (window, door, wall) and a box in the facade’s frame: a centre (u along the facade, v up, w out of the plane) and a size (width, height, depth).

Scoring begins by pairing: for each reference element, find the generated element of the same class that best overlaps it. We pair when the overlap of the two boxes projected onto the facade plane is at least 0.20 (intersection over union), or, for slender elements such as mullions where overlap is unstable, when the centres are close. Each element pairs at most once.

After pairing, every element is in one of three states: paired, unpaired reference (a miss), or unpaired generated (a false positive). The three scores follow from those states.

Recall: did we find it?

On the reference building, the reference has 96 windows; our run paired 77 of them. Recall 0.80. The 19 unpaired windows are misses, and on this facade they are mostly the ones behind the loggia screens, where the scan shows a louvred screen instead of the opening behind it.

Recall answers “how much of the building is in the model”. It is the number to look at first, because a missed element is one the reviewer has to draw from scratch, which is the most expensive kind of correction.

Precision: is what we found real?

Our run generated 78 windows; 77 paired. Precision 0.99. The one unpaired window is a false positive: something taken for a window that the surveyor did not model. It costs the reviewer one rejection.

Recall and precision trade against each other. A reader that draws a box on every dark rectangle will have high recall and low precision; one that only draws what it is sure of, the reverse. Our reader is tuned towards precision, on the principle that a reviewer deletes a false positive in one keystroke but must draw a miss by hand.

Correctness: is it in the right place, at the right size?

This is the number the first two do not contain. A paired window has, by construction, some overlap with the reference; it can still be 15 cm too tall or 20 cm too deep. Correctness asks each paired element four questions and takes the worst answer.

On the same run: 1 of 77 paired windows is correct at 10 cm; 0 at 5 cm. The median errors tell you why: u 0.6 cm, v 2.0 cm, size 8 cm, w 20 cm. Three axes pass; the fourth, depth, fails on every window because this version of the pipeline emits a placeholder depth. Correctness caught that, and neither recall nor precision could have.

The proof that two numbers are not enough

On a sister building of the same estate (188 reference windows) the current engine finds almost everything and says so per element, which is what we publish:

Doors at 1.00 and 1.00, windows at 0.99 and 0.94: by the two usual numbers, a near-perfect model. That is exactly why the third question matters — and why, having asked it of ourselves, we now decline to answer it with a single figure. A correctness share depends on the reference it is measured against, and on that building we have one reference, of one typology. What we publish instead is the median error on each axis, named to that building, so you can see that the openings are where we say and that the depth is a declared prior. The Accuracy page carries both

The four errors, and what each one tells you

Correctness is a threshold on the worst axis; the medians per axis are the diagnosis. On our current run:

A worked pairing, by hand

Take one window. The reference has it at u = 12.40 m, v = 4.85 m (centre), 1.20 m wide, 1.40 m tall, at a reveal depth of 0.18 m. The generated model has a window at u = 12.41, v = 4.83, 1.18 wide, 1.44 tall, at w = 0.10 (the placeholder).

1. Pair? Both are windows. In the u–v plane the two boxes overlap almost entirely: intersection about 1.60 m², union about 1.74 m², IoU 0.92, well above 0.20. Paired.
2. Errors. |Δu| = 1 cm. |Δv| = 2 cm. Size: |Δwidth| = 2 cm, |Δheight| = 4 cm, so |Δsize| = 4 cm. |Δw| = 8 cm.
3. Worst axis. 8 cm, the depth.
4. Verdict. Correct at 10 cm: yes. Correct at 5 cm: no, because of the depth.

Now imagine the same window with the placeholder depth 20 cm off, which is the median on our run: worst axis 20 cm, not correct at 10 cm either, while the three in-plane errors are unchanged at 1, 2 and 4 cm. That is the whole story of the current table in one window, and it is why we report the medians alongside the threshold.

Why 0.20 IoU, and why one-to-one

The pairing threshold is deliberately loose. A generated window that is 15 cm off in position and 20 % too small still overlaps its reference at about 0.5 IoU, and we want it paired, because a paired-but-wrong element is the useful diagnosis: the thing is there, fix its size. A tight threshold (0.5 and above) would turn placement errors into misses and make recall look worse for the wrong reason. The correctness stage then applies the strict test to the pairs.

One-to-one matters for the opposite reason. If two generated boxes overlap one reference window (a window and its blind were drawn as two openings), only one can pair; the other is a false positive and costs precision, which is what a duplicate should cost.

What correctness does not measure

Correctness scores paired elements only. It says nothing about the 19 missed windows (recall does) or the one false positive (precision does). It also treats every paired element equally: a window 11 cm off and one 90 cm off both fail at 10 cm. For that reason we publish the medians as well, and for a specification we suggest reading the three numbers as three questions: is it all there, is it all real, is it all right.

Compute it on your own building

You need your scan, a model from it made independently (your own surveyor’s, or one you commission for one facade), and both models’ elements as boxes in the same frame. Then:

1. Export both models’ windows, doors and walls with their bounding boxes. From IFC, a geometry library gives you world-space boxes; project them into the facade plane’s frame so u, v and w mean the same thing in both.
2. Pair by IoU ≥ 0.20 in the u–v plane, one-to-one, same class only.
3. For each pair, compute |Δu|, |Δv|, |Δsize| (max of width and height differences) and |Δw|. The element is correct at T if the largest of the four is ≤ T.
4. Report per class: counts, recall, precision, correct at 5 and 10 cm, and the four medians.

Our engine does this when a reference IFC is attached to a run (through the API today), and prints the same table we publish. The point of the recipe is that you can check us.

The first figures are the engine’s scoring of 10 September 2026 on the reference building, kept because this article walks through that run; the sister-building table is the engine of 13 September 2026. Current values on the Accuracy page.