Give building data a shared meaning

Define the information your building needs.

A building can export thousands of values and still be difficult to understand. A point named L03_AHU1_T1 might be a supply-air temperature, a return-air temperature or an old label attached to a replacement device. A successful connection does not resolve that uncertainty.

An ontology supplies shared concepts and relationships: what an asset or point is, where it belongs and how it relates to other things. A naming convention makes records recognisable to people. A points schedule specifies the information the project needs. A payload contract defines the messages; a protocol carries or exposes them. Some technologies cover several of these roles, but each decision still needs an answer.

Identity

Which exact asset or measurement is this, throughout its life?

Human name and physical label

How will someone recognise it in the building, drawings and register?

Semantic model

What does it mean, and what is it related to?

Point and message contract

Which value, unit, timestamp, quality and permitted action are expected?

Interface and transport

How does it reach the authorised application, and what happens when delivery fails?

Good Buildings helps clients define the information outcomes, compare models and translate the chosen approach into requirements. We coordinate the review of delivery evidence with the appointed specialists, from the source record to the information people use.

Compare three approaches to shared building information.

Brick: make relationships explicit.

Brick describes building assets and their relationships using an extensible vocabulary. Its RDF class hierarchy and directed graph support questions that depend on connections, rather than labels alone: which equipment serves a space, which points belong to it, and which readings should an application retrieve?

Where it fits. Consider a mixed-vendor portfolio where several applications must ask consistent questions across differently named systems. Explicit relationships can give those applications a common route to relevant information. The Brick tooling supports graph querying and inference; its SHACL validation facilities can check defined constraints.

What to confirm. The graph must be populated and maintained. Someone still has to resolve equipment identities, relationships, source references and exceptions. The team needs suitable graph and validation skills, or a supported product that supplies them. A valid model does not prove that a sensor is correctly installed or that the connected application interprets every relationship correctly. For a narrowly scoped retrofit with one consuming application, the extra modelling and governance may exceed the immediate benefit.

Project Haystack: structured descriptions close to operational data.

Current Haystack documentation defines vocabulary, taxonomy and relationships. Entities are tag dictionaries with identities and references; it is inaccurate to assess the current model as merely an uncontrolled list of labels. Its point model distinguishes functions, value types, units and current or historical status.

Where it fits. In a brownfield project whose operating tools already consume and export an agreed Haystack profile, retaining that native capability can reduce avoidable translation. Tags and references can support an incremental onboarding process while the team resolves the existing estate. Haystack also specifies typed exchange formats and an HTTP API ; the chosen implementation must demonstrate the required operations and encodings.

What to confirm. Confirm the version, definitions, required relationships and custom-tag policy. Two products described as Haystack-enabled may use different profiles or support different operations. A typed exchange format is not equivalent to an arbitrary JSON export, and flattening a model into ordinary CSV can discard types and relationships. The practical risk is inconsistent implementation and conversion, not an assumed absence of an ontology.

Digital Buildings: define expected equipment information and validate onboarding.

Google's Digital Buildings project uses YAML as its primary ontology configuration source and can generate an RDF representation. Its entity types, fields and relationships provide a structured way to describe equipment and the information expected from it.

Where it fits. A portfolio team with repeatable onboarding, commissioning and analytics requirements may benefit from explicit equipment-type expectations. The project toolset includes ontology and instance validation. Its building configuration distinguishes reporting and logical entities, maps native payload fields and translates units or states. That helps turn “connected” into something reviewable.

What to confirm. Check whether the required equipment and fields fit the model, who will maintain mappings and extensions, and whether the receiving applications actually use them. Missing required information must remain an explicit gap; a template is not permission to invent measurements. The configuration documentation includes old/new format guidance and implementation-specific examples, so pin a tested revision and toolchain. Google's use of an open-source project is not a support agreement or a requirement to buy Google hosting. Its FAQ and project documentation should be read alongside an actual pilot.

Test each model against a real information journey.

Start with the decisions and applications the client needs to support. Ask each candidate model to describe the same real information journey, using the receiving platform and the skills available to maintain it. Include the effort needed to make that journey work.

