Ingest from mixed vendors, agree a common vocabulary, and publish through interfaces that other systems can actually consume.
Most city data projects end with a screen in a control room and a database nobody else can read. Three years later the hardware is replaced and the history is gone, because it was never modelled — only stored.
The platform is built around four jobs, in this order.
Devices from us and from other suppliers arrive with different names, different units and different clocks. Ingest normalises identity, timestamp and unit at the edge of the platform, so a water level from three vendors is comparable in one chart.
A data dictionary is delivered with the project: what each point means, its range, its expected update interval, and who owns it. Without this, a replacement device six months later silently breaks every rule built on the old one.
REST and MQTT interfaces for read access, webhooks for events, and scheduled exports for the teams who still work in spreadsheets. The data leaves the platform; it does not have to be re-entered.
Device health, firmware state, alarm acknowledgement and an audit trail of who changed what. An alarm that nobody acknowledges is treated as an open incident, not a lost notification.

Deployed on your servers, no external dependency. The usual choice for authorities and operators with data residency rules.
Read more →02 · HOSTEDWe run the instance and the upgrades; you get an account and an API key. Fastest route to a working pilot.
Read more →03 · HEADLESSNo console at all — the platform publishes into your existing systems and you keep your own front end.
Read more →Send a sample of the data you receive today. We will tell you what can be normalised and what will need a gateway.