Why PaxExact computes measurements server-side

PaxExact's measurement module works from the dimensions recorded for a room and computes derived figures such as floor area from them. The computation happens once, in one place, against one set of recorded inputs, rather than being left to whichever client happens to be displaying the room. Net wall area with opening deductions is in development and not yet part of this computation.

A room's measurement record is its own entity, linked to the room and, through it, to the line items whose quantities depend on it — the same linked-record model that runs through PaxExact's evidence-to-line-item chain.

Keeping measurement as its own record, rather than a number typed directly onto a line item, is what makes it possible for one measurement to support several downstream quantities consistently. A floor-area figure computed once for a room can inform every line item priced by that surface, and correcting the measurement corrects all of them together rather than requiring each line to be separately re-typed.

Deriving a measurement is arithmetic, but arithmetic done independently in multiple places on the same inputs can still disagree — through a rounding difference, a different assumption about a dimension, or a stale cached copy of the room's inputs. PaxExact computes measurement once, server-side, from the dimensions of record, so that every consumer of a room's floor area — the estimator's view, a line item's quantity, a later export — reads the same figure computed the same way.

This also means a measurement can be recomputed cleanly when its inputs change. Because the computation is not duplicated across clients, correcting a recorded dimension and recomputing produces one authoritative new figure, rather than requiring every place that separately calculated the old figure to be found and updated.

It also removes an entire class of dispute. If two people looking at the same claim ever disagreed on a floor-area figure because they were each computing it locally from slightly different assumptions, there would be no single record to point to as the answer. A server-computed measurement is that single record: the figure is a property of the room as recorded, not a property of whichever screen happens to be showing it.

A computed measurement is not treated as final the moment it is produced. It carries an explicit review state, and a professional accepts or rejects it before it is relied on for quantities elsewhere in the estimate. This is the same accept/reject discipline that governs quantities and damage observations elsewhere in PaxExact: a computed figure is a proposal until a person has looked at it.

Rejecting a measurement does not silently fall back to some default; it leaves the measurement in a state that says a person looked at it and did not accept it, which is a materially different fact from a measurement that was never reviewed at all.

The review step exists because a computed figure is only as good as the recorded dimensions behind it — a mis-entered room dimension produces a confidently wrong floor area, and no amount of computational precision fixes an input mistake. Requiring a person to accept the measurement before it feeds a quantity is what catches that kind of error before it propagates into a priced line item.

A wall is rarely a solid surface — doors and windows reduce the area that is actually being repaired or repainted. Net wall area with opening deductions is in development: PaxExact does not yet compute those deductions as part of a measurement. An uploaded RoomPlan scan does record each door, window and opening's width and height as a proposed measurement, but nothing deducts them from wall area yet. The design intent, once it ships, is to record each opening as a documented deduction from the gross measurement, so a reviewer can see the gross dimension and each deduction that produced the net figure, not just a final answer.

Treating deductions as their own recorded facts, rather than an unexplained gap between a gross and a net figure, is consistent with the same evidentiary standard PaxExact applies elsewhere: a number that matters to the estimate should be traceable to the specific fact that produced it, not simply asserted as a final result.

Today, measurement is entered in a web browser or proposed from a LiDAR room scan. The scan path is in beta: a scan made in another app — an Apple RoomPlan JSON export, or a USDZ file with a text (.usda) layer — is uploaded to a room, and PaxExact derives proposed dimensions from the retained file on the server. RoomPlan import has not yet been proven on a real device export, USDZ import has been tested with one real scan, binary USDZ is not supported yet, and any USDZ file yields only the overall bounding dimensions of the capture; only the RoomPlan JSON export is read as a room model. There is no dedicated PaxExact mobile capture app; one with video and built-in LiDAR scanning is on the roadmap but not built. Net wall area with opening deductions is also in development — today's server-computed figures are room dimensions and floor area, not a net wall-area total.

The remaining gaps sit in how a measurement's inputs get recorded, not in how they are computed once they exist. The server-side computation, and the accept/reject review step around it, apply the same way whether a dimension was typed by hand or proposed from a scan.