A building integration demo should test meaning

Design proposal | Logic Foundry | October 12, 2026. This article proposes a demonstration format for property teams, controls providers and system integrators. The examples are fictional. The exercise has not been conducted by Logic Foundry and does not establish a working integration or measured outcome.

1. Begin with the question an operator must answer

Imagine a fictional demonstration in which a temperature value arrives in a portfolio dashboard. The number changes, the connection appears active and the chart looks convincing. Before judging whether the demonstration supports an operational use, ask a more specific question: can someone explain what the value represents and which decision it could inform?

For this proposed review, choose one modest question, such as whether a reported space temperature is suitable evidence for investigating an occupant complaint. The demonstration should then make the relevant context inspectable. A broad promise to connect all building data is harder to assess than a bounded example with an explicit limitation.

The purpose is not to turn an introductory product demonstration into a full commissioning exercise. It is to identify what has been shown, what has merely been described and what remains to be agreed for a particular building. Keep those three categories separate in the notes.

2. Follow one value through its interpretation

Ask the presenter to identify the property, equipment or space, source point and displayed field for the example. A familiar label is useful, but the proposed review should also show how the source is associated with the intended location. Record who would approve that association and how an incorrect mapping would be corrected.

In the fictional temperature example, distinguish a measured room value from a target setting or a calculated value. Those may all look like temperatures, but they answer different questions. The demonstration notes should identify the meaning claimed by the source and any transformation applied before display.

Make units explicit at the source and destination. If a conversion is involved, ask for a simple example that a reviewer can follow. The proposed acceptance question is whether the team can explain the displayed result, not whether a chart looks plausible. Do not treat the absence of an obvious error as proof that every point has been mapped correctly.

3. Make time part of the demonstration

Ask what each timestamp means: when the observation was made, when a receiving system obtained it, or when a screen was refreshed. These are proposed questions for the provider, not assumptions about how any particular product works. A demonstration should state which times are available and which are unknown.

Use a fictional delayed observation to explore the distinction. Suppose an old reading reaches a screen after a connection is restored. Would the user be able to distinguish that observation from a new one? Ask the presenter to explain the intended behaviour and identify whether it has actually been demonstrated.

Agree what freshness would mean for the chosen use before evaluating it. An occasional review of historical conditions and a time-sensitive operational decision may need different evidence. This article does not prescribe a universal update interval or a threshold suitable for every building.

4. Include an incomplete case

A successful example can show the intended path. An incomplete example can reveal what a reviewer would need when that path breaks down. In an isolated demonstration using synthetic data, consider an absent unit, an unknown equipment mapping or an observation whose timestamp is missing.

Ask whether the proposed interface would label the uncertainty, prevent a misleading interpretation or require someone to resolve it. If the behaviour cannot be demonstrated, record it as an open question. Avoid silently converting an unanswered question into an accepted capability.

Keep this exercise separate from live controls. There is no need to disconnect operating equipment, change settings or grant write permissions to discuss these cases. A mock record or a prepared test environment can expose the communication problem without changing a building's operation.

5. Agree who maintains the meaning

A useful discussion should extend beyond the first connection. In this proposed review, ask what would happen if equipment were replaced, a point were renamed or the intended use changed. Identify who would review the mapping and how the operating team would learn that an earlier interpretation may no longer apply.

The owner, controls provider and integration team may hold different pieces of the context. Rather than assume one party owns everything, list the specific questions each can answer. Separate responsibility for source configuration, interpretation in the receiving system and approval of an operational action.

Ask what a support handover would contain. A small example could include the mapping decision, an explanation of units and timestamps, known limitations and a contact responsible for unresolved interpretation. This is a suggested deliverable to discuss, not a claim that a particular vendor provides it.

6. Try a short demonstration review

Readers could prepare three synthetic records for one fictional asset: a complete observation, a delayed observation and an observation with missing context. Before viewing the demonstration, write down what a reviewer should be able to identify in each case. Keep the intended use narrow and avoid real occupant or customer information.

Invite a facilities operator and a technical reviewer to assess the same examples independently. Record their explanations, unanswered questions and disagreements. Distinguish evidence visible in the demonstration from statements about future configuration or additional services.

The hypothesis is that this format could expose interpretation gaps earlier in a project discussion. It can test whether the demonstration communicates meaning clearly to those reviewers. It cannot establish reliability across a portfolio, cybersecurity assurance, energy savings or suitability for autonomous control.

Two discussion prompts may help: Which field in your current demonstrations requires the most verbal explanation? Who would notice and resolve a changed equipment mapping after handover? Answers can help define a focused follow-up demonstration without implying a purchase, partnership or implementation commitment.

CORE-FM currently supports properties, assets, work orders, preventive maintenance and sensor monitoring. Logic Foundry's confirmed research includes BMS API integrations, digital twins and future reporting and decision tools. The demonstration format here is a proposal for learning and discussion, not a claim of a shipped BMS integration, tested partner connection or release commitment.