One scan, turned into measurements and evidence a reviewer signs off on

LiDAR capture is designed to slot into one continuous chain rather than exist as a separate scanning feature bolted on to the side. A scan starts at the property and ends up, several linked steps later, inside a reviewed, priced, approved case file — the same destination every measurement and every piece of evidence in PaxExact reaches by other means.

Part of this chain runs today. A scan made in another app can be uploaded to a room, PaxExact derives proposed dimensions from it on the server, and once a reviewer accepts them they flow into the room's measurements, scope and line items like any other accepted measurement. What is not built is the capture step itself: there is no PaxExact mobile app, so the scan has to come from a separate scanning app, and video is stored but not yet used.

The LiDAR scanners in recent iPad Pro and iPhone Pro models are short-range depth sensors: Apple introduced the iPad Pro's scanner as effective up to about 5 meters, and it's built for a room, not a landscape. The first iPhone to carry one was the iPhone 12 Pro; non-Pro iPhone models don't have one, which already narrows which devices a scan can come from.

Apple's RoomPlan technology, built on ARKit, is the closest existing example of what phone LiDAR can output today: not a raw point cloud, but a parametric room model — walls, doors, windows, openings, and furniture as distinct, labeled elements, each carrying its own confidence, exportable as a USDZ file. That's a meaningfully different output than a dumb mesh: elements a system can reason about individually, not just an undifferentiated cloud of points. PaxExact reads that parametric model only from RoomPlan's CapturedRoom JSON export; any USDZ file is read only as a raw mesh for its overall dimensions, and only if its root layer is text.

RoomPlan also comes with real limits Apple documents itself: it's built around a single room up to roughly 30 by 30 feet, it needs reasonably lit conditions (Apple specifies at least 50 lux), and mirrors, glass, and very dark surfaces are known to cause problems. None of that is a PaxExact limitation — it's the boundary of what this class of consumer hardware and software does today, and any scan PaxExact imports inherits it.

It's also worth being plain about device coverage: there's no mainstream Android equivalent to iPhone and iPad LiDAR today. Android's ARCore Depth API mostly estimates depth in software from ordinary camera motion, merging in a real time-of-flight sensor only on the handful of devices that have one — a short, largely legacy list. Treat LiDAR-based capture as an iPhone/iPad-Pro-class capability first.

A capture device never gets the final word on a dimension. The uploaded scan file is retained as evidence, and PaxExact's server derives dimensions from that retained file itself rather than trusting a figure the scanning app reported — the same server-authoritative approach measurement uses for room and floor figures. A derived dimension is a proposal; it becomes part of the record only when a reviewer accepts it.

Every derived measurement carries the same accept/reject review state that governs every other measurement in PaxExact — a scanned dimension is not exempt from a professional's review just because a machine produced it instead of a person typing a figure. A RoomPlan export carries a confidence level per element, and that confidence stays with the proposal. A USDZ scan (text-layer only) is read as a raw mesh with no confidence signal, so PaxExact derives only its overall bounding dimensions and says plainly that they describe the whole capture, not a detected room.

Openings — doors, windows, the same fixtures a hand-measured wall already accounts for — are meant to be deducted explicitly, as their own recorded facts, rather than folded invisibly into a net figure. A RoomPlan scan already records each opening's width and height as its own proposed measurement; deducting them from wall area is the in-development net wall area work and does not happen yet.

Photos already attach to a specific room and a specific damage record in PaxExact today, and spatial capture keeps that same discipline: an uploaded scan is evidence on a specific captured room, and every dimension derived from it cites that exact scan file, rather than living in a scan folder next to unrelated photos.

Video is part of the same model but only partly built: a video file can be uploaded and stored as evidence on a room today, and nothing is extracted from it yet — AI analysis is photo-only. When video processing ships, the same rule applies as everywhere else in PaxExact's evidence chain — video tied to a specific room or element, not a loose file with no anchor.

LiDAR and spatial capture is built to be an addition, not a replacement. Manual measurement — the web-based, accept/reject-reviewed workflow that's live today — stays first-class whether or not an estimator ever touches this module. An estimate produced entirely by hand and one that started from a scan are meant to look identical once they're both through review: the same measurement record shape, the same evidence links, the same approval gate.

An estimator working primarily indoors on simple, regularly shaped rooms, without a LiDAR-equipped device, or who's simply comfortable with a tape measure and the existing web workflow, loses nothing by skipping this module. It's designed for the opposite case: field estimators covering many properties, or teams for whom capture speed and consistency across a large volume of rooms is worth the added device requirement.

Two formats are accepted today, in beta: Apple RoomPlan's CapturedRoom JSON export, and USDZ files whose root layer is text (.usda), which are read only as a raw mesh; binary USDZ is not supported yet. Beyond those, no format commitment has been made. PLY, E57, and glTF are candidates under consideration for retained geometry and exportable models — PLY and E57 because they're established point-cloud and scan-data formats used well beyond consumer phones, and glTF because it's a widely supported format for transmitting 3D models. Naming them here is a statement of what's being evaluated, not a commitment to ship support for any of them, or on any particular date.