Nexma DataStore
The spatial filesystem
The Nexma DataStore is the spatial filesystem that holds every project's spatial state — designs, feeds, runs, automations, and session memory. It is the single source of truth. Every view in Nexma — the globe, the Object Explorer, panels, tabs, and Jax — reads from and writes to the same DataStore. One write, and everything reacts.
Core concepts
The DataStore replaces scattered shapefiles, databases, and tile caches with one versioned, branchable filesystem that humans and the agent share.
- A filesystem, not a database. Files have paths, contents, and history. They compose, fork, diff, and merge. Every primitive an engineer needs to coordinate work is already there, and an autonomous agent can reason about paths and contents as naturally as a person can.
- Single source of truth. There is no separate "AI workspace." Jax writes to the same files a human would edit. Diffs are reviewable; conflicts are mergeable.
- Typed by the ontology. The DataStore stores geometry and attributes; the ontology gives them meaning. A water valve and an electric transformer are both files — what they are comes from the active ontology.
- Reactive. All views render reactively from the store. A new feature in
designs/current/appears on the globe within a frame; a new feed infeeds/populates dependent panels immediately.
How it works
Jax operates the DataStore through eight generic primitives — never through domain-specific tools. The same eight tools work for fiber, water, drone corridors, or logistics.
| Primitive | What it does |
|---|---|
Read | Read a file with offset/limit pagination |
Write | Create or overwrite a file with full content |
Edit | Patch an existing file with find/replace |
Delete | Remove files by path or pattern |
Glob | Find files by pattern |
Grep | Search across file contents |
Run | Deterministic geo-math (haversine, centroid, snap-to-roads, isochrone) |
Solve | Optimization dispatch (MIP, VRP, CP, simulation, heuristic) |
See Primitives for the full contract and the Agent-computer interface for how Jax composes them.
Directory layout
A typical DataStore is organized by purpose. The examples below rotate across domains to show the structure is generic, not tied to any one vertical.
1_meta/
2 ontology.json # Active world model — types, links, constraints
3layers/
4 zones/ # Service areas / districts (polygons)
5 assets.geojson # Existing infrastructure (valves, poles, sensors)
6 endpoints.geojson # Customers, meters, waypoints
7designs/
8 current/ # Working design on the active branch
9 baseline/ # Reference for comparison
10feeds/
11 weather.geojson # Live data feeds (auto-render if spatial)
12 fleet-telemetry.geojson
13runs/
14 2026-06-05T10-22Z/ # Solver runs with inputs and results
15automations/
16 daily-replan.json # Scheduled or event-driven workflows
17sessions/
18 jax/ # Conversation history per session
19selections/
20 current.geojson # Ephemeral selectionsSpatial files (.geojson) render on the globe automatically. Application code lives in the repo, secrets are handled by the integration layer, and long-form documents belong in a knowledge base — the DataStore carries spatial state.
Persistence and history
The DataStore is database-backed. Reads and writes are durable across sessions, across team members, and across desktop and mobile. Earlier prototypes were in-memory; that limitation is gone.
- Every write is versioned. Nothing overwrites in place without a record. The before-state is always recoverable.
- Point-in-time replay. Check out any prior state of the world for a design review or an audit, without a separate backup system.
- Branchable. Spatial Branches layer real version-control semantics on top — fork the live state, design in isolation, diff, and merge with a full audit trail.
Because the store is versioned, teams move fast without breaking the live world. Every edit is reversible and attributable.
Reactivity and scale
Writes propagate instantly. Maps, tabs, and panels re-render from the same files the moment they change — no refresh, no polling, no sync jobs. Adding a new data feed requires only writing its data to feeds/; spatial feeds appear on the globe and feed dependent views without any wiring.
The store is engineered to scale from a single site to a national network — billions of features with predictable, low-latency reads. Storage and compute scale independently, so you grow without migrations or re-architecture.
Where to go next
- The Ontology — the typed model that gives the DataStore meaning.
- Spatial Branches — branch, diff, and merge spatial state with full history.
- Object Explorer — the typed instance browser onto the DataStore.
- Primitives — the eight tools Jax uses against the store.