How house scanning works

Living explainer for new teammates and agents. Current as of 26 September 2026, midday. About fifteen minutes.

A homeowner scans the outside of their house around the electric meter with an iPhone. The phone captures the wall, the server builds a 3D model and checks Base Power's placement rules against it, and the app shows where the battery goes, in AR, on the real wall.

Picture a home inspector with a tape measure and a checklist. The phone is the inspector's eyes and tape, and the server holds the checklist. The comparison breaks in one place, and that place shapes the design: an inspector can lean around a bush to look, but the server can judge only what the phone actually saw.

1. The problem: a battery has to fit between the rules

An outside wall with the battery and its clearance rules, drawn to scale Front view of a house wall. From left: an AC unit on the ground, a gas meter, the electric meter, the battery just to its right, a window, a door. Red hatched zones show 3 feet of clearance around the gas meter, AC unit, window and door. A bracket beside the battery shows 6.5 feet of headroom. A blue bracket along the ground shows 20 feet of cable reach either side of the electric meter. A tape along the bottom counts feet from the meter. Below, a view from above shows the battery footprint, 31 by 22 inches, and the 3 feet of clear space needed in front of it. 20 ft of cable, either side of the meter AC unit gas meter electric meter window door 6.5 ft headroom battery 3 ft 3 ft 3 ft 3 ft 151050 510152025 feet left and right of the electric meter The same wall from above battery footprint, 31 by 22 in 3 ft clear in front AC unit gas

Wider than the screen: scroll sideways for the rest of the picture.

Everything is drawn at one scale: 5 ft between tape marks. The red hatched areas are places the battery may not go. The battery just fits between the electric meter and the window's zone. Rules shown: 3 ft from the gas meter, from AC units, fences and other batteries, and from doors and windows that enter the home; 3 ft of clear space in front; 6.5 ft of headroom; within 20 ft of cable run from the meter; a flat, seen stretch of wall behind it.

Base Power puts a home battery on the outside wall, close to the electric meter, because a cable runs from the meter to the battery. The battery is 31 in wide, 22 in deep and 39.5 in tall. Whether it fits, and where, depends on the clearance rules in the picture. Today someone judges that from a few customer photos, which have no scale and can't show what sits just outside the frame.

The demo's rules come from public sources and live in the server's rules file, each with its citation. Two numbers there are placeholders because no public value exists (pool 10 ft, driveway 5 ft). Base's own thresholds are private, load at runtime from a file that is not in git, and do not appear on this page.

The rules the demo uses, with sources
RuleValueSource
Distance from the gas meter3 ftBase's public help page; Austin Energy; Texas Gas Service
Distance from AC units, fences, other batteries3 ftBase's help page
Distance from doors and windows that enter the home3 ftIRC R328.4
Clear space in front of the battery3 ftBase's help page
Cable run from the meterwithin 20 ftBase's help page
Headroom6.5 ftNEC 110.26, a demo choice
Wall behind the batteryflat, and seen by the camerademo requirement
Pool, driveway10 ft, 5 ftplaceholders; no public value exists

2. From scan to answer, one step at a time

