Projects & resources
Your business, as code
A project is your business, as code. Every design you draw, every rule your team follows, every asset on the map, every automation, every audit trail — Nexma keeps all of it as one editable, queryable, version-controllable thing.
Core concepts
A project is the container for a piece of work. It binds one Ontology, any number of Skills, and all the spatial state those produce — held in the Nexma DataStore. Inside a project you run sessions (Jax conversations) and manage resources (the entities, selections, and feeds that make up the work). The project, not any single view, is what persists.
| Element | What it is |
|---|---|
| Ontology | The typed world model the project is built on — immutable per project |
| Skills | Domain capability packs Jax can use — swappable at any time |
| Resources | The spatial state in the DataStore — entities, links, selections, feeds, results |
| Sessions | Individual Jax conversations within the project |
What "as code" means here
You don't write code to get this. The pitch is closer to: your operation finally behaves the way software does — composable, auditable, reproducible — without giving up the visual workflow your team is used to.
- Designs and rules live together. A constraint isn't a sticky note on a planner's desk. It's part of the project; the platform enforces it; Jax respects it; reports cite it.
- Edits are real and reversible. Anything you change is recorded. You can roll back any edit, compare any two points in time, and replay how the project reached its current state.
- AI and humans share the same artifacts. Whatever Jax produces is the same kind of object you'd create by hand. You edit Jax's output; Jax builds on yours. There is no parallel AI workspace that drifts out of sync.
- Field, office, and AI see the same project. Crews on the mobile app, designers in the office, and Jax in chat all read and write the same canonical state.
Ontology and Skills: the binding
A project binds exactly one Ontology. That choice is deliberate and fixed: the world model defines what every entity, relationship, and constraint means, so it can't change underneath the data without breaking it. Skills, by contrast, are swappable — add a new capability pack to give Jax more to do, or remove one, at any time. One world model, many capabilities.
See Ontology and Skills overview.
Sessions and resources
A session is a single Jax conversation — a thread of work against the project. Run several in parallel: one session sketches a feeder layout while another investigates a service complaint. All of them read and write the same DataStore, so work done in one session is immediately visible in the others.
A resource is any piece of project state: an entity, a relationship, a drawn selection, a connected feed, a Jax result. Resources are what the Globe renders, what the Object Explorer lists, and what Jax operates on.
Sharing and governance
Projects belong to your organization, not to an individual. Members access them according to their roles, and every change is attributed to an author with a timestamp. Because edits are durable and reversible, sharing a project is safe: a reviewer can see exactly what changed, when, and why, and can roll back anything that shouldn't have happened.
When a regulator, customer, or auditor asks "why was this designed this way," you have the full chain of reasoning — not a guess.
Three ways to interact
Most teams mix all three:
- Visually, through the Globe and side panels.
- By asking Jax — "list every cabinet within 200 m of this road," "move every closure that violates the new bend-radius rule."
- Directly, when you want to inspect or hand-edit a specific record.
The point isn't to pick the right interface. It's that whichever you choose, you're working on the same project — and your work is preserved.
Where to go next
- See the container in action in The workspace.
- Understand the state layer in Nexma DataStore.
- Control access in Authentication and access.
- Walk a full project lifecycle in Delivering a use case.