From a water alert to a useful operational decision

1. Begin with the observation

A building operator needs more than a red indicator. An exception should identify the affected zone, the time window, the readings involved and the comparison being made. Is overnight flow above an expected baseline? Is the signal current? Did a maintenance activity explain the change? These questions should remain visible beside any suggested action.

Our interactive example uses invented readings and scenarios. It is a way to explore interface and workflow decisions, not a connection to a building, sensor network or customer installation. No action in the example dispatches a team or controls equipment.

2. Compare three explanations

The normal scenario represents a pattern with no highlighted exception in this sample. It does not establish that a real building is safe or free from faults. The possible-leak scenario represents an unexplained flow increase that needs investigation. The maintenance scenario provides operational context that may explain an unusual reading without confirming the cause.

Keep observations separate from interpretation. A review queue can preserve the original signal while a responsible person checks sensor health, occupancy, maintenance records and relevant site procedures. Record an explanation and who accepted it instead of simply clearing the alert.

3. Make the delay assumption explicit

For the possible-leak illustration only, assume a constant extra flow of 0.5 cubic metres per hour. Assume it continues until an effective intervention at the selected response time. The control accepts a delay from 0 to 72 hours. Estimated excess volume is therefore 0.5 multiplied by the selected hours. The model excludes travel, diagnosis, repair time and changing flow rates.

At 8 hours, the model gives 4 cubic metres of cumulative excess water. At 72 hours, it gives 36 cubic metres. The difference, 32 cubic metres, is potential avoided excess relative to the 72-hour scenario, under those same assumptions. It is not measured savings, an achieved result or a promise that an alert will lead to an effective repair.

4. Define the human response

Before connecting a real system, agree the operational handoff with the people responsible for the building. A useful alert should help them investigate, document a decision and follow the existing procedure.

• Confirm the source, timestamp, unit and quality of the readings.
• Check maintenance context and the appropriate local operating procedure.
• Assign an owner and record whether further investigation is needed.
• Use authorised personnel and approved procedures for any physical intervention.
• Review subsequent observations before treating the exception as resolved.

5. Validate before connecting a building

A real pilot needs agreed sensor coverage, calibration evidence, data-quality checks and historical examples of both genuine exceptions and benign variation. Evaluate missed events as well as false alerts. Confirm who can access readings, who acknowledges alerts and what happens when the connection fails.

Start with observation and review before considering control. Compare the proposed process with the operator’s current practice. Only measured, attributable results from a real deployment can support future performance claims; this small simulation supplies none of that evidence.