1. Define the questions. For example: find the meter and occupancy coverage for a floor, identify the equipment serving a room, or trace a questionable reading to its source.
2. Inspect the existing estate. Review representative exports, identifiers, units, naming, available relationships, data rights, interface licences and known gaps. Include difficult legacy assets and exceptions.
3. Check actual consumers. Ask each proposed application to demonstrate the exact model version, profile, import/export and relationships it supports. A logo or “open” claim is insufficient.
4. Model the same small sample. Compare candidates against the same equipment, spaces, meters and questions. Record manual effort, extensions, information loss, validation results and unresolved fields.
5. Prove the journey. Follow a reading from its native source through mapping and transport to the application. Test changed names, missing information and a disconnected source as well as the successful view.
6. Record the decision. Agree the selected version/profile, scope, mappings, exceptions, costs, responsibilities and acceptance evidence. Define what would trigger a later review.

Match the model to the project. A retrofit, new development and international portfolio have different starting points. Where practical, agree one authoritative model for a defined boundary, preserve necessary native records and maintain explicit mappings to other models.

A mapping between ontologies is also a deliverable to test. Do classes, references, units, states and required fields survive the round trip? Where a concept has no direct equivalent, record the extension or loss instead of quietly labelling the conversion “interoperable”.

Give each asset a stable identity.

A human-readable name such as EX-L03-AHU-001 can describe a location and equipment type. It is useful on a drawing or label, but it should not be the only permanent identifier. Floors are renamed, assets move, gateways change and equipment is replaced.

Keep a stable asset identifier alongside the display name, native system name and permitted aliases. Keep measurement identifiers distinct from physical assets: one air-handling unit can have many points. Define when a change preserves an identity and when a replacement creates a new asset record with a link to its predecessor. If a logical measurement continues across a meter replacement, retain the device-change date and provenance.

Define the naming structure, abbreviations, uniqueness, case, separators, characters and length limits. Check the convention against the building management system (BMS), maintenance system, drawings and applications. Demonstrate a representative supplier import before issuing it for procurement.

Physical asset tagging is a related process, not a synonym for semantic tagging. Agree who assigns the identifier, produces and installs the label, checks it against the equipment and register, and maintains it after replacement. A QR code can resolve an approved asset record; it should not expose credentials or a live control endpoint. Photograph and verify a representative sample before extending the approach across the project.

The output is a naming and identity standard, an asset register, a cross-reference to existing identifiers, a physical-label specification and a change process. The appointed project and operating teams confirm the physical evidence.

A points schedule is an information specification.

Use the points schedule as an information specification: define what is required, what it means, how it will be obtained and how delivery will be checked. At minimum, agree:

• Identity and scope: asset and point IDs, display names, equipment/space relationships, measurement boundaries and exclusions.
• Meaning: sensor, command, status, setpoint or calculated result; quantity, engineering unit, type, permitted states and the selected semantic classification.
• Native source: system, device/object/register or API field, source unit, scale/offset, byte/word ordering where applicable, and who confirms the mapping.
• Time and quality: sampling or reporting mode, interval, source timestamp, time zone, freshness requirement, missing/stale/fault/estimated handling and counter resets.
• Use and evidence: receiving field, aggregation, read/write scope, access approval, responsibilities, verification result and mapping version.

Specify the differences that affect interpretation: power in kW and accumulated energy in kWh; a booking, entry event, presence signal and headcount. Give designers and integrators clear definitions they can carry through to the final view.

Maintain three clear records: the required information, the discovered points and the verified information delivered. Review the differences at agreed milestones. Give missing points an explicit resolution: revise the requirement, use another source or agree additional scope.

Download an illustrative points schedule (Excel) ↓

Specify the message as carefully as the connection.

The semantic model need not be repeated in every message. A stable point ID can link telemetry to its metadata. The contract still needs agreed fields, types, units, timestamps, quality, versioning and delivery behaviour.