The project splits into three problems: a phone that guides the homeowner until everything needed is captured, photos and their metadata turned into a 3D model, and that model checked against the rules. Two teams share them. Each picture below redraws the last and adds one step. The dashed line down the middle is the boundary between the teams.

  1. Stage 1: the phone guides the scan with a live 3D map The client team's side holds one box: a phone whose screen shows the wall, with grey haze over the part not yet seen. The label reads: guided scan, live 3D map, fog lifts as it sees. The server team's side is empty.
    The phone guides the scan. The app builds a live 3D map on the phone as the homeowner moves. A haze, which the team calls fog of war, covers what the phone hasn't seen and lifts as it sees it. The app routes the homeowner until every part the model needs is seen.
  2. Stage 2: the phone sends a capture packet The guided scan box from stage 1, with an arrow to a file icon labelled packet, sitting on the line between the teams.
    It sends a capture packet. Today the app uploads only its measurements and exports the full packet on request; the packet's README lists what it records so far. The packet holds photos; where the camera was and which way it pointed for each one (poses); the lens's focal length and center (intrinsics); motion-sensor readings; LiDAR depth and mesh when the phone has LiDAR; and the homeowner's marks, such as the meter. The packet is the contract between the teams.
  3. Stage 3: the server builds a 3D model from the packet Stages 1 and 2, plus an arrow from the packet to a box on the server side showing a dotted 3D wall with a window and the meter, labelled 3D model or point cloud.
    The server builds a 3D model. From the packet, the server team builds a 3D model or point cloud of the wall and the ground in front of it, at real scale. Which method does this best is open; section 4 compares the options.
  4. Stage 4: plain code checks the rules against the model Stages 1 to 3, plus an arrow down from the 3D model to a box labelled rules, plain code. It lists three checks: gas meter PASS, window UNSURE, door FAIL.
    Plain code checks the rules. The rules and their sources live in a file. Code tries the battery's footprint at every spot along the wall, and each check at each spot comes out PASS, FAIL or UNSURE. No model makes this decision, so every answer traces back to a rule and a measurement.
  5. Stage 5: the answer returns to the phone and shows in AR The whole loop. Guided scan, packet, 3D model, rules, and now an arrow labelled answer back across the line to a phone on the client side showing the battery outlined on the wall beside the meter.
    The answer comes back to the phone. The app draws the battery on the real wall in AR. It places the battery relative to the meter's anchor, so the drawing stays on the right spot as the phone's tracking corrects itself. When a check is UNSURE, the answer names the view that would settle it, and the homeowner can capture it on the spot.

3. Four ideas that keep the answer honest

The error bar decides: PASS, FAIL or UNSURE

No measurement is exact. The phone tracks its own position by dead reckoning, like counting your steps from a doorway, so its error grows the farther it gets from the meter. The comparison has a limit: a miscounted step only stretches the walk, while the phone's error can also drift sideways.

The server widens every measurement's error bar by 0.3 ft plus 0.16 ft for each foot from the meter. On public test walks, a current iPhone's tracking stayed inside that allowance. Then each check compares the rule against the whole error bar, not a single number.

Three measurements against the 3 foot gas meter rule A number line from 0 to 6 feet with a vertical rule at 3 feet. Row one: 4.5 feet plus or minus 0.8, the whole bar sits right of 3, PASS. Row two: 2.0 feet plus or minus 0.8, the whole bar sits left of 3, FAIL. Row three: 3.4 feet plus or minus 0.8, the bar straddles 3, UNSURE. 0123456 ft 3 ft rule (gas meter) too close clear 4.5 ft ± 0.8: clear by 1.5, more than 0.8 ✓ PASS 2.0 ft ± 0.8: short by 1.0, more than 0.8 ✕ FAIL 3.4 ft ± 0.8: clear by only 0.4 ? UNSURE
Three measurements against the 3 ft gas meter rule, each with an error bar of ± 0.8 ft. A check passes only when its margin beats the error, fails only when it misses by more than the error, and is UNSURE otherwise; a tie is UNSURE. UNSURE means a person looks, or the app asks for a better view. Tighter geometry shrinks the error bars and turns UNSURE answers into PASS or FAIL, which is why the 3D path matters.

Unseen is not clear

The live map's haze works like the fog of war in a strategy game: a dark patch is unexplored, not empty. The comparison stops there. In a game, scouting reveals the truth. Here, even the parts the phone saw carry an error bar.

