Ontology
The typed world model
The Nexma Ontology is the typed world model at the center of every project. You define what exists and how it connects once — entity types, relationship types, properties, and constraints — and every map layer, panel, tab, validator, and Jax tool is generated from that single definition. Load a different ontology and the same platform becomes a different application, with zero code changes.
Core concepts
An ontology answers two questions about your domain: what kinds of things exist and what rules govern them. Four primitives express the answer.
- Entity types. The nouns of your domain — a water valve, an electric transformer, a drone waypoint, a forestry zone, a logistics depot. Each entity type declares typed properties (fields with units and tiers) so an instance is never an anonymous point on a map.
- Relationship (link) types. The typed edges between entities —
feeds,contains,serves,depends-on. Topology and structure become first-class, not implied by proximity. - Constraints. Engineering standards and domain rules, declared once and enforced on every write, so the world stays valid by construction.
- Generation. From these definitions the platform generates the application: toolbar buttons, map layer styling, inspector panels, write-time validators, and the tools Jax reasons with.
The ontology is the source of meaning. The Nexma DataStore is the source of truth — the ontology types the files the DataStore holds.
How it works
Define entity types, link types, and constraints in one model. Here is a compact, domain-agnostic example — an electric-grid fragment:
1{
2 "entityTypes": [
3 {
4 "id": "transformer",
5 "label": "Transformer",
6 "tier": "asset",
7 "properties": [
8 { "name": "capacityKva", "type": "number", "unit": "kVA" },
9 { "name": "voltagePrimary", "type": "number", "unit": "kV" },
10 { "name": "status", "type": "enum", "values": ["active", "planned", "retired"] }
11 ]
12 },
13 {
14 "id": "service_zone",
15 "label": "Service Zone",
16 "tier": "area",
17 "properties": [
18 { "name": "peakLoadKw", "type": "number", "unit": "kW" }
19 ]
20 }
21 ],
22 "linkTypes": [
23 {
24 "id": "serves",
25 "label": "Serves",
26 "from": "transformer",
27 "to": "service_zone",
28 "cardinality": "one-to-many"
29 }
30 ],
31 "constraints": [
32 {
33 "id": "no-overload",
34 "label": "Transformer load within rating",
35 "applies": "transformer",
36 "rule": "sum(serves.service_zone.peakLoadKw) <= capacityKva * 0.8",
37 "severity": "error"
38 }
39 ]
40}When this model loads, the application reconfigures around it: a Transformer layer and a Service Zone layer appear on the map, an inspector renders the typed properties, the serves relationship becomes a connectable edge, and the no-overload constraint runs on every write that touches a transformer or its zones.
One model, every surface generated
Hardcoded spatial software buries the data model in code, so every new entity type or rule is a release cycle, and the map, the forms, and the logic each keep their own drifting copy of the schema. The ontology removes that duplication.
| Surface | Generated from the ontology |
|---|---|
| Map layers | Entity types and their styling rules |
| Panels and tabs | Entity properties, grouped by tier |
| Validators | Constraints, run at write time |
| Object Explorer | Tabs per entity type, columns per property |
| Jax tools | Typed entities and relationships Jax reasons over |
Because every surface reads the same typed model, the world means the same thing everywhere. Change the model and every surface adapts — there is no separate schema to keep in sync.
Evolving the model
The ontology is not a one-time setup. Extend it mid-project and every surface reacts instantly — no migration, no redeploy.
- Add a property. "Add a maintenance-interval field to transformers." The inspector, the table column, and Jax's view all gain the field.
- Add a type or relationship. Introduce a new entity type or link and the corresponding layer, tab, and connector appear.
- Add a constraint. New rules begin validating future writes immediately.
Ontology versions are tracked, so model changes are reviewable and reversible like any other change. Most teams start from a proven domain template and tailor it rather than modeling from a blank page.
Ontology and skills
A project binds one ontology and N skills. The two play different roles.
- The ontology is immutable per project. It is the fixed world model the project is built on; you do not swap the ontology under a running project, because every object, layer, and constraint is typed against it.
- Skills are swappable. A Skill is a domain package targeting an ontology — Jax's system prompt, tool bindings, capability toggles, and validators for a particular way of working. You can add, remove, or swap skills on a project without touching the world model underneath.
This split keeps the typed foundation stable while letting capabilities evolve. The same electric-grid ontology can host a planning skill today and an outage-response skill tomorrow.
Where to go next
- Nexma DataStore — the versioned filesystem the ontology types and gives meaning to.
- Object Explorer — browse and query every instance through the active ontology.
- Skills — the swappable domain packages that target an ontology.
- Spatial Branches — branch and merge changes to the world with full history.