These questions follow the respective BACnet guidance , Modbus application protocol , MQTT specification and OPC UA overview . They are a starting brief, not a complete protocol or cyber-security specification. Appointed specialists select and validate the actual arrangement.

For MQTT, delivery assurance is not the same as verified downstream processing. Decide how consumers handle duplicates, late or out-of-order events and recovery. For Haystack, use the documented typed encoding and operation/error rules rather than assume that any JSON body is interchangeable.

Publish read-only telemetry separately from commands. Any permitted write needs its own authority, range/state restrictions, priority or override behaviour, audit trail and safe failure arrangements. A schema does not grant permission to control the building.

Make the requirement concrete.

In the downloadable synthetic example, point GBX-PT-0001 describes the supply-air temperature associated with asset GBX-AS-0001 . The asset's display name is EX-L03-AHU-001 . Its native locator remains a separate field in the schedule; the application's identity is not tied to a network address.

The example JSON payload carries that point and asset ID, a value, a declared unit, observation and receipt timestamps, a quality status and mapping version. It is an original illustrative contract, not a native Brick, Haystack or Digital Buildings serialization. No live equipment or endpoint is involved.

{
  "record_status": "synthetic_example",
  "payload_version": "gb-example-1.0",
  "message_id": "example-message-0001",
  "point_id": "GBX-PT-0001",
  "asset_id": "GBX-AS-0001",
  "observed_at": "2026-11-10T09:00:00Z",
  "received_at": "2026-11-10T09:00:02Z",
  "value": 18.7,
  "unit": "degC",
  "quality": "ok",
  "mapping_version": "example-map-1",
  "timestamp_basis": "gateway_acquisition"
}

Here degC and ok are explicitly defined example codes. The timestamp basis here is gateway acquisition: it does not claim to be the device's original sample time. A real contract must name its unit and quality dictionaries and any translations. Confirm whether the source can provide an observation timestamp; if it cannot, label the acquisition timestamp honestly. A missing value is not zero, and a plausible number is not sufficient evidence that its unit, boundary or origin is correct.

A useful acceptance exercise would trace this requirement through the native source, agreed classification, transformation, message and receiving view. Include an incorrect unit, stale reading, missing mapping and renamed display label. Check whether the consumer flags the problem without losing the stable identity. Record the outcome rather than treating syntactically valid JSON as a successful handover.

Leave the client with a maintainable information asset.

Agree tangible outputs for the appointment: a model-selection record, naming and identity convention, asset and point schedules, mapping specification, message and interface contract, validation results and exception register. Scale the work to the building’s information needs and strategy.

Agree who approves definitions, maintains mappings, corrects physical labels and accepts changes. Version the model and its implementation profile; retain exports and a tested recovery route. Include an asset replacement, new room, changed unit and supplier update in change control. The commissioning handover is the beginning of that ownership, not its end.

Define success for the project stage. A refurbishment may need one verified information path and an orderly register; a new development may need consistent specification and acceptance requirements; a portfolio may need reusable definitions and validation. Review the result against those agreed outcomes.

Include a migration test in the handover. Select a renamed room, a replacement meter and a corrected unit. Can the next authorised team follow the asset identity, see what changed and explain which historical records remain comparable? W3C’s Data on the Web Best Practices covers persistent identifiers, provenance, versioning and data-quality information. These requirements complement model validation by keeping the history understandable as the building changes.

Download the information-requirements checklist (Excel) ↓

Sources and further reading.

• W3C — Data on the Web Best Practices. Guidance on persistent identifiers, provenance, versions, quality and access that complements a building-specific ontology and its validation rules.
• Brick: scope and building relationships ; schema structure and versioning ; implementation documentation ; validation and project-specific constraints .
• Haystack: vocabulary, taxonomy, relationships and entity identity ; point functions, units and status ; exchange formats ; HTTP operations and error handling .
• Digital Buildings: ontology and learning modules ; fields, entity types and relationships ; building configurations and native-payload translations ; ontology frequently asked questions ; project tools and scope .
• BACnet International: capabilities and product evidence ; Modbus application protocol specification ; OASIS MQTT 5.0 ; OPC UA concepts .