A check whose ground was never seen stays UNSURE and names the missing view A candidate battery spot on the wall. The ground beside it is covered by grey haze. Beside it a check reads: ground near the spot, checks need 6 to 13 ft of seen ground, UNSURE, missing evidence: show the ground about 6 ft right of your meter. meter candidate spot never seen Ground near the spot checks need 6 to 13 ft of ground ? UNSURE missing evidence: show the ground 6 ft right of your meter
If the camera never saw part of the area a rule depends on, that check cannot pass. It stays UNSURE, and the server names the view that would settle it. Here the ground beside the spot was never seen, and the checks that use ground need 6 to 13 ft of it. A blank on the map is never treated as empty ground.

Coverage means 100% of what the model needs

The app doesn't need the whole house. It needs every part the rules depend on, all of it. That is a fixed zone around the meter, so the app can say exactly what is left, and the scan can end when the zone is clear.

The zone a scan must cover, seen from above A plan view of the house with the electric meter on its front wall. A dashed blue rectangle marks the zone the checks need: the wall 20 feet either side of the meter and the ground in front of it out to 13 feet. Everything outside it is grey haze labelled not needed. Inside, a bush stands in front of the wall; the strip of wall behind it is unseen, so checks there are UNSURE. A dotted path shows the phone walking along the zone. house, seen from above cable reach: 20 ft either side not needed meter wall behind the bush: unseen, so UNSURE needed: all of it ground out to 13 ft
Drawn to scale, 1 ft to 8 px. The zone is the wall within 20 ft of cable either side of the meter, the ground in front out to 6 to 13 ft depending on the check, and the space overhead for headroom, which a plan view can't show. Near each end it reaches past 20 ft by the clearance around a spot at the edge of reach. A pass needs only the chosen spot and its clearances seen, and the server's answer says when the walk has gone far enough. The coverage map has to be honest. The app's first map checked only range, angle and framing, and claimed 1.1 ft of wall that no photo saw. Tested against depth, the recon worker claims at most about 0.46 ft.

LiDAR first, never required

Some iPhones have LiDAR, a sensor that measures depth directly by timing reflected light. Most homeowners' phones don't. The app uses LiDAR and other depth sensors whenever the phone has them, and every check must also work without them.

Two ways to get depth at real scale Left, a phone with LiDAR sends rays to a wall seen from the side, and dots on the wall mark measured depth; its reach is about 5 metres. Right, any iPhone: a dashed line shows a depth model's guess of where the wall is, a little off. The phone at two known positions sees the same point on the real wall, and the two sight lines meet there, which fixes the scale. Phone with LiDAR Any iPhone measured directly reach about 5 m model's guess known move guessed, then rescaled by triangulating with poses
LiDAR works like a laser tape measure: direct distances, but a reach of about 5 m, so capture has to stand within about 4 m of the wall. Without it, a learned model estimates depth in each photo, and the phone's poses fix the scale: the same point seen from two known positions pins down its distance, the way two eyes judge depth. Where that comparison breaks: your eyes sit a fixed distance apart, but the phone's move between photos comes from its tracking and carries that error. Both paths fill the same capture packet.

4. How to build the 3D model: the options

Problem 2, photos and metadata into a 3D model, is open. The server team is comparing three families of methods: broadly first, then in depth on the best. None is ruled out. The numbers so far come from public datasets whose buildings were laser-scanned, so the true shape is known to a fraction of an inch.

Traditional reconstruction, fused with LiDAR

Geometry from first principles: find the same points in several photos, work out where they sit in 3D, and merge the depth from every view into one surface. LiDAR depth drops straight into that merge.

The known weakness is that matching points across photos struggles on blank siding and has no scale of its own. LiDAR and the phone's poses supply the scale.

