Three speeds of building data

There's a question worth asking before any sensor goes on any wall:

What alarm do you actually want to wake up to at 2am?

If the answer is "not this one", it has no business being a real-time alert.

Most building data isn't midnight data. Treating it like it is — that's where dashboard fatigue starts.

Three speeds of data sit inside a building, and each one wants something different from the people running it.

Real-time. The midnight call.

A burst main. A server room losing cooling. A school kitchen freezer failing on the eve of term.

A sensor reporting every 5–10 minutes is fast enough for any of those. Buildings move slowly. The thermal inertia of concrete and steel buys you minutes, not microseconds. The point of real-time isn't speed for its own sake — it's that someone gets a phone call.

Near-time. The 8am task.

A humidity spike on the top floor after Sunday's rain. A CO₂ profile that doesn't match how a room is meant to be used. A boiler firing into an empty wing on a holiday Monday.

Real findings. Material ones. Not midnight ones. They can't be fixed in the dark, and waking someone up trains them to stop looking.

These wait, then land as a ticket at the start of the next shift.

Transaction-time. The audit trail.

The continuous hot-and-cold water log that proves legionella temperatures held. The half-hourly electrical draw that builds the year's EPC story. The CO₂ baselines that show whether BB101 was met across a term.

This is the slow data. It pages nobody. It proves things, later, to the people who want proof — auditors, inspectors, board reports.

The point.

If every finding wakes someone up, no finding gets attention. The platform's job is to know which speed each finding belongs in, and act accordingly.

That's not a feature. That's the design.