How to review an AI-generated BIM model in an hour

A model that a machine proposed is not a model until a person has looked at it. The question is how to look at it efficiently: a hundred elements checked one by one against a point cloud is an afternoon, and most of that afternoon is spent confirming things that were obviously right. This is the procedure we use and built the review panel around. It gets a regular facade through review in about an hour, with the attention going where the errors are.

Before you start: read the run’s report

Every run produces a summary before you open a single element. Three lines in it decide how long the review will take:

• How many elements were proposed, by class. Ninety-six on our example facade: 78 windows, 3 doors, 12 vents, 3 unclassified openings.
• How many could not be measured. Eighteen of 83 windows on the example, all flagged with a reason: “no recess evidence” (the bay is behind a screen) or “dimension change too large” (the depth cue merged neighbours). Those are your first stop.
• What the pipeline did not attempt. Railings, cornices, canopies. If the client needs them, they are drawn from scratch and you should know that before promising a time.

A facade with 20 % unfitted elements reviews in an hour. One with 45 %, which is what a heavily screened building gives, takes two, and the report tells you which one you have.

Step 1: the unfitted elements, one by one

Filter the list to the elements that could not be measured. Each carries its box, its confidence, and the reason nothing was measured, abstained. Select one; the viewer frames it in the cloud. Two things to check:

1. Is there an opening there at all? Behind a louvred screen, usually yes; the rhythm of the row was still legible even if the scan showed a louvre. Accept, or edit the height if the cloud shows the head clearly.
2. Is the height plausible? Heights are the weak axis. Compare with the fitted neighbour on the same storey; on a regular facade they should match within a few centimetres. Edit if not: the edit form takes the six numbers of the box in metres, and the viewer shows the change as a wireframe before you save.

This step is where most of the review time goes and where most of the corrections happen. On the example it is 18 elements.

Step 2: low confidence, whatever the fit verdict

Sort or filter by confidence and look at anything under 60 %. Low confidence goes to what could not be named (kind “other”), to openings at the edges of what was read, and to shapes it half-saw through vegetation. These are the false positives and the misclassifications: a shadow read as a vent, a panelled bay read as glazed. Reject or reclassify. On the example, the one false-positive window and the three unclassified openings are here.

Step 3: the missing ones

Now walk the elevation view of the facade with the cloud on and the model over it, storey by storey. What you are looking for is an opening in the cloud with no box on it. On the example, 19 windows were missed, and they are visible in the cloud as openings with no box. Draw each as a new element, using the neighbour’s dimensions as the starting box. This is the only step that adds elements rather than judging them, and it is the one an automatic tool cannot do for you.

Step 4: the regular ones, in bulk

What is left is the majority: fitted elements with high confidence, in regular rows, matching their neighbours. Filter to “proposed, fitted, confidence above 80 %”, scan the list once for anything odd, and accept the whole filtered list in one action. The panel asks for confirmation because it is about to mark seventy elements; that is the point, and it is why the earlier steps come first. Bulk-accepting before you have looked at the unfitted ones would accept the errors along with the rest.

Step 5: depth, if it matters for the purpose

In the current engine, every opening is emitted at a placeholder depth. For an energy calculation or an elevation drawing that does not matter; for a facade replacement quote it does. If depth matters, the edit form’s w and depth fields take the depth as measured from your cloud. Do it for one window per type and copy the value; reveals on a housing block are uniform to a centimetre.

Generate the reviewed model

When the last proposed element has a decision, generate the reviewed IFC. It is built from your decisions: rejected elements are left out, edited elements take your dimensions, accepted elements are as proposed, added elements are yours. Two things are worth knowing about the file:

• The GUIDs are the same as the proposal’s. An element’s identifier is derived from the run and the element’s position, not from the review, so anything that linked to the proposed element (an issue in a BCF file, a comment, a schedule row) still resolves.
• The proposal stays. The proposed IFC remains as its own deliverable, so the difference between what the machine said and what you delivered is auditable.

Change your mind later and generate again; it is free and produces a new generation of the reviewed file.

Reviewing as a team

On a campaign, one person runs the pipeline and several review. Two things make that work without stepping on each other. First, every decision is an event with a user and a time, and the counts update live for everyone looking at the same run, so two reviewers filtering by class (one on windows, one on doors and vents) do not collide. Second, the bulk action is the only way to change many elements at once, and it asks for confirmation naming the count, so a colleague cannot accept your half of the list by accident.

For a review that a second person signs off, the procedure above has a natural checkpoint: after step 4, everything is accepted, rejected or edited, and the run’s counts show it. The signer looks at the edited and added elements, which are the ones a human authored, and at the rejections, which are the ones a human overruled the machine on. Everything else was measured and accepted in bulk, and the record says so.

What the review record is for

Every accept, reject and edit is stored with its author and timestamp, and the reviewed IFC is generated from that record, not from a mutable model file. Three things follow.

• Audit. A checker can ask, for any element, whether the geometry was measured or came from a person, and if a person, who and when.
• Revision. Change one decision and regenerate; the new file is a new generation with the same identifiers. The previous generation stays downloadable.
• Learning. The set of elements people rejected or edited, across runs, is the most useful data the pipeline has about its own errors. That is how the vent kind, the panelled-bay rule and when to abstain were found: from what reviewers changed.

Keyboard, not mouse

A review of a hundred elements is a hundred decisions, and each one should cost one keystroke. In the panel: A accepts the selected element, R rejects it, E opens the edit form, J jumps to the next proposed element. With the list filtered to the elements that need attention, the loop is: look at the viewer, press a key, the next one is framed. The bulk action handles the rest.

What a good review leaves behind

A reviewed model, a proposal to compare it with, and a record of every decision with who made it and when. If the client’s checker asks why window 43 is 1.20 m wide, the answer is: AutoIFC measured it at 1.20 from your cloud, the reviewer accepted it on 11 September, and here is the evidence. That is a stronger answer than any hand-drawn model can give, and it costs nothing extra: the decisions are recorded as you make them.

Counts and figures are from the AutoIFC engine’s run of 10 September 2026 on the reference building. The procedure is what the review panel was designed for; see the Features page.