The system, in plain terms.
A regulated industrial water user operating multiple borehole installations needed continuous, auditable consumption data and periodic reports filed with a national groundwater regulator. The existing manual logbook process was slow, error-prone, and difficult to defend if questioned by the authority.
The client needed a single system that captured field consumption data continuously, stored it reliably, and produced regulator-format reports their compliance team filed each cycle. The system also had to handle frequently intermittent field connectivity and a small number of installations spread across geography.
What needed to be solved.
Built a continuous telemetry and reporting platform replacing manual logbooks for regulator-mandated groundwater consumption reporting.
- Field telemetry needed a transport that survived patchy networks and constrained device hardware. HTTP polling was the wrong shape.
- The communication path between field devices and the central system needed to be secure end-to-end. Tampering with consumption data would create both compliance and operational risk.
- Reports follow a specific format and have to reconcile against the raw telemetry. Compliance teams need to trust the report and trace any number on it back to source readings.
- Operations and compliance teams needed visibility without depending on engineering for every question.
“For industrial IoT monitoring tied to regulatory reporting, the architecture needs to be split deliberately.”
What we set out to do.
- 01Continuous, telemetry-based monitoring of groundwater consumption across all installations
- 02Reliable data delivery from devices in low-bandwidth and intermittent network conditions
- 03Secure communication between field devices and the central platform
- 04Regulator-format report generation on demand and on schedule
- 05Dashboard usable by compliance and operations teams without engineering involvement
How we built it.
Field telemetry needed a transport that survived patchy networks and constrained device hardware. HTTP polling was the wrong shape. — Built the monitoring layer on MQTT. Devices publish to a broker that buffers and persists messages until the backend acknowledges them; QoS-2 guarantees no readings are silently dropped during outages, which would otherwise create compliance gaps.
The communication path between field devices and the central system needed to be secure end-to-end. Tampering with consumption data would create both compliance and operational risk. — Designed a secure communication layer over MQTT with TLS encryption for transport, certificate-based device authentication, and per-device topic namespaces on the broker. Each device has a unique credential, can only publish to its own topic, and is auditable in broker logs.
Reports follow a specific format and have to reconcile against the raw telemetry. Compliance teams need to trust the report and trace any number on it back to source readings. — The backend ingests and normalizes telemetry from the broker, runs validation rules against readings, and stores them in a relational store with full audit history. Report generation pulls from this store rather than from live telemetry — a stable, point-in-time view that ties back to specific device readings.
Operations and compliance teams needed visibility without depending on engineering for every question. — A React dashboard provides real-time consumption views, historical trends per installation, alerting on anomalies (sudden drops, spikes, device-offline), and self-serve report generation. Role-based access separates the compliance view from the operations view.
Auditable telemetry
Continuous, auditable groundwater consumption monitoring across all installations, replacing manual logbooks
What we used.
What changed in production.
Continuous, auditable groundwater consumption monitoring across all installations, replacing manual logbooks
Self-serve regulator-format report generation, replacing a multi-day reconciliation exercise
Secure, tamper-resistant data path from field devices to the compliance dashboard
Operations team gained visibility into anomalies — device failures, leaks, unusual draw patterns — that the manual logbook process did not surface
Lessons from shipping it.
For industrial IoT monitoring tied to regulatory reporting, the architecture needs to be split deliberately. The telemetry path is real-time, MQTT-based, and tolerant of network conditions. The reporting path is batch, validated, and auditable. Mixing the two creates either unreliable telemetry or untrustworthy reports. We have used this same split on subsequent industrial monitoring engagements.
The most valuable feature for the compliance team was not the report generator — it was the audit trail. Being able to point to the exact device, the exact reading, and the exact timestamp behind any number on a regulator filing is what made the system defensible.