Real-Time Digital Twin

A real-time digital twin is a live, queryable model of your world — every asset, sensor reading, crew location, and constraint reflected as typed entities in one governed graph, updated as the field updates. For thirty years "digital twin" has meant a render: a 3D model of a factory or a city block, decoupled from the systems it claims to represent. A live twin is something else. The map is incidental; the graph is the product.

It is the same operating system — the DataStore as the graph, the Event Broker feeding it live, the DataBase holding its history, and Jax querying it in language.

What you can do

• Connect every system that already speaks. SCADA, GIS desktop, work-order systems, IoT brokers, and satellite feeds wire into the DataStore as typed entities. The twin is alive the moment the feeds land.
• Visualize from one truth. Render the same graph as a globe, a floorplan, a graph view, or a table. Switch surfaces without losing context, because each is a read off the same source.
• Query in natural language. "Which crews are behind schedule?" "What changed in the north field overnight?" Jax composes the answer against the Ontology and returns it with provenance.
• Govern what is true. Bind policy, constraints, and ownership to entity types in the Ontology. The twin enforces what it knows; deviations become alerts, not silent drift.
• Close the loop. When a sensor crosses a threshold or a window opens, Jax solves, writes the action back, and dispatches — with the audit trail attached and a human in the loop on demand.

Core concepts

A live twin is a typed graph kept current by live data, not a 3D scene. Three pieces make it real: the world model that holds the typed state, the live feeds that update it, and the time-aware backbone that remembers how it changed.

• The graph is the twin. Entities, relationships, and geometry live in the DataStore, governed by the Ontology. Because state is typed, the twin is queryable — not just visible.
• Live data keeps it current. Positions and readings stream through the Event Broker into the same entities, so the twin reflects the field in near real time.
• History is part of the model. The DataBase retains every change with its timestamp, so "what did this look like last Tuesday?" is a query, not an archaeology project.

Operations become queryable, not just visible. The shift from a render to a typed graph is what turns a digital twin from a presentation into an instrument.

How it works

Feeds land as typed entities, surfaces render off the graph, Jax answers questions against it, and automations act when the world crosses a rule.

Every surface is a projection of the same graph, so a reading that updates one entity updates every view at once.

Indoor 3D

A live twin does not stop at the property line. Nexma renders indoor environments — buildings, floors, rooms, equipment — as first-class spatial features in the same graph. A fiber drop that enters a building continues to the splice point on the third floor without changing models. Indoor environments are composed of three layers: structure (walls, floors, doors as extruded GeoJSON), equipment (racks, panels, sensors as typed points sharing the outdoor schema), and routes (cable runs and riser drops that snap to walls, ceilings, and floors). Because indoor entities carry the same schema as outdoor ones, cross-domain queries — "every camera within 50 meters of this asset, inside or out" — just work. Floorplans come in from PDF or DWG import, manual sketch, or a generated brief, and performance scales to roughly 10,000 indoor entities per scene.

Example

An operator runs a live twin of a regional water network.

1. SCADA telemetry, the GIS asset register, and field-crew positions wire into the DataStore as typed entities; the twin is live on connection.
2. A pressure sensor crosses its low threshold overnight; because pressure limits are bound to the pipe entity type in the Ontology, the deviation raises an alert.
3. An AgentEngine automation solves for the nearest qualified crew, writes a work order, and dispatches it — with the human-approval gate the operator configured.
4. In the morning, the operator asks Jax "what changed in the east district overnight?" and gets a sourced answer drawn from the DataBase history.
5. The same graph renders as a globe for the control room and a floorplan for the pump-station interior, both current to the last reading.

Swap the Ontology and the same connect-visualize-query-govern-automate loop runs a twin of a power grid, a logistics fleet, or a building portfolio. The twin mechanics are generic; the meaning comes from the world model.

Where to go next

• DataStore — the graph that is the twin.
• Live data — the streams that keep the twin current.
• DataBase — the time-aware history behind every "what changed" question.
• Nexma AgentEngine — close the loop with governed automation.
• Spatial Analysis — ask rigorous spatial questions of the live twin.