Everyone's building the synthesis layer. Nobody's building the capture layer.

Why we spend our time in plant rooms instead of dashboards, and what that gets you.

There is a lot of work going into the layers that sit on top of physical infrastructure data. Ontologies to describe assets. World models to reason about them. Analytics platforms to chart them. All of it is useful, and all of it starts from the same assumption: that a live feed from the asset is already there, waiting to be queried.

Across most of the built environment it isn't. Buildings, plant, networks, and sites in the field: the assets are unmonitored, or they are read by hand on a monthly cycle, with nothing recorded in between. The gap between what the software layer assumes and what the estate actually produces is where every one of these projects quietly stalls.

The reason the data doesn't exist is physical

Getting a reading out of a pipe is not a software problem. It is a probe, a power budget, a radio survey, a gateway with somewhere to sit, and access to a plant room that someone has to unlock. None of that is solved by another dashboard, and none of it gets easier by being described more precisely in a schema.

It is also unglamorous, which is part of why the gap persists. The interesting-looking work is one layer up.

That is the whole thesis. The first site of any kind is genuinely difficult: you learn what the radio does inside that building, where the antenna has to point, what the probe tolerances need to be, how the readings should be identified. Once that is settled, the same work on the next site is close to a repeat.

What we actually hand over

Not a stack diagram. Three things:

Instrumented sites. Sensors in place and reporting continuously, with the radio, power, and access questions already answered on site rather than left as risks in a plan.

Data out via API. Readings and history queryable directly. Your systems consume the feed; you are not asked to move into ours.

Location and asset identity, attached at ingestion. Every reading arrives bound to a coordinate and an asset, so nothing has to be reconciled after the fact. This is the part that decides whether the data is usable a year later.

{
  "asset_id":  "site-01/plant-01/hwc-flow",
  "point":     [-0.24193, 51.47286],
  "metric":    "temperature_c",
  "value":     58.4,
  "ts":        "2026-09-04T06:12:03Z",
  "source":    "pt1000/ch2"
}

Temperature, flow, pressure, occupancy, energy: the ingestion path, the identity model, and the API do not change when the sensor does. That is deliberate. A capture layer that only works for one kind of measurement is a product, not infrastructure.

Where it stands

In summer 2026, hardware, gateway, and platform were field-tested in a working plant room, and production boards are now in validation. The first phase was delivered and paid. It was a small trial, and we would rather describe it accurately than dress it up.

The first vertical is water hygiene: continuous L8 and HSG274 temperature monitoring, sold white-label through contractors who already hold the client relationships. It was the fastest route to a real site with real compliance pressure behind it, which is exactly what you want the first deployment to have. It is not the product.

If you have an estate where the data does not exist yet, that is the conversation we want to have. Tell us the site, the assets, and where the readings need to land.