Location is not a property.
It's a dependency graph.
The same sensor reading means something completely different depending on where it was taken, what's upwind, what terrain intervenes, which jurisdiction governs it, and what happened at neighboring sensors sixty seconds ago. geog.ai resolves that dependency graph — in real time, for every reading, on every device.
sensor ingestion
spatial meaning
autonomous decision
What geog.ai is — and is not
What Stripe did to payment APIs, geog.ai does to spatial intelligence — turns something that required specialist tooling into a clean API call that any application can make.
| geog.ai IS | geog.ai is NOT |
|---|---|
| A real-time spatial reasoning engine | A GIS tool for analysts |
| A physics-aware decision substrate | A mapping application |
| An API layer that turns location into context | A tile server or visualization platform |
| A propagation and simulation runtime | A replacement for QGIS, ArcGIS, or ESRI |
| A calibration loop that improves with sensor data | A static geodata warehouse |
ArcGIS answers: What is where?
geog.ai answers: Given where and current conditions — what happens next, to whom, and who is responsible?
That is a categorically different product.
Every IoT platform stores what and when.
Most stop there.
The full decision loop requires a third axis — without it, you have a data logging system, not a decision engine.
// Resolve the WHERE — now you have a decision:
{
"wind_vector": { "speed_ms": 8.2, "bearing_deg": 312 },
"source": { "asset": "wellpad_07", "distance_m": 195 },
"terrain": { "ridge_height_m": 15, "slope_deg": 3.1 },
"upwind_sensors": [{ "reading_ppm": 0 }, { "reading_ppm": 0 }],
"jurisdiction": { "authority": "TCEQ", "limit_ppm": 10, "notify_within_hr": 24 },
"personnel_zones_at_risk_in_12min": ["Zone C", "Zone D"]
}
The raw sensor value was one field. The rest is spatial context — resolved, enriched, and current. That's what geog.ai provides.
The Four Where-Types
Every spatial system that fails does so because it treats location as a single coordinate field. geog.ai treats location as having four distinct semantics, each requiring different storage, indexing, and reasoning.
Observation Geometry
Where the measurement was physically taken. Includes lat/lon/altitude for outdoor sensors, and building/floor/zone/room for indoor. This is the starting point — a spatiotemporal fact that changes when devices move.
Asset / Site Geometry
Where the thing being monitored exists. A well pad is a polygon. A pipeline is a polyline. A watershed is a network. A factory fence is a boundary. This geometry is stable but versioned — it changes when the physical asset changes.
Field-of-Influence Geometry
The modeled footprint of a phenomenon — a plume, a flood inundation extent, an RF coverage map, a noise contour, a thermal diffusion field. This geometry is computed, not stored. It changes as conditions change.
Governance Geometry
Jurisdictional boundaries, permit areas, exclusion zones, regulatory districts, easements. Location determines which rules apply, which authority is notified, which permit threshold governs. Versioned and auditable — legally consequential.
Six engines that model how phenomena move through space
Most IoT platforms stop at spatial indexing and context enrichment. geog.ai goes further: physics-based simulations of how things propagate through terrain, atmosphere, and infrastructure.
Atmospheric Dispersion
Gaussian plume (Tier 1, <1s), AERMOD regulatory grade (Tier 2, 1–30s), and Lagrangian particle tracking for non-steady-state scenarios. Calibrated per-site against actual sensor readings.
Try the live plume demo
RF Propagation
ITM/Longley-Rice terrain model for outdoor links. HATA/COST-231 for urban deployments. Coverage probability polygons, link budget analysis, mesh viability matrix, and node placement optimizer.
Try the live RF coverage demo
Flood & Hydrological
DEM-based watershed delineation, SCS Curve Number rainfall-runoff, kinematic wave channel routing, and 2D flood inundation mapping. EPA SWMM integration for urban stormwater networks.
Try the live flood inundation demo
Noise Propagation
ISO 9613-2 standard octave-band outdoor sound propagation. Accounts for geometric spreading, atmospheric absorption, ground effect, barrier insertion loss, and vegetation attenuation. Produces isodB contour polygons.
Thermal Diffusion
Heat propagation from industrial sources, fire events, or HVAC failures. Time-to-temperature-threshold at monitored locations, hot zone polygons for personnel exclusion, and cooling cascade prediction.
Spatial Graph Engine
Models sensor networks as graphs — nodes (devices/assets), edges (distance, radio, fluid, causal influence). Enables influence spread queries, evacuation routing, anomaly clustering, and mesh failure analysis.
The calibration loop — the feature that compounds
GIS platforms don't have sensors. IoT platforms don't have physics models. geog.ai has both — and runs a feedback loop that neither competitor can replicate.
↓
Compare against actual sensor readings
↓
Compute residuals (predicted - observed)
↓
Update site-specific model parameters (stability correction,
terrain factor, effective emission height)
↓
Next simulation is more accurate
After 30 days, plume predictions are site-calibrated. After 90 days, they're calibrated to seasonal meteorological patterns. After a year, they're calibrated to facility operating modes. A competitor deploying the same software on the same site starts from scratch.
Regulatory boundaries, permit IDs, notification thresholds, cross-boundary relationships — assembled from hundreds of public sources, normalized, versioned, and continuously maintained. Expensive to replicate.
The spatial graph of deployed devices, their connectivity, their historical behavior patterns, their terrain relationships — a proprietary asset that grows with every deployment.
A new competitor on day one has generic models. geog.ai on year two has site-specific models calibrated against millions of actual sensor readings. The gap widens every day the system runs.
geog.ai × m8n — spatial layer meets decision layer
geog.ai is the spatial layer. m8n is the decision layer. Neither is complete without the other. Every m8n native function becomes location-aware through geog.ai.
m8n.app
Decision engine, workspace orchestration, blueprint execution, outcome learning
geog.ai
Spatial context resolution, propagation modeling, RF optimization, jurisdiction mapping, calibration loop
zooid.net
Edge agents, sensor ingestion, mesh networking, Scout/Hive/Swarm/Colony tiers, IoT verticals
Spatial Triggers
Blueprints can fire on spatial conditions — "plume crosses permit boundary," "asset enters exclusion zone," "RF coverage drops below minimum in zone." Jurisdiction-aware notifications route to the correct authority based on where the event occurred.
Terrain-Normalized Anomalies
A reading that looks anomalous is normal if the sensor is in a valley during a temperature inversion. Pattern Analysis accuracy improves when geog.ai resolves whether a reading is spatially expected or genuinely anomalous.
Location-Driven Configuration
When Bootstrap receives a deployment location, geog.ai resolves jurisdiction (sets thresholds), terrain type (selects propagation model), local climatology (sets dispersion parameters), and neighboring deployments (identifies calibration references).
Sensor Placement Intelligence
Bootstrap's initial deployment recommendation includes geog.ai's sensor placement optimization — given terrain, prevailing wind, and asset layout, where should the first sensors go for maximum coverage and minimum redundancy?
The verticals where WHERE changes everything.
Every zooid.net vertical has at least one spatial dependency. These are the verticals where geog.ai's spatial reasoning is the critical path — where the sensor reading means nothing without the plume direction, watershed position, regulatory boundary, or terrain between source and receiver.
Primary: Atmospheric dispersion — plume simulation and wind-source triangulation. Three sensors reading zero upwind + one reading 50 ppm downwind = source location, plume direction, emission rate estimate, and twelve-minute risk forecast for personnel zones.
Secondary: Jurisdiction mapping for TCEQ/EPA notification thresholds. Personnel zone proximity from indoor spatial graph.
Primary: Watershed delineation and inundation mapping — every water sensor's position resolved to its upstream contributing area and downstream flood zone. Contamination plume tracked through the hydrological network.
Secondary: Upstream sensor graph for causal attribution. NPDES permit boundary enforcement via governance geometry.
Primary: Terrain-adjusted spatial interpolation and kriging — microclimate readings from a valley floor mean something fundamentally different than readings from a ridge top. geog.ai resolves terrain context for every met station to produce spatially meaningful nowcasts.
Secondary: Fire weather index enrichment. Atmospheric stability class resolution for plume models that depend on this vertical's wind data.
Primary: Fire spread polygon and ember transport zone — combining fire source, terrain, and wind vectors to model propagation in minutes. Ignition risk enrichment from lightning strike coordinates and fire weather index. Prescribed burn containment geofence and escape-route check.
Secondary: CAL FIRE/USFS district boundary and notification authority. Upstream weather station graph for fire weather index computation.
Primary: Vibration spatial correlation and settlement mapping — seismic signals propagate through soil in ways that depend on geology, depth, and intervening structure. geog.ai resolves which sensors are geologically co-located vs. separated by a fault plane or soil type boundary.
Secondary: Building footprint and infrastructure polygon context. Slope stability zone geometry for landslide-risk enrichment.
Primary: Spatial correlation of pressure delta anomalies along a polyline asset to locate leak position. A pressure drop between sensors narrows the leak to a segment; geog.ai resolves that segment geometry, its terrain, and nearest access point.
Secondary: PHMSA permit boundary and right-of-way polygon. Nearest water body and settlement for consequence-of-failure enrichment.
Primary: Transmission line coordinate enrichment for ice-load and wind-load per segment using terrain and weather context. Power network graph for outage propagation modeling — which downstream assets are at risk if this transformer fails.
Secondary: FERC territory polygon for jurisdiction and notification authority. Terrain-adjusted wind resource via spatial kriging for renewable integration planning.
Primary: Route analysis and congestion zone detection — traffic counts are only meaningful when resolved to their road network position, intersection geometry, and upstream/downstream flow relationships. geog.ai resolves the infrastructure graph that makes adaptive signal control spatially coherent.
Secondary: DOT district jurisdiction for incident notification. V2X RSU coverage polygon for autonomous vehicle corridor analysis.
Primary: Vessel trajectory modeling, berth proximity resolution, and plume dispersion over water for exhaust and fuel spill analysis. Tidal current modeling affects both plume transport and berthing safety margins.
Secondary: Tidal zone jurisdiction for COLREGS and port authority notification. Hull sensor positions resolved against berth and channel geometry for collision-risk enrichment.
Primary: Field zone analysis and soil variability mapping using NDVI + terrain + soil sensor spatial interpolation. Variable rate application zones are output geometries — polygons that prescribe exactly where and how much to apply, computed from spatial heterogeneity in the sensor network.
Secondary: Watershed delineation for irrigation return flow modeling. Property boundary for regulatory compliance on chemical application.
Primary: Water body geometry and current modeling for drift prediction of buoys, gliders, and pollutant plumes. DO and temperature readings from distributed sensors spatially interpolated across the monitoring area to build a continuous field model — not isolated point readings.
Secondary: EEZ and watershed boundary for regulatory trigger evaluation. Effluent plume simulation for pollution source tracing.
Primary: Pen GPS coordinates resolved against tidal current vector and water exchange rate — the same DO reading in a well-flushed pen and a stagnant corner means something completely different. Spatial interpolation of DO and temperature across the pen array identifies which pens need intervention.
Secondary: Aquaculture licensing authority and lice treatment trigger via watershed/EEZ boundary. Effluent plume for downstream impact assessment.
Quick reference — primary geog.ai call by vertical
| Vertical | Primary geog.ai Call | Secondary |
|---|---|---|
| V01Gas & Air Quality Monitoring | POST /simulate/plume |
GET /jurisdiction GET /nearby |
| V02Water Quality & Hydrology | POST /simulate/flood |
GET /graph/upstream GET /within (watershed) |
| V04Seismic & Geotechnical Monitoring | GET /context |
GET /nearby (soil zone) GET /within (slope stability) |
| V05Noise & Vibration Monitoring | POST /simulate/noise |
GET /jurisdiction (noise limits) |
| V06Weather & Microclimate | GET /context |
GET /nearby (terrain-adjusted) |
| V17Emergency & Disaster Response | POST /simulate/plume (multi-source) |
GET /graph/evacuate GET /jurisdiction (dynamic) |
| V18Drone Operations & Aerial Intelligence | GET /rf/coverage |
GET /trajectory/predict GET /within (no-fly zones) |
| V19Traffic & Transportation Intelligence | GET /context |
POST /simulate/rf_coverage (V2X RSU) |
| V21Precision Agriculture & Land Management | GET /coverage (field zones) |
GET /context (soil variability) POST /simulate/flood (watershed) |
| V22Marine & Port Operations | GET /trajectory |
POST /simulate/plume (spill) GET /jurisdiction (tidal) |
| V23Pipeline & Linear Asset Monitoring | GET /context (spatial correlation) |
GET /jurisdiction (right-of-way) |
| V27Aquatic & Oceanographic Monitoring | POST /simulate/plume (ocean) |
GET /trajectory (buoy drift) GET /within (EEZ boundary) |
| V36Power Generation & Grid Infrastructure | GET /context |
GET /within (FERC territory) GET /graph/influence (outage) |
| V47Border & Perimeter Security | POST /rf/mesh/viability POST /rf/optimize/placement |
GET /rf/gaps GET /rf/coverage |
| V50Wildfire Detection & Prescribed Burn Management | POST /simulate/fire |
POST /simulate/plume (smoke transport) |
All 50 ZOOID verticals ship with geog.ai context resolution on every sensor event. See zooid.net/zooid/#clusters for the full vertical explorer.
Spatial intelligence as clean API calls
Every response includes the result, a confidence score (0.0–1.0), model version, calibration age, and full data provenance.
GET /context?device_id=sensor_h2s_023
GET /context/batch?device_ids=[...]
# Proximity and spatial queries
GET /nearby?lat=31.96&lon=-99.90&radius_m=500&type=gas_sensor
GET /within?geometry={polygon}&type=asset
GET /jurisdiction?lat=31.96&lon=-99.90
# Propagation simulations (async jobs with webhook callback)
POST /simulate/plume { source, wind, stability_class, duration_min }
POST /simulate/flood { watershed_id, precip_mm, duration_hr }
POST /simulate/rf_coverage { node_id, frequency_mhz, tx_power_dbm }
POST /simulate/noise { source_id, octave_bands_db }
POST /simulate/fire { ignition_point, fuel_model, weather }
# RF-specific (propagation, mesh, placement)
GET /rf/coverage?node=N&threshold_dbm=-90
GET /rf/link?from=A&to=B
POST /rf/mesh/viability { node_ids, failure_scenarios }
POST /rf/optimize/placement { area, coverage_threshold, existing_nodes }
GET /rf/gaps?area=polygon&threshold_m=500
# Optimization and calibration
POST /optimize/node_placement { area, coverage_threshold, existing_nodes }
POST /optimize/sensor_placement { vertical, target_coverage_pct }
GET /model/calibration?model=plume&site_id=wellpad_07
Pay per call. Subscribe per site.
We sell spatial decisions — not maps, not tiles. Two pricing dimensions: metered API usage for queries and simulations, and site-level calibration subscriptions that compound over time.
Spatial context resolution for any device. Returns full SpatialState — terrain, jurisdiction, neighbors, wind vector, confidence score.
The calibration loop running on a specific facility. Models improve every day. Switching cost increases every month — by design.
Physics-based simulation jobs — plume, flood, RF coverage, noise contours, fire spread. Priced by model tier and complexity.
| Endpoint | Type | Rate | Notes |
|---|---|---|---|
| GET /context | Per call | $0.001 | High volume, low margin — designed for every sensor event |
| GET /jurisdiction | Per call | $0.0005 | Cached aggressively; jurisdictions change rarely |
| POST /simulate/plume | Per run | $0.05–$0.25 | Tier 1 (Gaussian) vs Tier 2 (AERMOD regulatory) |
| POST /simulate/flood | Per run | $0.10 | Includes watershed delineation + inundation mapping |
| POST /simulate/rf_coverage | Per run | $0.08 | Single node coverage polygon at given RSSI threshold |
| POST /rf/mesh/viability | Per run | $0.15 | Full mesh connectivity matrix with failure probability |
| POST /optimize/node_placement | Per run | $1.00–$5.00 | Consultants charge $50K+ for this manually |
| Site Calibration | Per site/mo | $200–$500 | Compounds in value — models improve every month |
Bundle discount: 20% off geog.ai API usage when paired with an active zooid.net Swarm or Colony tier subscription. Site calibration subscriptions are priced by vertical complexity — gas/plume sites start at $200/mo, multi-vertical enterprise sites at $500/mo.
Spatial intelligence as a dependency, not a product
geog.ai is the spatial layer your ZOOID verticals already need. Context resolution, propagation simulation, jurisdiction mapping, and a calibration loop that compounds — available as clean API calls, starting today.