NEXUS AI PLATFORM
Twelve pods. One connected platform. Inside your boundary.
Nexus connects the systems a utility already runs, centralizes what they hold, and adds AI that answers across them and acts in the system of record — on the models you choose, inside your own infrastructure.
Your boundary
Data stays inside your infrastructure. Communication is encrypted end to end, with connected systems and with the model alike. The platform is closed by default: no external access is required or permitted unless you ask for it.
Your model
Nexus is not tied to one AI provider. Run the models you choose, on premises or in your own cloud, and reuse subscriptions you already pay for — including different models for different groups of users at the same time.
Your pace
Functionality ships as self-contained pods, and pods do not depend on one another being installed first. Start with the one or two that answer this quarter's problem and add the rest when the work calls for them. Nothing here needs a platform-wide programme before it does anything useful.
Four steps, in this order. Everything a pod does sits on top of them.
-
Connect once
Where a pod has to reach a system outside the platform, an administrator registers that system and connects to it by API or by a direct database connection. The connection and its mappings are defined once, not again per project.
-
Centralize
What those systems hold becomes available in one place, to every pod, under the access rules you already apply to your people.
-
Inform
Questions are answered across systems, in plain language, without the person asking needing to know which system holds which field.
-
Act
The platform writes back to the system of record, inside the rules you set, with what was done and by whom recorded as the write happens.
A crew member asks a question from the messaging client they already use. Nexus answers against the network, not against a document about the network.
Platform overview
What Nexus does and where it sits against the systems you already run. No registration.
Every pod runs on the same platform, under the same access rules, and each one stands on its own. Start with whichever matches the problem in front of you.
Connectivity
Set up your own connections and APIs. Added when a pod has to reach a system outside the platform.
-
Connect a system once and every pod can use it, so nothing has to be re-integrated project by project.
Available now
Core pods
The ones most clients end up running. Ask, act, orchestrate and report across the connected estate.
-
Designers ask in plain language and the work happens inside Smallworld, with network integrity checked before anything is posted.
Available now -
The GIS job queue and the job servers look after themselves, and a failure tells you at the time instead of surfacing days later.
Available now -
Ask across every connected system in plain language, then share the reports and dashboards that come back rather than exporting them.
Available now -
Every layer and every connected system on one map in the browser, with plain-language questions over all of it.
Available now
Specialist pods
One job each, with a simplified map of its own. Added when that job is the one in front of you.
-
Someone else’s drawing arrives as a file and leaves as a checked project in your GIS.
Available now -
Drop a pin where the customer is and get back a designed, rule-checked project sitting in your GIS.
Available now -
Your own team corrects displaced network geometry, and the patterns they build up get reused from one area to the next.
Available now -
Prune where the network actually fails rather than where the calendar says, with everything from field collection to the finished work order in one place.
Available now -
The utility's own telecom network — to splice and port level — on the same map as the grid it keeps running, with joint use alongside.
Available now
Delivered with maintenance and support
Applied to your environment rather than licensed as separate pods.
-
Operator
An autonomous service desk — for example, integrated with ServiceNow.
Available now No separate page -
MD Studio
A Magik/VMDS engineering workspace.
Available now No separate page
Security & data
Where the data sits, where the model runs, who can see what, and what gets written down as the platform acts.
Deployment
Where it can run and what a sizing session covers. No reference figure, for a reason the page explains.
Videos
Every public recording in one place, with nothing to fill in first.
Spatial Studio is where users look and ask. The specialist pods are where they act. Workspace is where results are consolidated into reports and indicators.
The specialist pods carry deliberately simplified single-layer maps — the electrical network, vegetation, joint use, external layers. Spatial Studio is where those layers are seen together.
AI-centric
Intelligence is built in rather than bolted on. The platform retrieves and cross-references information and takes real actions on connected systems.
Modular
Functionality ships as self-contained pods, deployed and tailored per client. You add the ones that match the work in front of you.
Cloud-agnostic
The same container image runs on every target — a Kubernetes cluster in any major cloud, on premises, or a hybrid of the two. Only the orchestration layer differs.
Model-agnostic
No tie to one AI provider. Different models can serve different users at the same time, and subscriptions you already pay for can be reused.
Self-contained and secure
Data stays inside your infrastructure, communication is encrypted end to end, and nothing reaches outside the network unless you enable it.
Each connection is made by API or by a direct database connection. Once it is defined, every pod can work from it.
- GE Smallworld
- Esri
- 3GIS
- SAP
- Maintenance systems
- ADMS — read only, from a non-operational copy
- Weather-forecast services
Connecting to Esri or another GIS is interoperability. Nexus reads and writes alongside the systems you run; it does not replace them, and they stay the system of record.
Nexus is not an ADMS. It reads from a non-operational copy and takes no part in operating the network.
Thematic data does not have to wait for the GIS
Thematic data can live on the platform rather than in the GIS. A utility part-way through a GIS version upgrade does not have to wait, and does not have to open a change window in the GIS to start getting value. Moving that data into the GIS later stays an option rather than a precondition. The platform is the stable point of access: the GIS version behind it changes, the connection is repointed, and users keep the same interface and the same profiles.
Who can see what
Users authenticate against your corporate directory. Access control is applied in four places — at the platform, within each pod, on the map, and in query responses — so a profile that cannot see a layer cannot read it out of an answer either.
A technical session covers your estate, where the platform would run, and which pods come first.
Book a technical session