Interoperability Is an Acceptance Test

Connection is not understanding

Two systems can exchange data and still disagree about what it means. Asset names, units, time zones, operating states and space hierarchies can differ. A successful API call proves transport; it does not prove that a maintenance engineer or analytics model can interpret the result correctly.

Hong and Li’s guidance calls for clear data and software documentation in building-AI work [HONG]. JLL identifies data-related workflows as a CRE technology priority [JLL]. Osmos’s practical conclusion is that interoperability should be specified as an observable acceptance result, not a generic feature in a proposal.

Write the test around a complete use case

Choose a decision that crosses systems. For example, a validated equipment anomaly should reach the maintenance platform with the correct asset identity, supporting trend and urgency, and its final status should return to the analytics workflow. The test should include both the successful route and an exception.

Specify what must survive the exchange: identifiers, units, timestamps, quality flags, provenance and relevant attachments. Confirm how duplicate records, missing values and incompatible statuses are handled. Silent substitution may be convenient for software but dangerous for a user interpreting operational evidence.

Figure 1. The accountable operational loop Original Osmos Global conceptual framework, 2026. Not a measured dataset. Prepared 1 September 2026.

What this means: An alert earns value only through a verified operational outcome.

Test change and failure, not only the happy path

A working interface can break when a supplier changes an endpoint, an asset is renamed or a network link fails. Acceptance should therefore examine the response to interrupted communication, delayed data and schema changes. The system should expose the problem rather than continue displaying stale information as current.

Assign ownership for monitoring and repair. If every supplier says the fault is outside its boundary, the buyer carries the integration risk. A joint responsibility matrix should explain who diagnoses the issue, who communicates with users and how the service is restored.

Make commercial terms match technical promises

Clarify whether interfaces, data exports, API usage and future connectors are included in the price. Define support obligations when either connected system changes. The implementation budget should not assume that an undocumented custom integration will remain free to maintain indefinitely.

Require a practical exit test. Can the organisation retrieve the asset hierarchy, historical records, quality flags and workflow history in a form another provider can use? A large export that lacks definitions or relationships may satisfy a clause while leaving the organisation operationally dependent.

Illustrative decision rehearsal

An illustrative integration test sends a confirmed fault from analytics to a maintenance system. The ticket arrives, but its asset identifier has been converted into free text and the evidence link requires a separate administrator account. Technically the interface worked; operationally the technician still has to search for the equipment and request access to understand the task.

Acceptance should therefore be observed by the people who perform the work, not only the integration team. Ask a technician to use the ticket, identify the asset, inspect the evidence and return the result through the normal workflow. Measure the manual steps and exceptions encountered without inventing a target that the organisation has not agreed.

Then change one element under controlled test conditions: delay a message, rename a test asset or make a non-critical source temporarily unavailable. Confirm that the interface exposes the exception and preserves enough information for reconciliation. The test should not alter live safety-critical systems.

The first-cycle report should list which complete workflows passed, which passed with restrictions and which remain unsupported. Tie payment or acceptance milestones to those agreed outcomes where appropriate. A connector count is not a useful substitute. The buyer needs evidence that meaning, permissions and feedback survive the journey between systems, because those are the conditions under which integration creates operational value rather than additional administrative work.

Use acceptance as a learning checkpoint

Record the observed outcome of each test, unresolved exceptions and any agreed limitation. Acceptance should not erase known defects; it should make the remaining risk visible and assign a correction plan. Re-test decision-critical integrations after material changes rather than assuming the original certificate remains sufficient.

The cited sources do not prescribe a universal interface architecture or protocol. The proposed tests are original Osmos recommendations. Their value is in turning an abstract integration promise into evidence that the building’s information can support the intended work, including during change and failure.

Source notes

[HONG] Tianzhen Hong and Han Li. Good practices for documenting AI-based studies on energy and buildings. Energy & Buildings / Elsevier; author copy hosted by Lawrence Berkeley National Laboratory, 2026-01-20. Sections 2, 3.1–3.6 and 4; pp. 1–4. DOI: 10.1016/j.enbuild.2026.117043. Accessed 1 September 2026. https://eta-publications.lbl.gov/sites/default/files/2026-06/1-s2.0-s0378778826001039-main.pdf [JLL] Yuehan Wang. Reality check: The true pace and payoffs of AI adoption in corporate real estate. JLL, 2025-10-27. Key highlights; AI pilot selection; Lessons learned. Accessed 1 September 2026. https://www.jll.com/en-hk/insights/global-real-estate-cre-technology-survey

Editorial and visual note

This is original Osmos Global analysis informed by the cited publications. Reported findings are distinguished from Osmos recommendations and illustrative scenarios. Source findings and trademarks remain attributable to their owners. Original visual designs do not imply endorsement by source organisations. The content is general research and does not replace site-specific professional advice.