How can buildings share data across a district?

The tempting answer is to connect every building to a district platform and let it read whatever it needs. The better one is a set of agreed interfaces, each carrying a defined set of information with its meaning, quality and access rules intact. Each building publishes what the shared purpose requires, the district consumes it, and the building stays free to change its own systems as long as it keeps honouring the interface.

The place to start is the shared decision, meaning what the district actually needs to know or do. Only then should anyone specify the minimum information each building must supply to support it.

The information contract

The core document is an information contract, sometimes called a data-sharing specification, agreed between the district and each building. It begins with identifiers for sites, buildings, spaces, meters and assets, so that the same thing has the same name everywhere. It then defines what each field means: what the value represents, in what unit and over what interval. Get this wrong and comparisons mislead without warning; a district total becomes meaningless if one building reports instantaneous power and another reports energy accumulated over an hour under the same field name.

The contract also needs to state timestamps and time zone, and whether values are measured, estimated or calculated. It should carry quality indicators that distinguish good, suspect, estimated and missing values, and set the update frequency and latency the district can rely on. Finally, it fixes the access rules, meaning who may read each data set and for what purpose, and the change control: how either side proposes a change and how much notice is given.

Technical patterns

Whichever pattern is chosen, the interface should be formally documented. The OpenAPI Specification, maintained by the OpenAPI Initiative, is a widely used way of describing HTTP APIs in machine-readable form; the 3.2 line was introduced in September 2025, and its latest patch release, 3.2.1, followed in September 2026, while the earlier 3.1 and 3.0 lines remain published and in use.

Agreeing on meaning

Shared field names are a start, but larger districts benefit from a shared semantic model. ETSI's SAREF (Smart Applications REFerence ontology) is designed as a shared core model that lets different data models relate to each other without a dedicated mapping for every pair, and SAREF4CITY extends it for the smart-city domain. In city data ecosystems, the Open & Agile Smart Cities network's Minimal Interoperability Mechanisms (MIMs) set out a minimal, sufficient level of interoperability, including making data available through APIs and representing it in standards-based formats; it points to NGSI-LD as a modern standard for sharing information about real-world entities in a common, consistent way.

None of these guarantees interoperability on its own. The parties still have to agree which version and which subset they will use, and how conformance will be checked.

Keeping buildings autonomous

District access must never become a dependency for a building's own controls. Most exchanges should be read-only. Where the district can make requests that change operation, such as asking for demand to be reduced, the arrangement has to define who authorises them, the limits each building sets, how a building rejects or overrides a request and what happens if the link is lost.

Missing data needs the same forethought. A building that temporarily stops reporting should appear as unavailable or stale. It must never silently contribute an old value to a current district total.

Putting the relationship in writing

The information contract describes the data. The parties also need an agreement about the relationship, particularly where buildings have different owners. It should state what the shared data may be used for, and that any new use needs fresh agreement. It should name who operates the district platform, who is responsible for each building's feed and whom each party calls when something breaks.

Personal and commercially sensitive data needs particular care. Consumption for a small tenancy, or access events, can relate to identifiable people or reveal a business's activity. The first question is whether such data is needed at all; where the purpose allows, it should be aggregated, and where personal data remains, privacy advisers should confirm each party's roles and obligations.

The agreement also has to settle money and reliance: who pays for the building-side connection, the platform and later changes, which uses depend on the data being right (recharging, for example), and what service level and remedy apply when it is not. It should explain how a new building joins, what happens to a building's history when it is sold or withdraws, how often the arrangement is reviewed and how disagreements are resolved.

On a privately managed estate these terms may sit in estate management agreements or leases; on a public campus, in an internal service agreement. Either way, legal advisers draft the document. The technical team's job is to make sure it describes what the systems will actually do.

A sensible order of work

The work begins with the shared decision and a named owner for it, followed by an honest list of what each building can supply today and at what quality. Version 1 of the information contract covers the minimum data set only, and the technical pattern is the one the least mature participating building can support. A pilot with two or three buildings, deliberately including the weakest, comes before the rest join in planned waves.

That testing should run end to end, with representative data from several buildings. It needs to show that:

• values, including their units and intervals, are interpreted correctly;
• permissions restrict each party to what it is entitled to see;
• stale and missing data are flagged;
• the district recovers properly after a building or the link has been offline;
• a change to the interface follows the agreed process.