DataStore-first architecture
One foundation, every view
Nexma is built on one idea: a single versioned, branchable spatial filesystem is the foundation everything else stands on. The Nexma DataStore is the source of truth, and every view, tool, and capability is a renderer over it.
Core concepts
A filesystem is the simplest foundation an autonomous agent and a human can both reason about. Files have paths, contents, and history. They compose, fork, diff, and merge. Every primitive an engineer needs to coordinate work is already there.
- One store, not many. Instead of a database, exported shapefiles, tile caches, and CAD files drifting apart, there is one filesystem that holds the whole world model: entities, relationships, geometry, constraints, feeds, runs, automations, and session history.
- Typed by the Ontology. The active Ontology types every object in the store, so tools, validators, and Jax all understand the world the same way.
- Versioned and branchable. Every change is a commit with full history. You can branch the live state, design in isolation, and merge back — Git semantics for the physical world.
- Persistent and real. The store is database-backed and durable across sessions, teammates, and the desktop and mobile apps. It is engineered for billions of features, not an in-memory cache.
How it works
Every surface reads from and writes to the same files. There is no application state that lives somewhere else.
1designs/current/ ← Jax writes a route here
2 │
3 ▼ one write
4 ┌─────┴───────────────────────────────────┐
5 ▼ ▼ ▼ ▼ ▼
6Map Table Graph Panels Mobile
7 (all re-render reactively from the same files)Write once and everything reacts. A new feature in designs/current/ appears on the map within a frame. A new feed in feeds/ populates live-data views immediately. A new ontology entity makes a new toolbar button, a new tab, and a new Jax capability appear at once — because all of those surfaces are generated from the same files.
There is no separate "AI workspace." Jax writes to the same files a human would edit. Diffs are reviewable, conflicts are mergeable, and every write is reversible.
One write, everything reacts
The reactivity is the payoff of having one source of truth. Consider a single change — moving an electric transformer to a new location:
| Surface | What updates from one write |
|---|---|
| Map | The transformer symbol moves; connected lines re-route their render |
| Table | The transformer's row updates its coordinates and any derived fields |
| Graph | The ontology graph reflects new or changed relationships |
| Validators | Constraints re-check; violations surface immediately |
| Jax | The agent sees the new state on its next read — no cache to invalidate |
| Mobile | Field crews see the updated position on next sync |
None of these surfaces holds its own copy of the data. They are all projections of the same files.
Contrast with the legacy stack
Traditional spatial stacks scatter data and pay for it constantly:
- Scattered sources. Shapefiles, PostGIS, tile caches, and exports live in separate silos that drift out of sync, so no one fully trusts a single source of truth.
- No history. Legacy stores overwrite in place. When something changes, the before-state is gone — no audit trail, no rollback, no scenario comparison.
- Brittle pipelines. Every consumer re-exports and re-projects the same data, so pipelines shatter the moment a schema or projection shifts upstream.
The DataStore replaces all of that with one versioned filesystem that every tool and the agent share — eliminating exports, re-projections, and sync jobs. You grow from a single project to a national network without migrations, because storage and compute scale independently.
What does not belong in the DataStore
- Application code lives in the repo, not the store.
- Secrets are handled by the integration layer and never written to DataStore files.
- Long-form unstructured documents belong in a knowledge base; the DataStore carries spatial state.
Where to go next
- See the store as a product surface: Nexma DataStore.
- Learn parallel workflows: Branches.
- Understand the typed schema: Ontology.
- See how the agent operates the store: The eight primitives.
- Browse instances of the world model: Object Explorer.