The console
A browser: submit a file, watch the phases move, open the result in a viewer and download the folder.
Six steps, in this order, on every submission. You can stop after any of them, run one on its own, or hand over a stage list of your own.
The header first: bounds, point count, returns, the classification histogram, the coordinate reference system and what is missing from it. Horizontal and vertical EPSG codes are read, stamped and reprojected as a first-class record rather than guessed at.
This is a read of the header, not of the file, so it answers on a survey-sized cloud in the time it takes to open one. A file with no vertical datum, a unit that disagrees with its own header, or duplicate points across strips is something you want to know before a job runs rather than after.
Noise out, ground separated from everything standing on it, vegetation split by height above ground, buildings found as planes. The ground filter is chosen from the site itself rather than fixed: a progressive morphological filter suits a flat corridor and a cloth simulation suits a steep forested slope, and picking the wrong one is the difference between a terrain model and a smoothed hillside.
Measured on a five-point-eight-million-point parcel on a twenty-four per cent forested slope: sixteen seconds from raw, unlabelled points.
Rasters at the cell size you ask for, each written with its coordinate reference system attached: bare earth, the surface including everything on it, and the height of the canopy between them. A colour preview is written beside each one so a reviewer can see the result without loading it into anything.
Contours from the ground points at your interval, with index contours on their own layer. Cross-sections at stations along an alignment, each with a long profile, as drawings or as the underlying numbers.
An overview and a level-of-detail pyramid, so a survey-sized cloud opens in a browser rather than being downloaded. The same cloud can be written as a cloud-optimised point cloud instead, for a desktop client that reads pieces of a file over the network.
What the run did, what it found and what it wrote: the classification before and after, the parameters each stage actually used, the findings worth a reviewer's attention, and every artifact with its size. As a page to read and as a machine-readable record, because a deliverable that cannot be checked is a deliverable somebody has to trust.
A browser: submit a file, watch the phases move, open the result in a viewer and download the folder.
A script or a pipeline of your own. A client uploads its file straight to object storage with a presigned PUT; the bytes are never posted through the API.
The REST API and the MCP server are two front doors onto one typed contract, so an HTTP client and an AI assistant reach the same operations with the same names, schemas and errors.
While a job runs it publishes a ledger a client can poll: state, phase, percent complete, events with stable codes, the run's own log lines and the report.
That matters more than it sounds. A job on a survey-sized cloud is minutes of work, and a progress bar that is a guess is worse than none; the phases and the percent come from what the run has actually finished.
Two real deliveries, and the machine each ran on. Neither is a benchmark and neither is a promise about your data — a point cloud's shape decides most of its cost.