From Messy LiDAR to Building Intelligence

When we started building the scanner, the first story was simple: use RoomPlan, capture a room, and get walls, windows, doors, floors, and measurements. That works well for clean rectangular rooms. It does not fully solve real building geometry.

Homes are full of awkward realities: sloped ceilings, bay windows, partial walls, fragmented LiDAR patches, curved geometry, floors over garages, below-grade boundaries, and multiple scan passes that need to become one building-level picture. The hard part was not just detecting surfaces. The hard part was deciding what those surfaces mean.

Our answer was the canonical building graph.

Do not choose between RoomPlan and mesh

A tempting architecture is to pick one geometry source as the truth. We rejected that.

• RoomPlan gives clean semantic structure: walls, openings, room bounds, and a field-friendly scaffold.
• ARKit mesh gives observed physical evidence: irregular surfaces, sloped planes, true surface area, and coverage signals.

Choosing only RoomPlan would make the system too clean and brittle. Choosing only raw mesh would make it too noisy and hard to use. So we separated responsibilities:

That changed the core question from "which source is right?" to something more useful: what did RoomPlan believe, what did the mesh observe, where do they agree, where do they disagree, and how much of that disagreement should be review-gated before downstream use?

The geometry pipeline

The pipeline now behaves like a layered evidence system rather than a one-shot geometry export:

1. Capture ARKit LiDAR mesh.
2. Group mesh faces into raw surface nodes.
3. Consolidate fragmented coplanar patches into logical surfaces.
4. Associate RoomPlan semantic surfaces with mesh evidence.
5. Build a per-scan BuildingGraph.
6. Run envelope reasoning and classification.
7. Reconcile aligned scan passes into a CanonicalBuildingGraph.
8. Feed measurement, CAD, and thermal systems with selected areas, confidence, and warnings.
9. Export a normalized building intelligence package.

The important engineering choice was to keep those layers separate. Raw mesh extraction should not know about F280 readiness. The measurement resolver should not be responsible for scan-pass alignment. CAD should not be guessing which patch is a foundation wall.

Surface consolidation: simplify noise, preserve information

Raw LiDAR mesh often splits one wall into several disconnected or slightly offset patches. If we expose those directly, users see fragments instead of building components.

The surface consolidation step merges likely fragments by looking at surface type, confidence, planarity, normal agreement, plane offset, bounds gap, centroid distance, and minimum merged area.

That gives us the practical rule we wanted: merge fragmented coplanar walls, but do not flatten sloped or irregular geometry just because it is nearby. A fragmented wall is noise. A sloped ceiling is information.

The per-scan building graph

After consolidation, we build a scan-level BuildingGraph. This layer answers a local question: what did this scan pass actually see?

• Rooms and stories.
• Boundaries and openings.
• Volume estimates and mesh associations.
• Unresolved mesh evidence.
• Unresolved semantic evidence.

One of the most important details is that unmatched evidence is not thrown away. If RoomPlan saw a door we could not confidently match, it stays as unresolved semantic evidence. If mesh saw a strong architectural surface that RoomPlan did not explain, it remains available for review and, in some cases, careful promotion into synthetic boundary evidence.

The canonical building graph

The canonical graph is where scan evidence becomes building memory. Real workflows are not always one perfect continuous scan. Buildings may need separate passes for the main floor, basement, garage, attic, mechanical room, or a selected zone.

The canonical graph reconciles aligned passes into stable entities for stories, spaces, surfaces, openings, and volumes. Each entity carries provenance, confidence, confidence history, source scan pass IDs, bounds, conflicts, and unresolved evidence.

That provenance model is the difference between a demo and a system we can build on. If later evidence reinforces a wall, confidence should increase and the history should record why. If evidence conflicts, the system should record a conflict instead of silently merging.

Make geometry quality visible

One lesson from this work is that geometry systems need health reporting, not just output. A geometry truth report lets the app say things like:

• 12 raw mesh fragments were consolidated into 4 logical surfaces.
• 3 logical surfaces remain review-gated because they are weak, sloped, irregular, or low confidence.
• Completion patches need assessor review before compliance-style use.
• Sloped or irregular surfaces were preserved and should not be flattened automatically.

That language matters. The goal is not to produce a magical number from a scan. The goal is to produce measurement evidence with enough transparency that an advisor, engineer, or CAD reviewer can trust the process.

Measurement resolution and envelope classification

For load workflows, we eventually need an area. But we do not want to collapse the evidence too early. The measurement resolver keeps RoomPlan area, observed mesh area, selected load area, source strategy, confidence, warning codes, and canonical links together.

That lets the system do the right thing for irregular homes. If mesh is strong and materially different, true surface area can win. If mesh evidence is weak or partial, the system can fall back to RoomPlan and explain that fallback.

The same principle applies to classification. A surface graph can say something is wall-like or floor-like. An auditor needs more: above-grade exterior wall, partition, foundation wall, exposed floor, sloped ceiling candidate, attic boundary, or review required.

Why the inspector and CAD layer matter

A canonical graph is only useful if someone can inspect it. The evidence inspector organizes surfaces, spaces, openings, conflicts, and unresolved evidence by priority and confidence, so users can review logical building components first and drill into raw evidence only when needed.

That is also why the downstream contract matters. CAD should not reverse-engineer iOS scan logic. It should receive stable IDs, geometry kind, canonical entity links, bounds, centroid, normals, selected load area, confidence, review state, warnings, and provenance notes directly from the building intelligence package.

What comes next

The canonical graph gives us the foundation. The next work is about making it more auditor-ready across whole-home workflows:

• A fuller envelope classification matrix for walls, roofs, floors, and foundations.
• Opening schedules with host links, orientation, and thermal assignment.
• Grade and foundation resolution for slab, basement, crawlspace, and walkout conditions.
• Whole-home scan scopes for floors, zones, additions, and review-only passes.
• Richer CAD and evidence inspection with round-trip-friendly metadata.

What this means for the product

This architecture changes the scanner from a room capture tool into a building intelligence system. That does not mean the app should claim final compliance or fully autonomous takeoff. It should not.

The honest language is preliminary F280-ready building and load evidence. That framing leaves room for ambition without overstating certainty. It says the workflow is scan-derived, evidence-backed, useful for early load work, structured for review, and still respectful of final professional judgment.

We did not solve complex building geometry by pretending homes are simple. We solved it by building a system that can carry multiple kinds of truth at once, reconcile them carefully, and explain its reasoning all the way down to exported CAD metadata.