RESOURCES
Find the path that matches your role.
Explore the platform by responsibility, by capability or by operational domain — and see exactly what is published, what is available on request, and what does not exist yet.

START HERE
Start with what you need to accomplish.
Three ways into the same material, depending on the question you arrived with.
Deciding
You are deciding whether this fits
Start with what the platform is made of and how the pieces relate, then look at the domains closest to your own infrastructure.
Integrating
You are integrating equipment
Start where the device meets the platform: how protocols are instantiated, how payloads become metrics, and what a command has to satisfy before it is sent.
Operating
You are operating an installation
Start with the screens people will actually work in, the rules that run without them, and the access and audit model behind both.
THE PLATFORM
Explore the platform, capability by capability.
Nine pages, one per layer of the product. Each one describes what the platform actually does at that level, not what it could be configured to look like.
Digital Twins & Device Lifecycle
Models, versions and instances — how a category of equipment becomes a managed digital asset with its own serials, location and state.
Connectivity & Integration
Protocol instances as containerised services, MQTT and HTTP, ChirpStack and LoRaWAN, codecs and enrollment templates.
Data, Metrics & Commands
Parameters, metric templates and command templates — the dynamic attributes that make heterogeneous equipment comparable.
Rules & Automation
How rules evaluate metrics and states, and how a command is validated before it leaves the platform.
Dashboards & Visualization
The widget palette, the per-version and per-system dashboards, and how they are edited by dragging and resizing.
GIS & Spatial Operations
The interactive map: systems, devices and groups as layers, with filters, shapes and device popups.
Security & Audit
Users, groups, roles and permissions down to menu, entity and action — and the central audit trail behind them.
Enterprise Administration
Nomenclators and platform-wide configuration: states, units of measure, data types, organisational units and map profiles.
Developer & Integration Tools
What is available for extending the platform and connecting it to the systems you already run.
BY DOMAIN
Explore by operational domain.
The same platform foundation, described for the equipment and the vocabulary of a particular domain. Where a scenario is not documented as an existing configuration, it is labelled as an illustrative example.
Solutions
What the platform is configured to do — lighting, environment, metering, process infrastructure, buildings, video and city operations.
Industries
Who operates it — municipalities and public infrastructure, utilities, industrial and critical sites, building portfolios, and defence-site infrastructure.
ON REQUEST
Technical material, when you need it.
Some material is not published on the site because it is written for a specific evaluation. It exists, and it is shared on request.
On request
Platform documentation
The complete functional documentation: architecture, registry and device modelling, connectivity, dynamic attributes, rules, dashboards, maps, security and the screen-level specification.
On request
Technical specifications
The technical specification of the underlying application platform, including installation, administration and operation, and the security component.
On request
Integration support
A working session on your specific equipment: how the payload is read, which metric and command templates it needs, and how it is enrolled.
SCOPING
What we need to evaluate an integration.
Eight things. With them, the answer about effort and fit is a technical one rather than an estimate.
01
Identity
What the device is, who makes it, and which version of it is installed — the information that becomes a model and a version.
02
Connectivity
Which protocol it speaks, through which gateway or network, and whether a protocol instance for it already exists.
03
Payload
A real message, and what each field in it means — that is what a metric template is written against.
04
Metrics
Which values must be stored, with which data type and unit, and whether any need preprocessing before persistence.
05
Commands
What the device can be asked to do, with which parameters and value ranges, and how a response is confirmed.
06
Rules
What should happen automatically — by schedule, by threshold, by state — and what must stay a manual decision.
07
Visualisation
Who looks at it, on which screen, and whether the map matters as much as the dashboard.
08
Testing
How the integration can be exercised: a reference payload, a test unit, or a pilot site.
NEXT STEP
Bring us your integration challenge.
Describe the device and the message it sends. We will tell you the shortest path from that payload to a working operational model — including the parts that are not worth doing.