Evidence: the recon worker (PR #20) merges depth into one surface. With a laser scan standing in for LiDAR, its walls come out at 2.1 in (p90).

Learned depth plus the phone's poses

A neural network estimates depth from a single photo. Its own sense of scale is off by 4 to 12%, so the photos are rescaled with the phone's poses and then merged.

MapAnything, a learned model that reads several photos at once, was not a stable baseline: its scale shifted with the input resolution.

Evidence: walls about 5 in (p90) at a realistic phone error, 2.8 in with exact poses. Edges 8 in or worse in every setting.

World models

Large learned models that take photos or video and produce a whole 3D scene at once, camera positions included. Think of someone who has seen thousands of houses sketching this one from a few snapshots.

The sketch comparison also shows the risk: a good sketch fills in what the artist never saw. That is fine for a picture, but a check needs to know which parts were observed.

Evidence: not evaluated yet. The server team will.

Wall error at p90 for each 3D path tested so far, on one laser-scanned building

Wall error at p90, in inches, for each 3D path tested so far A dot plot from 0 to 20 inches. Depth model alone: about 20 inches. Depth model rescaled with poses at a realistic 2 percent pose error: 5.0 inches, interval 3.8 to 6.8. With exact poses: 2.8 inches, interval 2.0 to 4.4. Edges with learned depth: 8 inches or worse in every setting. Recon worker, photos only: 2.8 inches. Recon worker with a laser scan standing in for LiDAR: 2.1 inches. World models: not evaluated yet. 05101520 inwall error, p90 (9 in 10 points are closer) depth model alone + poses, 2% error + exact poses edges, any setting recon, photos only recon, laser as LiDAR world models about 20 in 5.0 in (3.8 to 6.8) 2.8 in (2.0 to 4.4) 8 in or worse 2.8 in 2.1 in not evaluated yet Depth model alone, its own scale: p90 about 20 in Depth rescaled with phone poses at a 2% pose scale error: p90 5.0 in, 95% interval 3.8 to 6.8 Depth rescaled with exact poses: p90 2.8 in, 95% interval 2.0 to 4.4 Edges, learned depth: 8 in or worse in every setting Recon worker, photos only: wall p90 2.8 in Recon worker, laser scan as LiDAR: wall p90 2.1 in World models: not evaluated yet
All rows come from the ETH3D electro building, walls within 6 m. The top four are learned depth (MoGe-2 and Depth Anything 3); the next two are the recon worker; the last has no data yet. Brackets are 95% intervals where they exist. Caveat: the recon worker's two runs chose different walls, so those two numbers are not measured on the same wall. Reading it: learned depth alone is too rough for clearances, which are measured from edges. With LiDAR or the phone's poses supplying scale, walls come within a few inches.
Data table
PathSettingWall error, p90Source
Learned depthmodel's own scale (4 to 12% off)about 20 inevals, PR #12
Learned depthrescaled with poses, 2% pose scale error5.0 in (3.8 to 6.8)evals, PR #12
Learned depthrescaled with exact poses2.8 in (2.0 to 4.4)evals, PR #12
Learned depthedges, every setting8 in or worseevals, PR #12
Recon workerphotos only2.8 inrecon, PR #20
Recon workerlaser scan standing in for LiDAR2.1 inrecon, PR #20
World modelsnot evaluatedserver team, next

What any path has to show

5. Where each piece lives

Files marked with a pull request exist only on that branch until it merges. Each component's README wins over this page.

PieceSource of truthState
iPhone app
client team		ios/README.mdGuided capture in PR #10; live 3D map in PR #21, stacked on it
Capture packet
client team		packet/README.mdSpec, validator and samples in PR #22
Rules engine, API, capture contract
server team		server/README.md, "What settles each check"PR #11; live as a public demo with public rules, and privately with Base's rules behind a key
Reconstruction worker
server team		recon/HANDOFF.mdDraft PR #20, handed to the server team
Accuracy evalsexperiments/evals/README.mdPR #12
Agent rules, system overviewAGENTS.md, docs/00-overview.mdOn main
Web review pageParked, PR #15

The plan, the decisions and the full evidence list are in 00-overview.md. The public rule values, their code citations and the model and imagery licenses are in 04-prior-art-and-codes.md.