A quiet sensor is not always a healthy building

Research perspective | Logic Foundry | October 10, 2026. This article proposes a monitoring design and a small evaluation readers could conduct. It does not report a completed experiment or measured product results.

1. What does a quiet dashboard mean?

Consider a fictional portfolio where an air-handling unit has stopped generating temperature alerts. The latest number looks ordinary. An operator might reasonably read the quiet screen as reassurance. But the same display could result from a disconnected device that has not delivered a fresh reading. The operational question is whether the team can distinguish those situations before using the display to decide what needs attention.

A proposed principle is to represent the condition of the equipment separately from the condition of the evidence. A reading may suggest an ordinary operating condition while its age makes that suggestion unsuitable for a current decision. Conversely, a fresh reading outside an expected range may justify investigation without proving equipment failure.

2. Give data freshness its own meaning

For each monitored point, a proposed record would identify the property and asset, what is measured, the unit, the measurement time and the time the system received it. Those last two times answer different questions. A delayed message arriving now does not necessarily describe the building now. A device clock that is wrong creates another uncertainty that should remain visible.

Teams would also define the expected reporting pattern and how long a reading can remain useful for a particular decision. There is no universal interval proposed here. A value used to examine seasonal patterns and a value used to investigate a current comfort complaint have different requirements. Equipment specialists and responsible operators should define those requirements for the intended use.

An interface could then display separate statements such as data current, data delayed or data unavailable alongside the observed condition. These are proposed information states, not diagnostic conclusions. A missing value should not silently become zero, and a previously normal value should not silently become a statement that the equipment is currently healthy.

3. Match the response to the uncertainty

In the fictional example, an overdue temperature report could prompt an information-quality investigation: check the expected reporting pattern, the equipment association and the available communication-status records. It should not automatically become a repair instruction for the air handler. The cause might be a device issue, an integration issue, planned work or another explanation.

The responsible person also needs to know where to direct that investigation. A controls contractor, an IT team and a maintenance team may own different parts of the path. A short responsibility record can identify who checks the missing information, who decides whether another observation is needed and how the operational team will be informed. It should respect existing site procedures and avoid assuming remote control authority.

Across several buildings, a portfolio view could separate assets needing operational attention from points needing better evidence. Combining both into one red total would hide the difference between suspected equipment problems and unreliable visibility. Keeping the categories distinct is a design hypothesis to test with operators, rather than a claim that one layout works for every portfolio.

4. Design for the awkward cases

Freshness rules can be misleading if the reporting pattern itself changes. Some points report at regular intervals; a proposed integration may instead receive values only when they change. Maintenance windows, equipment shutdowns and intermittent connectivity also need explicit treatment. A rule written for one pattern should not be copied into another without review.

Reconnection raises a different question. If a device uploads a backlog, can the interface identify historical readings without making them look like live conditions? A useful evaluation would also include duplicate messages, incorrect units, clock errors and a point mapped to the wrong asset. Fresh data can still be wrong data.

Too many information-quality notifications could overwhelm the same people the design is meant to help. Grouping related communication failures is one possible approach, but grouping can also conceal an important individual case. The threshold for escalation, the owner of an unresolved issue and the handling of planned downtime should be agreed before relying on the proposed view.

5. A small exercise before live use

Use a permitted copy of non-sensitive historical readings or a clearly labelled synthetic dataset. Keep the exercise separate from live dispatch and building controls. Select a few representative points and write down the reporting assumptions and the decisions each point is intended to support. Do this before showing participants the test cases.

Prepare cases with ordinary fresh readings, fresh unusual readings, a stale last value, missing values and delayed historical messages. Ask operators to explain what they believe is known, what is uncertain and whom they would contact next. Record occasions when the display implies that missing evidence means normal operation, or when a communication problem is mistaken for an equipment diagnosis.

Compare the proposed display with the current presentation using the same cases. Review misunderstandings, unnecessary escalations and the time needed to choose a next step. A small exercise can reveal interface problems; it cannot establish annual savings, diagnostic accuracy or reliability across different building types. Logic Foundry has not conducted the experiment described here.

6. Questions for a portfolio review

Which current decisions depend on a reading being recent, and who has defined how recent is sufficient?

When visibility is lost, can your team identify an owner and a next step without treating the equipment itself as either healthy or failed?

CORE-FM currently supports properties, assets, work orders, preventive maintenance and sensor monitoring. Logic Foundry is researching sensor anomaly detection, predictive maintenance, BMS API integrations and future reporting and decision tools. The freshness model and evaluation described here are proposals for that wider discussion, not claims of a shipped integration, autonomous control or promised release.