PROPERTYSCAN
The cost of a property inspection is the inspector's visit. PropertyScan removes the visit. The tenant becomes the camera operator under a fail-closed capture protocol: the app refuses to advance until every acquisition invariant is met.
2026.03 · RESEARCH PROTOTYPE · iOS + CLOUD
A standard property inspection requires an in-person human visit. The visit is the cost: scheduling, travel, hourly rate, the scarce calendar of a certified surveyor. Everything downstream of the visit (defect classification, severity rating, report drafting) is software-cheap.
The interesting question, then, is not how do we help the inspector. It is how do we remove the inspector from the acquisition loop without losing the data they produce. PropertyScan is an experiment in answering that, by turning the tenant into the camera operator and putting the expert in the loop only when something is flagged.
A non-expert with a phone is a noisy sensor. The trick that makes the data usable is borrowed from systems engineering: default-deny. The default state of the app is "cannot advance." It refuses to leave a room, finish a wall, or terminate the session unless a set of acquisition invariants holds for that surface.
The invariants are concrete: coverage of the floor plan's known surfaces, parallax between successive frames, focus quality, exposure, and scale consistency from ARKit pose. The tenant is on rails. They cannot skip a corner because the corner is missing from the coverage map. They cannot submit blurred frames because the frame buffer is blur-gated. They cannot mis-scale a wall because every frame carries metric pose.
The result is a dataset that an inspector would have produced, by enforcement rather than expertise. The tenant is the camera operator. The protocol is the inspector.
Three phases on a single iOS app.
Phase 1, Floor plan. On LiDAR-capable devices (iPhone 12 Pro and later), Apple RoomPlan extracts walls, doors, and windows automatically. On non-LiDAR devices, the tenant marks corners in AR; Depth Anything V2 (CoreML, 48 MB) provides per-pixel depth hints to disambiguate the geometry. Both paths emit the same room schema and become the rail the rest of the session runs on.
Phase 2, Rail-guided sweep. The app projects per-wall AR arrows derived from the floor plan, auto-captures every 2–3 s with blur-gated frames, and tracks coverage as a percentage of the known surfaces. Coverage below threshold blocks the room transition. There is no skip button.
Phase 3, Triage. On-device CoreML pipeline (YOLO11-seg at 30.7 MB, SAM2 Tiny at 76 MB) runs a first pass. Apple Foundation Models produce a per-room narrative summary in ~2 s, fully offline. Off-device: a Gemini Flash → Pro cascade handles anything that needs more capacity, with server-side YOLOE-large for crack segmentation. The expert reviews only what the protocol could not resolve. Reports emit as PDF plus a USDZ 3D model.
On-device inference is not there to replace cloud models. It is there to close the feedback loop before the tenant leaves the room. The first time you learn a wall was under-covered or a frame was unusable must not be after upload. By then the tenant is gone.
Cloud analysis then refines. The split was chosen against a target operational cost of ~$0.17 per scan: heavy vision-language work stays remote; everything that affects what the operator does next stays local.
Prototype. Floor plan capture (both LiDAR and AR-fallback paths), rail-guided sweep with coverage tracking, PDF and USDZ export, and the cloud upload pipeline are working end-to-end. Defect detection is the hard part and is still in progress. The on-device weights bundled today are placeholders, and the BD3 building-defect dataset (3,965 annotated images, 7 classes) is being fine-tuned.
Stack: SwiftUI · ARKit · RoomPlan · Vision · CoreML on iOS. FastAPI · Celery · Redis · S3 on the cloud side, with a TypeScript monorepo (tRPC · Drizzle · LibSQL) serving the inspection dashboard. Reconstruction layer can route to MapAnything, COLMAP, or Nerfstudio depending on input quality.
The research question underneath is not "which model detects which crack." It is how much of an acquisition session can be guaranteed by protocol (coverage, parallax, focus, scale) so that a non-expert sensor produces data a downstream model can act on. That is the part this project is built to study.