Explore built-environment, workplace, facilities, real-estate and adjacent technology categories without confusing database breadth with a recommendation for your organisation.
These guides combine the canonical category boundary with current primary-source context. They do not rank vendors or replace organisation-specific assurance.
Evidence checked 11 October 2026 · Updated 11 October 2026
Workplace booking, visitor management and employee experience
Buying a workplace app is not simply choosing the easiest desk-booking screen. The whole journey from arrival through support, safety and workplace experience matters.
Educational procurement guidance only. No supplier endorsement, certification, legal-compliance opinion or verified integration claim.
Define the services being purchased
Distinguish desk and room booking, visitor invitations, check-in, wayfinding, locker or parking reservations, experience surveys, service requests and analytics. They may be sold together but operate under different data, control and risk requirements.
Start with the people and workflows
Consider employees, visitors, reception staff, hosts, contractors, security, cleaning and FM. Map common journeys, exceptions and accessibility needs. A highly rated mobile app may still introduce work for operational teams.
Distinguish reservation from presence
Booked does not necessarily mean occupied. Occupied does not explain the activity. Compare cancellation, no-show and release rules, alongside genuine availability at the times people need suitable settings.
Assess calendars and identity
Determine the exact Microsoft 365, Google Workspace, directory, badge and mobile-access requirements. Verify licences, permissions, synchronisation, delegated booking and behaviour when integrations fail. A vendor logo or general connector claim is not an acceptance test.
Keep visitor processes safe and workable
Visitor workflows may involve invitations, identity checks, building entry, accessibility, host notification, health-and-safety information and emergency response. Determine which system owns each control and ensure an outage does not leave visitors or staff without a safe process.
Decide what employee experience means
A satisfaction score, booking count or app engagement metric does not by itself demonstrate better work. Consider service responsiveness, suitability of settings, accessibility, certainty about team presence and whether the app removes friction or adds it.
Limit intrusive data collection
Review which personal data is needed for reservations, security or service delivery; who sees it; how long it is retained; and whether it can be used for another purpose. Employee monitoring and visitor data warrant purpose-specific privacy assessment.
Check accessibility and inclusion
Test on ordinary devices and in real workplace conditions, including visitors without smartphones, people with accessibility requirements and employees without persistent connectivity. Provide a workable non-digital alternative when required.
Price deployment and operations
Include licences, hardware, identity and access integrations, training, reception workflow changes, support, configuration, data migration and replacement costs. Compare a suite with point solutions on full operating cost, not just per-user pricing.
Plan an evidence-based pilot
Pilot representative roles, sites and high-demand days. Agree in advance what must improve, what cannot be sacrificed and when the test will stop. Retain the possibility of improving operating rules rather than changing technology.
Questions for procurement and operating teams
Which employee and visitor journeys are in scope?
Does the app improve access to suitable space or merely track bookings?
How are bookings, no-shows and actual presence distinguished?
What calendar, directory and badge integrations are required?
What functions remain available during an outage?
Who controls visitor approvals and physical entry?
How are accessibility and no-smartphone scenarios supported?
Which identifiable employee or visitor data is collected, and why?
Can teams adapt booking policies without code or vendor intervention?
How is employee experience evaluated beyond app usage?
What are implementation, operating and exit costs?
What alternatives, including changing current policies, should be tested?
NIST · Published; verify latest version · See publisher
Where workplace systems intersect with operational technology.
Evidence checked 7 October 2026 · Updated 7 October 2026
Access control and smart entry
A buyer guide for physical access, credentials, visitor entry, mobile access and biometric systems across identity, devices, integrations and operational resilience.
This guide frames buyer questions and evidence expectations. It does not certify a product, declare a vendor legally compliant or treat a protocol claim as proof of configured interoperability. Apply the law, risk model and life-safety requirements for each site and jurisdiction.
Define the physical and identity boundary
Map doors, zones, lifts, gates, lockers, visitors, contractors and privileged areas before comparing products. Name the authoritative sources for workforce identity, visitor identity, site access and emergency roles. Joiner, mover and leaver rules should cover temporary access, delegation, revocation latency, duplicate identities and exceptions rather than relying on a generic directory integration claim.
Prove interoperability at profile, version and workflow level
OSDP addresses communications between access-control panels and peripheral devices such as readers. ONVIF access-control Profiles A, C, D and M cover different configuration, door-control, peripheral and metadata functions. Ask for exact versions, roles and registered conformance where applicable, then test interoperability across credential creation, schedule changes, events, alarms, revocation, degraded operation and error handling. A standards logo or API list is not end-to-end proof.
Test credentials and degraded operation
Compare cards, mobile credentials, PINs and biometrics against the actual risk and user journeys. Test provisioning, replacement, revocation, phone or wallet dependencies, reader behaviour, cached permissions, clock drift, queued events and recovery when cloud, network or identity services are unavailable. Define which controls must remain local and what evidence proves the recovery sequence.
Make cybersecurity and key ownership explicit
Require a documented design for device identity, secure channels, encryption keys, certificate rotation, administrator authentication, logging, remote support, firmware integrity, vulnerability handling and segmentation. For legacy estates, identify Wiegand or other one-way reader interfaces and plan a controlled migration rather than assuming that replacing the head-end removes field-device risk.
Treat biometrics as a separate decision
Biometric access can introduce special-category data, accuracy, fairness and worker-monitoring obligations. In the UK, the ICO says buyers should assess necessity and proportionality, carry out a DPIA where required, address errors and security, and consider a non-biometric alternative. The ICO also marks this guidance as under review following the Data (Use and Access) Act, so applicability must be checked at decision time.
Plan migration, support and lifecycle
Inventory panels, readers, locks, cabling, power, credentials, schedules, integrations, event history and local procedures. Pilot representative sites, define coexistence and rollback, and reconcile permissions before cutover. Contract for lifecycle support covering firmware, security notifications, spare availability, mobile-platform dependencies, API and certificate changes, deprecation notice, data export and transition assistance.
Separate available capability from roadmap
Record whether each material capability is generally available, beta, announced or retired for the quoted product, edition, region and deployment model. Keep vendor assertions attributable and recheck them before approval, commissioning and estate-wide rollout. A future mobile credential, biometric mode or integration should not satisfy a current mandatory requirement unless the commitment is specific and enforceable.
Questions for procurement and operating teams
Which system is authoritative for people, visitors, contractors, sites, zones and access policy?
What is the maximum proven time to revoke access across every connected and offline controller?
Which OSDP version and ONVIF profiles are supported by each client, panel, reader and peripheral, and is conformance registered?
Who provisions, rotates, backs up and revokes device keys and certificates throughout the estate?
Which entry, alarm and lockdown functions continue during cloud, network, identity-provider or power failure?
For biometrics, what makes the processing necessary and proportionate, what alternative exists, and how are accuracy, fairness, DPIA and deletion handled?
How will legacy credentials, controllers, event history and integrations coexist, reconcile and roll back during migration?
Which firmware, mobile-platform, API, spare-part and end-of-support commitments are contractually testable?
US National Institute of Standards and Technology · Final guidance · 29 June 2018
Risk-based PIV use in US federal physical-access systems. It is useful technical context, not a general certification or a universal jurisdictional requirement.
Security Industry Association · Published industry standard; version 2.2.2 listed as current · Current source checked 7 October 2026
Panel-to-peripheral communications standard intended to improve interoperability, cybersecurity and device management. Configured compatibility still needs testing.
ONVIF · Published profiles · Current source checked 7 October 2026
Profiles A, C, D and M may apply to access-control systems. ONVIF states that registered profile conformance is required for a product to be considered conformant.
UK Information Commissioner's Office · Current regulator guidance; under review · Updated 6 June 2024; status checked 7 October 2026
UK data-protection guidance for worker monitoring and biometric access. The ICO says it is under review following the Data (Use and Access) Act.
Evidence checked 8 October 2026 · Updated 8 October 2026
Environmental, IAQ and IoT sensors
A buyer guide for environmental and indoor-air-quality sensing across measurement fitness, deployment design, integration, operational use and device lifecycle.
This guide frames buyer questions and evidence expectations. It does not certify measurement accuracy, a health or safety outcome, configured interoperability, product suitability or legal compliance. Thresholds and duties depend on the use case, building, people, jurisdiction and operating context; obtain qualified advice where the decision carries health, safety or regulatory consequences.
Start with the decision, not the sensor catalogue
Define whether the system will investigate conditions, inform occupants, support facilities work, trigger alarms, feed analytics or influence building controls. For every use case, name the variables, units, decision thresholds, response owner, required latency, evidence-retention period and consequence of a false positive, false negative or missing reading. A broad ‘IAQ score’ should not replace pollutant- or condition-specific requirements.
Specify measurement fitness and quality control
Set application-specific requirements for range, resolution, accuracy, precision, response time, drift, limit of detection, cross-sensitivity, environmental envelope and calibration. Require the supplier to distinguish laboratory specifications from field performance and to expose quality flags, correction methods and known limitations. The US EPA’s Enhanced Air Sensor Guidebook treats monitoring purpose, sensor selection, siting, collocation, correction, quality assurance and interpretation as connected steps rather than a device-only choice.
Design representative coverage
Model rooms, zones, occupancy patterns, air paths, contaminant sources, outdoor influences and maintenance access before fixing sensor counts. Pilot representative spaces and compare readings with a suitable reference or established method where the use case justifies it. Test placement sensitivity, time synchronisation, installation height, local heat or moisture, cleaning activity, connectivity loss and seasonal conditions; a dense deployment of poorly placed devices can create false confidence.
Interpret carbon dioxide carefully
Treat indoor carbon dioxide as one input with a defined technical basis, not as a universal measure of overall indoor air quality. NIST’s Indoor Carbon Dioxide Metric Analysis Tool explains that common CO2 applications can misunderstand the relationship between concentration, ventilation and IAQ. State whether a CO2 rule is being used to examine occupant-related ventilation, support demand control or answer another question, then validate the assumptions, outdoor baseline, occupancy inputs, sensor location and calibration.
Prove integration beyond a protocol label
Separate device transport, message delivery, object or topic structure, units, timestamps, quality status, identity and semantic meaning. BACnet or MQTT support does not by itself prove that a sensor’s data can be discovered, normalised and used safely in the target BMS, analytics platform or data service. Ask for exact protocol versions, BACnet device profiles and BTL listing where claimed, MQTT topic and payload contracts, authentication, rate limits, offline buffering and a tested mapping for every required point.
Test control and failure modes
If measurements can drive ventilation, filtration, alarms or occupant messaging, test the complete decision path. Define stale-data detection, plausibility checks, hysteresis, manual override, safe fallback, alarm acknowledgement, escalation and recovery after sensor, gateway, network, cloud or downstream-system failure. Keep monitoring evidence distinct from proof that a control action caused a reported outcome.
Make security and data stewardship explicit
Document device identity, onboarding, network segmentation, administrator access, encrypted communications, certificate or key rotation, signed firmware, vulnerability handling, remote support and audit logging. Identify whether granular environmental data can reveal occupancy or behaviour when combined with space and time, then set access, retention, sharing and deletion rules proportionate to the actual deployment.
Plan migration, support and device lifecycle
Inventory existing devices, gateways, radio networks, point names, calibration records, dashboards, rules and downstream consumers. For migration, pilot coexistence, preserve raw and normalised data where required, and define rollback before replacing interfaces or semantics. Contract for batteries, consumables, recalibration, firmware, radio and operating-system dependencies, spare availability, API changes, export, deprecation notice, end-of-support and transition assistance.
Separate available capability from roadmap
Record whether each material sensor, measurement, protocol, analytics function and control integration is generally available, beta, announced or retired for the quoted model, firmware, region and deployment option. Keep supplier claims attributable and recheck them before approval, commissioning and scale-up. A future measurement or integration should not satisfy a current mandatory requirement unless the commitment is specific and enforceable.
Questions for procurement and operating teams
Which operational decision will each measured variable support, and what happens when a reading is wrong, late or absent?
What range, accuracy, precision, response time, drift, cross-sensitivity and environmental limits are proven for the exact model and firmware?
How will siting, density, commissioning, collocation, calibration and periodic field checks show that readings represent the intended spaces?
For CO2, which question is the metric intended to answer, and which assumptions about outdoor concentration, occupancy, distribution and calibration must hold?
Which exact BACnet profiles, BTL listings, MQTT versions, topics, payloads, units, timestamps and quality flags are implemented and tested?
What are the safe fallback, alarm ownership and recovery sequence when a sensor, gateway, network, cloud service or downstream control fails?
Who owns device identity, keys, firmware, vulnerability response, remote access, audit logs and security support through end of life?
How will existing points, rules, histories and integrations coexist, reconcile and roll back during migration?
Which capabilities are generally available, beta, announced or retired for the quoted model, firmware, region and deployment option?
US Environmental Protection Agency · Published government guidance · 2022 edition; source checked 8 October 2026
Planning and conducting air-quality measurement using sensors, including selection, siting, collocation, correction, quality assurance, interpretation and performance. It is not a product certification or a substitute for application-specific measurement requirements.
US National Institute of Standards and Technology · Published Technical Note 2213 · 25 March 2022; source checked 8 October 2026
Explains the technical basis and limitations of indoor CO2 metrics for ventilation and IAQ analysis. It does not make a CO2 reading an overall IAQ score or prescribe a universal threshold.
BACnet International · Current certification programme information · Source checked 8 October 2026
Describes independent testing and product listings for BACnet protocol implementation. A listing supports protocol evidence but does not prove the configured end-to-end workflow, data semantics or fitness for a buyer’s use case.
OASIS Open · OASIS Standard · 7 March 2019; source checked 8 October 2026
A publish-subscribe messaging protocol standard. Conformance at the transport layer does not define a sensor’s topic taxonomy, payload semantics, data quality or downstream operational behaviour.
Evidence checked 9 October 2026 · Updated 9 October 2026
BMS, building automation and smart building
A buyer guide for building management, automation and smart-building systems across control outcomes, interoperability, operational technology security, resilience and lifecycle.
This guide frames buyer questions and evidence expectations. It does not certify a control sequence, safety outcome, cybersecurity posture, product suitability, configured interoperability or legal compliance. Requirements depend on the building, system boundary, operational consequence, jurisdiction and accountable engineering design.
Define the controlled outcome and system boundary
Start with the building services and operating outcomes that the system must monitor, supervise or control: plant, air systems, terminal units, lighting, meters, alarms, schedules and connected equipment. For each outcome, identify the controlled variable, permitted range, response owner, local and supervisory logic, manual authority and consequence of an incorrect, delayed or missing command. Separate a head-end interface, analytics layer and integration platform from the field controllers and physical systems that actually determine behaviour.
Prove sequences, commissioning and ongoing performance
Translate design intent into testable sequences of operation, points, alarms, trends, setpoints, schedules and acceptance criteria. Test normal operation, start-up, shutdown, occupancy transitions, seasonal modes, maintenance overrides and representative faults at equipment and system level. Require trend evidence and issue closure rather than accepting screen demonstrations as proof. Define who owns recommissioning when plant, spaces, software, firmware or control logic change.
Test interoperability at every layer
A BACnet claim can support data exchange between building-automation devices, but it does not by itself prove that the required objects, services, units, priorities, schedules, alarms, trends, write behaviour or recovery sequence work across the selected products. Record the exact protocol, edition, transport, device role and security option; verify any claimed listing; and run point-by-point and workflow tests through gateways, supervisory systems and field controllers. Treat proprietary extensions and integration middleware as explicit dependencies.
Make data meaning portable
Require stable identities, naming, units, timestamps, quality status, equipment relationships, space relationships and versioned point semantics. Project Haystack shows how a controlled vocabulary, taxonomy and ontology can describe sites, spaces, equipment, points and devices, but use of a semantic model still requires a governed instance model for the buyer's estate. Contract for an exportable point register and mappings so a change of head-end, analytics tool or service provider does not erase operational meaning.
Engineer operational technology security around physical consequences
Treat the BMS as operational technology where cyber actions can affect the physical environment. NIST SP 800-82 Revision 3 is the current final guidance and includes building automation systems; Revision 4 was an initial public draft on 21 September 2026 and must not be presented as final. Define asset inventory, zones and conduits, identities, least privilege, administrator and remote-support access, secure update and backup, monitoring, vulnerability handling and incident recovery while preserving required performance, reliability and safety.
Design degraded modes and recovery
Map what continues locally when the supervisory server, cloud service, network, gateway, time source, identity service or external data feed fails. Test controller autonomy, stale-data detection, command priority, manual override, safe fallback, alarm routing, restart order, configuration restore and reconciliation after connectivity returns. The required fallback is an accountable engineering decision; a generic high-availability or zero-trust claim is not evidence that a building will remain safe or operable.
Control remote services, analytics and automation
List every outbound connection, remote user, vendor support path, API, cloud dependency, optimisation service and automated write-back. Distinguish read-only monitoring from software that can change schedules, setpoints or commands. The NSA's 8 October 2026 zero-trust guidance is primarily scoped to US National Security Systems, the Department of War and the Defense Industrial Base; it is a useful high-consequence OT signal, not proof of general applicability or vendor compliance.
Plan migration without losing control knowledge
Inventory controllers, panels, networks, gateways, firmware, programs, graphics, point databases, schedules, alarms, trends, credentials, licences and service tools. Establish which artefacts can be exported in usable form and which require supplier cooperation. Pilot representative plant, define coexistence and rollback, preserve validated sequences, and contract for spare parts, engineering tools, certificates, API changes, security support, deprecation notice, end-of-support and transition assistance.
Separate available capability from roadmap
Record whether each material controller, protocol, semantic model, cloud service, cybersecurity function, optimisation feature and integration is generally available, beta, announced or retired for the quoted product, edition, firmware, region and deployment model. Keep supplier assertions attributable and recheck them before design approval, factory testing, commissioning and scale-up. A roadmap feature should not satisfy a current mandatory requirement unless the commitment is specific and enforceable.
Questions for procurement and operating teams
Which physical systems and outcomes are in scope, and where do local control, supervisory control, analytics and human authority begin and end?
Which sequences, points, alarms, trends, schedules and failure states will be tested, with what acceptance evidence and accountable owner?
Which exact BACnet edition, transport, device roles, objects, services, security options and product listings are implemented?
How will point identities, units, timestamps, quality flags and equipment and space relationships remain portable across tools and suppliers?
Which assets, zones, identities, remote paths and privileged actions exist, and how are updates, backups, monitoring and vulnerability response governed?
What continues locally during loss of server, cloud, network, gateway, time source, identity service or external data, and how is recovery reconciled?
Which services can write schedules, setpoints or commands, what prevents unsafe changes, and how are actions logged and reversed?
Which programs, graphics, point databases, histories, credentials, licences and engineering tools can be exported in usable form?
What support, spare-part, firmware, certificate, API, deprecation and end-of-support commitments are contractually testable?
Which capabilities are generally available, beta, announced or retired for the quoted product, edition, firmware, region and deployment model?
ASHRAE · Published protocol overview · Current source checked 9 October 2026
Describes BACnet communication for building automation and control equipment and the types of building data exchanged. A protocol claim is not proof of configured point coverage, workflow behaviour, security or end-to-end interoperability.
US National Institute of Standards and Technology · Final guidance · September 2023; status checked 9 October 2026
Final NIST guidance for securing operational technology, including building automation systems, while addressing performance, reliability and safety. It is guidance rather than deployment certification.
US National Institute of Standards and Technology · Initial public draft; comments due 30 November 2026 · 21 September 2026
Draft guidance that expands coverage of building automation and control systems and aligns with the NIST Cybersecurity Framework 2.0. It is not final and must not be treated as a current mandatory requirement.
Project Haystack · Open-source ontology documentation, version 4.0.0 · 2 September 2026; source checked 9 October 2026
Defines vocabulary, taxonomy, relationships and instance-model concepts for built-environment data. Use of the ontology does not prove that a deployed estate has complete or correct semantic modelling.
US National Security Agency · Published government cybersecurity guidance · 8 October 2026
Primarily intended for US National Security Systems, the Department of War and Defense Industrial Base owners and operators. It is a scoped security signal, not proof of vendor compliance, implementation completeness or general applicability.
Evidence checked 10 October 2026 · Updated 10 October 2026
Occupancy, people counting and space analytics
A buyer guide for occupancy measurement and space analytics across decision use, measurement performance, privacy, interoperability and lifecycle.
This guide frames buyer questions and evidence expectations. It does not certify measurement accuracy, anonymity, privacy, biometric status, legal compliance, product suitability or that an analytics intervention caused an outcome. Requirements depend on the method, use case, building, workforce, jurisdiction and accountable operating decision.
Define the decision and counting boundary
Start with the decision the data must support, then define the observable precisely. Footfall, entries and exits, concurrent occupancy, presence, dwell, utilisation and named-person location are different measurements with different error and privacy consequences. State whether the system produces anonymous aggregates, device or trajectory data, identity data or biometric inferences; a broad occupancy label should not conceal a more intrusive capability.
Specify performance against representative ground truth
For every required output, specify the space boundary, time bucket, sample size, representative ground-truth method, error measure, false-positive and false-negative treatment, missingness, latency and confidence or uncertainty. Separate sensor performance, algorithm performance and end-to-end reporting performance. A percentage accuracy claim without the denominator, conditions and aggregation method is not comparable evidence.
Test representative conditions and drift
Commission against real entrances, zones and operating patterns. Include occlusion, groups, direction changes, variable daylight, furniture or partition changes, network loss, seasonal conditions and the busiest and quietest periods. Define recalibration triggers and periodic revalidation so that sensor movement, layout change, model update or population change does not silently degrade the measurement.
Make space and time semantics portable
Require stable building, floor, space, zone and sensor identities; versioned zone geometry and coverage; timestamps, time zones and daylight-saving handling; explicit units; and a clear distinction between counts, states, events and derived rates. Brick 1.4.4 can support portable relationships between spaces, equipment and points, but use of an ontology does not prove that a supplier's instance model is complete or correct.
Treat privacy as a design constraint
Document the purpose, people affected, least intrusive method, edge processing and aggregation, retention, access, sharing, transparency and deletion. For UK worker monitoring, current ICO guidance says to define the purpose, use the least intrusive means, be transparent and complete a DPIA where processing is likely to present high risk; that guidance is under review following the Data (Use and Access) Act. Recheck the current law and scope for each deployment rather than treating this guide as legal advice.
Separate AI, video and biometrics
Where machine learning or computer vision affects the measurement, use an evidence plan that covers validity, reliability, ongoing testing, monitoring and change control; NIST AI RMF 1.0 is a voluntary reference rather than a certification. If the system performs facial or gait recognition, watch-list matching or other biometric video-surveillance processing, treat that as a separate decision. ISO/IEC 30137-1:2024 may then be relevant, but it does not govern a generic anonymous people counter.
Prove integration beyond a protocol label
Test the exact APIs, MQTT topics and payloads, BACnet objects or vendor exports needed by workplace, IWMS, BMS and data platforms. Verify identities, timestamps, units, zone versions, quality flags, duplicates, loss, buffering, backfill, rate limits and error handling. MQTT 5.0 defines message transport; it does not define occupancy semantics, privacy controls or operational fitness.
Put guardrails around downstream action
For cleaning, energy, capacity or portfolio decisions, define thresholds, hysteresis, data-freshness rules, confidence limits, fallback, manual override and the owner who may act. Preserve the distinction between a measured association and a causal claim: a change in an occupancy dashboard does not by itself show that the technology caused an operational or financial outcome.
Plan migration, support and lifecycle
Inventory sensors, gateways, radios, zone definitions, calibration records, rules, dashboards, histories and downstream consumers. Pilot coexistence, export usable data and semantics, and define rollback before cutover. Contract for batteries, firmware, security support, radio and operating-system dependencies, API changes, recalibration, deprecation, end-of-support and transition assistance. Record whether every material capability is generally available, beta, announced or retired for the quoted model, region and deployment option.
Questions for procurement and operating teams
Which decision and action will the data support, and what happens when the measurement is wrong, late or absent?
Is the observable footfall, entry and exit, concurrent occupancy, presence, dwell, utilisation, trajectory or identity?
What metric, denominator, time bucket, sample size and ground-truth method support each performance claim?
Which representative conditions, layout changes and model or firmware updates trigger revalidation?
How are purpose, minimisation, transparency, retention, access, deletion and any required DPIA handled?
Can the system identify, recognise or follow a person or device, and how are biometric or identity capabilities disabled and verified?
How will space, zone, sensor and time semantics remain portable when layouts or suppliers change?
Which exact API, MQTT, BACnet or export versions, payloads, quality flags and backfill behaviours are tested?
What thresholds, confidence rules, fallbacks and manual overrides govern downstream action and causal claims?
Which lifecycle dependencies and capabilities are generally available, beta, announced or retired for the quoted deployment?
UK Information Commissioner's Office · Current UK regulator guidance; under review · Status checked 10 October 2026
UK data-protection guidance for worker monitoring, including purpose, necessity, proportionality, transparency and DPIAs. The ICO says it is under review following the Data (Use and Access) Act; it is not a universal legal test.
US National Institute of Standards and Technology · Published voluntary framework · January 2023; source checked 10 October 2026
Voluntary, non-sector-specific framework for managing AI risks. It can inform testing and monitoring of AI-based analytics, but it is not a product certification or regulation.
International Organization for Standardization · Published international standard · 2024 edition; source checked 10 October 2026
Applies to biometric technologies used in video-surveillance systems, including facial and gait recognition. It is conditional context for biometric deployments, not a standard for generic anonymous counting.
Brick Consortium · Published open ontology; version 1.4.4 listed as current · 1 May 2025; source checked 10 October 2026
Provides semantic concepts and relationships for buildings, spaces, equipment and points. Ontology use does not prove a deployed instance model is complete, correct or portable.
OASIS Open · OASIS Standard · 7 March 2019; source checked 10 October 2026
Publish-subscribe messaging protocol standard. Transport conformance does not define occupancy payload semantics, data quality, privacy or operational fitness.
Evidence checked 11 October 2026 · Updated 11 October 2026
IWMS, CAFM, CMMS and EAM
A buyer guide for integrated workplace, facilities, maintenance and enterprise-asset platforms across operating model, data, workflows, interoperability, migration and lifecycle.
This guide frames buyer questions and evidence expectations. It does not certify an asset-management or facility-management system, configured interoperability, data quality, cybersecurity, legal compliance, product suitability or business outcome. Apply the operating model, asset criticality, service obligations and jurisdiction for each deployment.
Define the suite boundary before comparing breadth
Name the decisions and workflows the platform must support across property, leases, space, workplace services, assets, maintenance, projects and service delivery. Separate the system of record from portals, mobile clients, analytics and specialist operational systems. A broad IWMS label does not prove CMMS or EAM depth, and a strong maintenance product does not automatically provide lease, workplace or portfolio capability. Score the quoted edition and modules against an explicit boundary rather than the supplier's category label.
Start with the operating model and accountability
Map demand organisations, facility teams, asset owners, service providers, occupants, finance, IT and operational-technology owners. Define who sets policy, owns data, approves work, accepts handover, measures service and resolves exceptions. ISO 41001:2018 is a published facility-management system standard, amended in 2024 and marked by ISO as due for revision; it can frame management-system questions but does not certify software or prescribe a product architecture.
Connect asset strategy to executable work
Translate asset objectives, criticality, risk, performance and expenditure into hierarchies, maintenance strategies, inspection plans, job plans, materials and decision rights. ISO 55001:2024 specifies requirements for an asset-management system and replaced the 2014 edition. Use it to test whether the proposed workflow supports the organisation's asset-management system; buying software alone neither establishes that system nor demonstrates conformity.
Govern identifiers, relationships and data quality
Define authoritative identifiers for sites, buildings, floors, spaces, systems, maintainable assets, contracts, suppliers, people and cost objects. Specify hierarchy rules, status values, units, classifications, ownership, validation, effective dates and change control. ISO 55013:2024 provides guidance on managing data to support asset-management objectives; it does not determine the financial value of data or prove that a supplier's data model is complete. Require measurable completeness, uniqueness, validity and reconciliation rules for each critical dataset.
Test maintenance and service workflows end to end
Demonstrate requests, triage, priority, planning, permits, parts, labour, scheduling, dispatch, mobile or offline work, subcontractors, completion, verification, cost posting and closure using representative scenarios. Define which clock starts each service target, how pauses and reassignments are recorded, and how emergency, statutory, condition-based and planned work differ. A dashboard or work-order count is not evidence that the underlying task, asset, time, cost or service record is accurate.
Prove integrations as governed data contracts
Inventory required exchanges with identity and HR, ERP, finance, procurement, lease accounting, GIS, BIM, document systems, building controls and IoT services. For every interface, specify direction, object, identifier, field meaning, unit, cadence, latency, authentication, authorisation, error handling, replay, monitoring and reconciliation. OpenAPI 3.1.2 can describe an HTTP API surface; an OpenAPI document does not prove workflow coverage, semantic alignment, performance or configured end-to-end operation.
Specify BIM and handover information precisely
State which operational data must be accepted from projects, validated, approved and linked to maintained records and documents. buildingSMART lists IFC 4.3.2.0 as the latest official IFC release and notes its publication as ISO 16739-1:2024. Require the exact IFC release, exchange purpose, model view or information-delivery requirement, classifications, properties and validation evidence. Schema-valid exchange does not by itself prove that asset data is complete, current or usable for operations.
Plan migration as reconciliation, not file loading
Profile source systems before design and quantify duplicates, missing identifiers, invalid statuses, obsolete assets, open work, conflicting hierarchies and unsupported attachments. Define transformation ownership, acceptance thresholds, exception queues, rehearsal, freeze, cutover, coexistence, rollback and post-load reconciliation. Preserve required work history, warranties, readings, documents and audit evidence, while separating defensible retention from indiscriminate migration.
Protect operational connections and degraded service
Where the platform exchanges data with building automation or other operational technology, treat the boundary as more than a generic IT integration. NIST SP 800-82 Rev. 3 is final guidance for OT security and explicitly includes building automation; Revision 4 is an initial public draft, not the current final. Test segmentation, least privilege, service accounts, remote support, logging, backup, restore, queued transactions and safe behaviour during identity, network, cloud, mobile or downstream-system failure.
Separate available capability from roadmap and lifecycle
Record whether each material module, workflow, mobile mode, connector, analytics feature and AI-assisted function is generally available, beta, announced or retired for the quoted edition, region and deployment model. Keep supplier assertions attributable and recheck them before approval, migration and scale-up. Contract for support boundaries, release policy, API and data-model change, deprecation notice, security maintenance, export, archival access and transition assistance.
Questions for procurement and operating teams
Which workflows and records are in scope, and which systems remain authoritative for property, people, finance, procurement, BIM, controls and documents?
Which IWMS, CAFM, CMMS or EAM capabilities are native, separate modules, partner products, custom work or roadmap for the quoted edition?
How do asset criticality, risk, performance and expenditure rules become approved maintenance strategies, job plans and work decisions?
Who owns each critical identifier and field, and what measurable completeness, uniqueness, validity and reconciliation thresholds apply?
How are requests, priorities, service clocks, permits, parts, subcontractors, costs, verification and closure evidenced end to end?
For each integration, what are the direction, objects, semantics, units, cadence, authentication, error, replay and reconciliation controls?
Which OpenAPI version, endpoints and schemas are supplied, and what tested workflow evidence goes beyond interface description?
Which IFC release, exchange purpose, model view or information requirement, classifications and validation rules govern project handover?
What source-data defects, exclusions, transformations, acceptance thresholds, rehearsal, rollback and post-load controls govern migration?
What remains available, queued or safely unavailable during identity, network, cloud, mobile, ERP, BMS or other downstream failure?
Which capabilities are generally available, beta, announced or retired for the quoted edition, region and deployment option?
What support, security maintenance, release, API change, deprecation, export and transition commitments are contractually testable?
International Organization for Standardization · Published with 2024 amendment; revision under development · April 2018; amendment February 2024; status checked 11 October 2026
Requirements and guidance for a facility-management system. ISO marks the published standard as due for revision; a management-system standard is not a software certification or product architecture.
International Organization for Standardization · Published international standard, edition 2 · July 2024; source checked 11 October 2026
Requirements for establishing, implementing, maintaining and improving an asset-management system. It replaced ISO 55001:2014 and does not certify a software product.
International Organization for Standardization · Published international standard, edition 1 · July 2024; source checked 11 October 2026
Guidance for managing data to support asset-management objectives. It does not provide methods for deriving or appraising the financial value of data assets.
buildingSMART International · Latest official release 4.3.2.0; ISO 16739-1:2024 · Current source checked 11 October 2026
Open schema for structured built-environment information exchange. Version or schema validation does not prove complete, current or operationally usable asset information.
US National Institute of Standards and Technology · Final guidance; Revision 4 initial public draft now available · 28 September 2023; status checked 11 October 2026
OT security guidance that includes building automation and addresses performance, reliability and safety. It is not a product certification or a universal control baseline for every IWMS deployment.
OpenAPI Initiative · Published specification · 19 September 2025; source checked 11 October 2026
Language-agnostic description for HTTP API surfaces. A conforming description does not prove semantic alignment, workflow coverage, performance, security configuration or end-to-end interoperability.
Evidence checked 12 October 2026 · Updated 12 October 2026
Facilities and asset maintenance
A buying guide for turning asset strategy into controlled maintenance work, dependable records and evidence that operating teams can use.
General procurement guidance only. It does not certify an asset-management system, maintenance programme, legal compliance, product suitability, diagnostic accuracy, reliability outcome or configured interoperability. Apply asset criticality, competent engineering judgement, site conditions, contractual duties and the relevant jurisdiction.
Define the maintenance boundary before comparing products
State which assets, sites, teams, service providers and work types are in scope. Separate the maintenance system of record from broad IWMS functions, building controls, condition-monitoring platforms, parts systems, finance, procurement and document repositories. A CMMS, EAM or facilities-maintenance label does not prove support for a particular operating model, asset class or risk profile. Score the quoted edition and modules against representative work, not the category name.
Connect asset objectives to executable maintenance
Translate service outcomes, criticality, risk, performance and expenditure into asset strategies, inspection plans, maintenance regimes, job plans, materials and decision rights. ISO 55001:2024 specifies requirements for an asset-management system and replaced the 2014 edition. It can frame governance questions, but buying software neither establishes that system nor demonstrates conformity or improved reliability.
Make the asset hierarchy and record ownership explicit
Define authoritative identifiers and relationships for sites, systems, maintainable items, components, meters, warranties, documents, spares and cost objects. Specify naming, classification, status, units, ownership, effective dates, validation and change control. Decide how commissioning, replacement, refurbishment, temporary assets and decommissioning alter the record. A populated register is not necessarily complete, current or correctly related to work history.
Demonstrate work control from request to verified closure
Test requests, triage, priority, planning, permits, isolation, competence, materials, labour, scheduling, dispatch, mobile or offline work, subcontractors, completion, verification, cost posting and closure. Define which clock starts each service target, what can pause it and how emergency, corrective, statutory, planned and project work are distinguished. A work-order count or dashboard does not prove that the underlying task, asset, time, cost or service record is accurate.
Choose a maintenance strategy for each failure mode
Use the asset's function, credible failure modes, consequences, detectability, intervention options and evidence quality to decide between corrective, scheduled, usage-based, condition-based or other approaches. Do not treat preventive, predictive or prescriptive labels as proof of fitness. Require the supplier to show the inputs, decision thresholds, exception handling, human approval and feedback needed for each proposed strategy.
Treat condition monitoring as a governed programme
ISO 17359:2018 sets out general procedures for establishing a condition-monitoring programme for machines, while ISO 13379-1:2025 describes common concepts and guidance for condition-monitoring and diagnostic systems. Use them to frame questions about monitored functions, baseline behaviour, sensor suitability, data quality, alarm logic, diagnostic confidence, competence, review and response. Neither standard validates a supplier's model, proves fault prediction or removes the need for engineering judgement.
Standardise failure and maintenance data with its scope intact
Define failure, symptom, cause, mechanism, detection method, action, downtime and maintenance-resource fields before comparing reports. ISO 14224:2016 provides a standardised equipment taxonomy and reliability and maintenance data structure for petroleum, natural-gas and petrochemical industries. It is useful evidence for those sectors and may inform questions elsewhere, but it is sector-specific and must not be represented as a universal facilities data model.
Control parts, tools and resource availability
Link job plans to approved parts, substitutes, tools, skills, access constraints and lead times. Specify reservations, issues, returns, serial or batch traceability, repairable items, min-max logic, stock checks and financial posting. Test how the system treats unavailable material, unplanned work and contractor-provided stock. High inventory availability can coexist with obsolete holdings, weak issue discipline or incorrect bills of material.
Preserve operational information through projects and change
State which asset, document and maintenance information must be accepted from projects, validated, approved and linked to operational records. ISO 19650-3:2020 describes an operational-phase information-management process using building information modelling; ISO lists it as current but due for revision, with a replacement under development. Define the required information, identifiers, responsibilities and acceptance rules rather than assuming that a model handover creates usable maintenance data.
Prove integrations and degraded operation
For identity, finance, procurement, BIM, document, meter, building-control, IoT and specialist diagnostic interfaces, specify direction, object, identifier, semantics, unit, cadence, authentication, error handling, replay, monitoring and reconciliation. OpenAPI 3.1.2 can describe an HTTP interface; it does not prove semantic alignment or configured end-to-end operation. Where maintenance connects to operational technology, use NIST SP 800-82 Rev. 3 to frame segmentation, remote access, service accounts, logging, backup, restore and safe degraded modes. Revision 4 is an initial public draft, not the current final.
Plan migration, support and product lifecycle
Profile source data and quantify duplicates, missing identifiers, invalid statuses, open work, conflicting hierarchies and unsupported attachments before design. Define transformations, exclusions, acceptance thresholds, rehearsal, cutover, rollback and post-load reconciliation. Record whether each material workflow, mobile mode, connector, analytics feature and AI-assisted function is generally available, beta, announced or retired for the quoted edition, region and deployment model. Contract for support boundaries, security maintenance, release policy, API change, deprecation notice, export, archival access and transition assistance.
Questions for procurement and operating teams
Which assets, sites, teams, providers and maintenance work types are in scope, and which systems remain authoritative?
How do asset objectives, criticality, failure consequences and expenditure rules become approved maintenance strategies and work?
Who owns each asset identifier, hierarchy, status, classification, unit, document and relationship, and how is change controlled?
How are requests, priorities, permits, isolations, competence, parts, labour, verification, costs and closure evidenced end to end?
Which credible failure modes justify corrective, scheduled, usage-based or condition-based maintenance, and what evidence supports the choice?
For condition monitoring, what establishes the baseline, alarm threshold, diagnostic confidence, review role and required response?
Which reliability and maintenance data definitions apply, and where are sector-specific standards being used outside their stated scope?
How are parts, substitutes, repairable items, tools, skills and contractor stock linked to executable job plans?
What information must projects hand over, who validates it and how is it reconciled with the operational asset register?
For every integration, what are the objects, identifiers, semantics, units, cadence, authentication, error, replay and reconciliation controls?
What remains available, queued or safely unavailable during mobile, identity, network, cloud, ERP, BMS or diagnostic-system failure?
What source-data defects, exclusions, transformations, acceptance thresholds, rehearsal, rollback and post-load controls govern migration?
Which capabilities are generally available, beta, announced or retired, and what support, deprecation, export and transition commitments are testable?
International Organization for Standardization · Published international standard, edition 2 · July 2024; source checked 12 October 2026
Requirements for establishing, implementing, maintaining and improving an asset-management system. It replaced ISO 55001:2014 and does not certify a software product.
International Organization for Standardization · Published international standard, edition 3; confirmed current in 2023 · January 2018; status checked 12 October 2026
General procedures for setting up a condition-monitoring programme for machines. It does not validate a particular sensor, diagnostic method or supplier outcome.
International Organization for Standardization · Published international standard, edition 3; confirmed current in 2022 · September 2016; status checked 12 October 2026
Reliability and maintenance data structure for petroleum, natural-gas and petrochemical industries. Sector-specific scope; not a universal facilities taxonomy or a failure-rate benchmark.
International Organization for Standardization · Published and confirmed in 2024; revision under development · July 2020; status checked 12 October 2026
Operational-phase information-management process. ISO marks the edition as due for revision; it does not prove that a handover dataset is complete or usable for maintenance.
US National Institute of Standards and Technology · Final guidance; Revision 4 initial public draft available · 28 September 2023; status checked 12 October 2026
OT security guidance that includes building automation. It is not a product certification or a universal control baseline for every maintenance deployment; Revision 4 is not final.
OpenAPI Initiative · Published specification · 19 September 2025; source checked 12 October 2026
Language-agnostic description for HTTP API surfaces. A conforming description does not prove semantic alignment, workflow coverage, security configuration or end-to-end interoperability.
Evidence checked 13 October 2026 · Updated 13 October 2026
Workplace analytics
A buyer guide for turning workplace, occupancy and portfolio data into traceable decisions without confusing bookings, attendance, occupancy, utilisation or modelled demand.
This guide frames buyer questions and evidence expectations. It does not endorse a supplier, certify data quality, privacy or legal compliance, prove configured interoperability, attribute causation, predict savings or recommend a portfolio decision. Definitions, lawful bases and operational thresholds depend on the decision, people, sites and jurisdictions in scope.
Start with the decision and accountable action
Name the decision before selecting dashboards or models: for example, changing services, testing workplace policy, planning a move, redesigning space or examining a lease option. Define the decision owner, review cadence, threshold, alternatives, reversibility and evidence needed to act. ISO 41014:2020 frames facilities strategy around the demand organisation's objectives, needs and constraints; analytics should support that strategy rather than become an objective in itself.
Keep the measures distinct
Do not treat booking, attendance, presence, occupancy, utilisation, capacity, allocation, demand and experience as synonyms. For every measure, record the numerator, denominator, unit, location level, collection window, exclusions, time zone, refresh rule and intended use. The US GSA's current occupancy reporting rules illustrate how a jurisdiction-specific definition fixes people, floor-area and reporting-period inputs; those federal rules and thresholds must not be transplanted into another organisation as universal metrics.
Create a metric and population contract
Define who or what is observed, which days and hours count, how shared areas and multi-building visits are treated, and when a person, device or event is considered unique. Specify treatment for holidays, travel, contractors, visitors, part days, duplicate signals, missing days and late corrections. Preserve the version of every definition used in a published report so that a trend is not created by an undocumented denominator or scope change.
Reconcile sources before interpreting them
Map sensors, access events, bookings, calendars, Wi-Fi, directories, HR locations, leases, cost data, service records and surveys to their authoritative owners, identifiers and effective dates. A booking does not prove presence; a badge event may not prove duration; a network association may represent a device rather than a person. Require reconciliation rules, duplicate handling, quality flags and a traceable route from an aggregate back to permitted source evidence.
Make data quality and uncertainty visible
Set decision-specific requirements for completeness, accuracy, consistency, timeliness, coverage and provenance. Show outages, stale feeds, sampling gaps, exclusions, imputation, confidence bounds and material corrections rather than silently smoothing them away. ISO 8000-1:2022 and ISO/IEC 25024:2015 provide data-quality concepts and measures; W3C's Data Quality Vocabulary can express metrics and provenance but explicitly does not define a universal meaning of quality.
Control privacy and worker-monitoring risk
Minimise personal data and separate operational, planning, security and performance-management purposes. Establish access, aggregation, retention, deletion, transparency, rights handling and controls against re-identification or function creep. Assess necessity, proportionality and impact for each jurisdiction and workforce context. The UK ICO's worker-monitoring guidance is UK-specific and currently under review following the Data (Use and Access) Act, so it is context rather than a blanket compliance conclusion.
Distinguish description, inference and prediction
Label descriptive reporting, diagnostic analysis, forecasts, scenarios and recommendations separately. Correlation between presence, cost, service or experience does not establish causation. For forecasts and scenarios, expose input data, assumptions, model version, training period where relevant, sensitivity, uncertainty, human override and performance after deployment. Compare action against a credible alternative, including changing policy or service without buying new technology.
Test portfolio scenarios against operational constraints
Model lease events, growth ranges, seasonal peaks, critical adjacencies, specialist spaces, accessibility, business continuity, location strategy and service capacity. Use scenarios to show trade-offs rather than presenting a single optimisation result as inevitable. Define which constraints are hard, which are assumptions and who can change them; retain the ability to inspect why an option was included or rejected.
Prove integration and semantic alignment
For each interface, specify objects, identifiers, units, timestamps, time zones, quality status, lineage, update cadence, authentication, rate limits, error handling, replay and reconciliation. OpenAPI 3.2.1 can describe an HTTP API surface, but a conforming description does not prove that two systems share definitions or that a configured workflow operates end to end. Test representative records, schema change, late data, duplicate events, access boundaries and recovery from partial failure.
Plan migration, baselines and continuing validation
Profile source history before setting a baseline. Quantify missing locations, changing floor areas, identifier drift, sensor moves, policy changes and gaps caused by integration or estate changes. Define transformations, exclusions, acceptance thresholds, rehearsal, rollback and post-load reconciliation. After launch, monitor drift in data coverage, definitions, organisational structure and model performance so that an apparently stable dashboard does not mask a changing evidence base.
Contract for capability and product lifecycle
Record whether each material dashboard, connector, scenario model, forecasting feature and AI-assisted function is generally available, beta, announced or retired for the quoted edition, region and deployment model. Keep vendor assertions attributable and recheck them before approval and rollout. Contract for support ownership, data export, metadata and definition export, API and model changes, deprecation notice, historical access, portability and transition assistance.
Questions for procurement and operating teams
Which decision, action, owner, cadence and alternative does each analysis support?
How are booking, attendance, presence, occupancy, utilisation, capacity, allocation and demand defined and kept separate?
What are the numerator, denominator, population, collection window, exclusions and version for every reported measure?
Which systems are authoritative for people, spaces, sensors, bookings, leases, costs, services and experience data?
How are duplicate, late, missing, stale, imputed and corrected records exposed and reconciled?
Which data-quality thresholds are decision-specific, and what happens when they are not met?
Which personal or worker data is collected, for what purpose, with what access, aggregation, retention and deletion controls?
How are descriptive results, inference, forecasts, scenarios and recommendations labelled and independently reviewed?
Which model inputs, assumptions, versions, uncertainty, sensitivity and human overrides are recorded?
Which portfolio constraints are hard requirements, which are assumptions and who may change them?
For each integration, what are the identifiers, semantics, units, timestamps, quality flags, error, replay and reconciliation controls?
How will migration establish a trustworthy baseline and detect later changes in definitions, coverage or model performance?
Which capabilities are generally available, beta, announced or retired, and what export, support, deprecation and transition commitments are testable?
International Organization for Standardization · Published international standard, edition 1 · September 2020; source checked 13 October 2026
Guidance for developing an FM strategy aligned with the demand organisation's objectives, needs and constraints. It does not prescribe analytics metrics or certify a product.
International Organization for Standardization · Published international standard, edition 1; confirmed current in 2024 · April 2022; status checked 13 October 2026
Overview of data-quality concepts and the ISO 8000 series. It does not certify a workplace dataset or define a universal acceptance threshold.
World Wide Web Consortium · Working Group Note; may be updated, replaced or obsoleted · 15 December 2016; status checked 13 October 2026
Vocabulary for expressing data-quality measurements, metrics, provenance and related metadata. The note says publication does not imply W3C Membership endorsement and does not define a universal meaning of quality.
UK Information Commissioner's Office · Current regulator guidance; under review · Status checked 13 October 2026
UK data-protection guidance for worker monitoring. The ICO states that it is under review following the Data (Use and Access) Act; applicability and current law must be checked for the deployment.
US National Institute of Standards and Technology · Version 1.0 final; Version 1.1 initial public draft, not final · Version 1.1 draft published 14 April 2025; status checked 13 October 2026
Voluntary privacy-risk management framework and update project. It is not law, product certification or a deployment-specific compliance conclusion.
US General Services Administration · Current US federal reporting guidance · Source checked 13 October 2026
Reporting definitions and methods for covered US federal public buildings and leased space. Its scope, exclusions, design requirement and reporting cadence are jurisdiction-specific, not universal workplace benchmarks.
OpenAPI Initiative · Published specification; current version at source check · Status checked 13 October 2026
Language-agnostic description for HTTP API surfaces. A conforming description does not prove semantic alignment, workflow coverage, security configuration or end-to-end interoperability.
Evidence checked 14 October 2026 · Updated 14 October 2026
Meeting room management
A buyer guide for governing room identity, booking, check-in, panels and service workflows across calendars, meeting platforms and physical spaces.
General procurement guidance only. It does not endorse a supplier, certify accessibility, privacy or legal compliance, prove configured interoperability, validate occupancy or utilisation figures, or establish that a meeting-room system is suitable for a particular estate. Verify the quoted edition, licence, region, device, firmware, calendar tenant and deployment configuration.
Set the decision boundary before comparing products
Separate the room-management decision from broad workplace booking, visitor management, video-conferencing, room AV and control, digital signage, access control, occupancy sensing and workplace analytics. State which functions are required: room discovery, booking, approval, check-in, release, panel display, ad-hoc reservation, service requests, equipment status or utilisation insight. A suite logo or room-system label does not prove that the quoted modules and licences cover the required workflow.
Make the calendar and room record authoritative
Choose the authoritative room identity and record its mailbox or resource calendar, building, floor, capacity, equipment, time zone, delegates, booking policy and lifecycle owner. Microsoft documents room mailboxes and room lists in Exchange Online; Google Workspace documents resource calendars and resource managers. These are platform-specific administration models, not proof that a third-party connector preserves every rule. Test creation, rename, move, closure and reinstatement as well as ordinary booking.
Specify booking semantics and exceptions
Define who may book, how far ahead, for how long and with which approval, recurrence, delegation, capacity, equipment and privacy rules. Test conflicts, tentative meetings, organiser changes, declined series, room swaps, time-zone and daylight-saving changes, external organisers, offline clients and late updates. RFC 5545 standardises iCalendar data, including recurrence and time-zone components; it does not guarantee identical policy or conflict behaviour across products.
Keep reservation, check-in and occupancy distinct
A reservation is not presence, a check-in is not continuous occupancy and an occupied room does not prove that the booked meeting is taking place. Define no-show and release windows, grace periods, manual override, sensor or room-system inputs and the treatment of early departures. Zoom states that its Scheduling Display can remove a booking when nobody checks in within a configured period; treat this as an attributable product assertion and acceptance-test the exact subscription, calendar, device and policy configuration.
Design accessible and resilient room journeys
Test search, booking, arrival, check-in, extension, release and fault reporting with representative users, assistive technology, colour and contrast needs, reach ranges, languages, visitors, people without smartphones and users without persistent connectivity. WCAG 2.2 is a W3C Recommendation for web content and can frame interface tests; it does not by itself certify a wall panel, mobile app or end-to-end workplace journey. Provide a usable fallback when a panel, network, identity service or calendar is unavailable.
Prove calendar and API interoperability
For each integration, specify objects, identifiers, fields, permissions, direction, cadence, ordering, retry, rate limits, deletion, replay, reconciliation and monitoring. Google documents Calendar API push notifications for resource changes but notifications can indicate that a change occurred without carrying the changed event, so consumers must retrieve and reconcile authoritative state. Test duplicates, missed or delayed events, expired subscriptions, token rotation, partial outages and recovery rather than accepting a connector logo as evidence.
Treat panels and room systems as a managed device estate
Record model, operating system, firmware, application, certificate, network segment, identity, licence, mounting, power, accessibility and support owner for each panel or controller. Microsoft publishes current Teams-panel certification and firmware tables and notes that devices may not be re-certified and can be discontinued by the manufacturer. Certification is programme- and version-specific; it does not prove whole-system suitability, continuing support or interoperability outside the stated configuration.
Plan security, privacy and safe operation
Separate room availability from meeting title, organiser, attendee, transcript, audio, video and sensor data. Define least-privilege service accounts, device hardening, patching, secrets and certificate renewal, logging, remote administration, retention, display redaction and incident response. Establish which system may capture or expose each data class and assess the actual jurisdictions, people, devices and purposes. Category membership or vendor headquarters does not establish legal applicability or compliance.
Define service and utilisation measures before reporting
Keep booked time, checked-in time, sensed occupancy, meeting duration, room availability, release events, faults and service response distinct. Record numerator, denominator, opening hours, time zone, exclusions, missingness and source version for every measure. Use utilisation evidence to investigate demand, room mix and operating policy; do not treat it as proof of employee performance, meeting value, causal savings or market-wide behaviour.
Separate generally available, preview and retired capability
For the quoted edition and region, label every material feature, connector and device function as generally available, preview or beta, announced, limited rollout, deprecated or retired. Keep supplier assertions attributable. Microsoft device release notes, for example, say that Teams-panel app version 1449/1.0.97.2025385601 or later is required for calendar continuity as Exchange Web Services is deprecated in Exchange Online. Recheck the current release notes and tenant requirements before approval and rollout.
Rehearse migration, coexistence and rollback
Inventory rooms, aliases, resources, delegates, recurring series, equipment, policies, panels, licences and integrations before design. Profile duplicates, orphaned resources, invalid time zones and stale meetings. Define mapping, exclusions, freeze windows, pilot groups, reconciliation, cutover, coexistence, rollback and post-migration ownership. Test what happens when old and new services both receive changes and how users recognise the authoritative booking surface.
Contract for support and lifecycle evidence
Allocate responsibility across workplace, IT, AV, facilities, identity, networks, vendors and local support. Contract for supported calendar and meeting-platform versions, device and operating-system lifecycles, firmware policy, security maintenance, API change and deprecation notice, spare and replacement availability, remote diagnosis, service levels, configuration export, event and metric export, archival access and transition assistance. Microsoft states that Teams Rooms supports only the current and previous major application releases and that OEM hardware support remains a separate lifecycle consideration.
Questions for procurement and operating teams
Which room-management functions are in scope, and which adjacent booking, AV, access, sensor and analytics systems remain separate?
Which calendar or room record is authoritative, who owns it and how are moves, renames, closures and reinstatement controlled?
How are permissions, approval, recurrence, delegation, conflicts, time zones, external organisers and privacy handled?
How are reservation, check-in, presence, occupancy, meeting duration and room availability defined and kept distinct?
What no-show, release, grace-period and manual-override rules apply, and which evidence triggers them?
How do representative users complete each journey when a panel, smartphone, identity service, calendar or network is unavailable?
For each integration, what are the identifiers, permissions, semantics, event order, retries, deletions, replay and reconciliation controls?
Which panel, controller, firmware, operating-system, certificate and licence combinations are supported at each site?
Which booking, identity, attendee, audio, video, transcript or sensor data is exposed, retained or exported, and why?
What are the numerator, denominator, operating hours, exclusions, missingness and source version for every room metric?
Which capabilities are generally available, preview or beta, announced, limited rollout, deprecated or retired for the quoted configuration?
What source defects, migration mappings, coexistence rules, acceptance thresholds, reconciliation and rollback controls are required?
Who owns monitoring, support, patches, certificates, spares, vendor escalation and local fallbacks after launch?
What export, deprecation, hardware lifecycle, replacement and transition commitments are testable in the contract?
Microsoft Learn · Current product documentation · Source checked 14 October 2026
Documents room and equipment mailboxes, room lists, booking options and delegates in Exchange Online. It is platform documentation, not proof that a third-party integration preserves the configured behaviour.
Microsoft Learn · Current product planning documentation · Updated 5 March 2026; source checked 14 October 2026
Microsoft planning guidance covering room components, licences, operations and procurement. Product and licence assertions are attributable to Microsoft and require configuration-specific verification.
Microsoft Learn · Current certification, firmware and support tables · Source checked 14 October 2026
Microsoft programme status for listed models and versions. Certification and firmware entries change and do not prove complete solution suitability or continuing OEM support.
Microsoft Learn · Current vendor release notes · Source checked 14 October 2026
Version-specific Teams-panel changes and Microsoft's EWS-deprecation warning. Recheck the deployed app, tenant, calendar and licence before relying on a stated capability or remediation.
Microsoft Learn · Current vendor lifecycle documentation · Source checked 14 October 2026
Microsoft application and Windows support policy, including N and N-1 app support and separate OEM hardware lifecycles. It does not state support for every device or configuration.
Zoom Support · Current vendor product documentation · Source checked 14 October 2026
Zoom's description of scheduling-display and check-in behaviour. Treat as a vendor assertion and verify subscription, device, calendar integration, configuration and rollout status.
Google Workspace Admin Help · Current platform administration guidance · Source checked 14 October 2026
Google Workspace resource-calendar sharing, manager permissions and approval workflow. It does not prove equivalent behaviour in a connected room product.
Google for Developers · Current API documentation · Source checked 14 October 2026
Documents notification channels and resource-change signals. A notification is not the changed event, and documented API behaviour does not prove a configured integration is complete or resilient.
Internet Engineering Task Force · Published Standards Track RFC; subsequently updated by later RFCs · September 2009; source checked 14 October 2026
Core iCalendar data format, including recurrence and time-zone components. Conformance does not guarantee identical booking policy, conflict handling or end-to-end interoperability.
World Wide Web Consortium · W3C Recommendation · Current Recommendation dated 12 December 2024; source checked 14 October 2026
Technology-neutral testable criteria for web content. It is not a certification of a wall panel, mobile application, physical installation or end-to-end meeting-room journey.
Evidence checked 15 October 2026 · Updated 15 October 2026
Property, lease, space planning and digital twin
A buyer guide for connecting portfolio, lease and space records with BIM-linked operations and digital twins without confusing a model, dashboard or vendor roadmap with an authoritative operating system.
This guide frames buyer questions and evidence expectations. It does not endorse a supplier, certify a model or integration, determine an accounting treatment, establish legal or regulatory applicability, or prove that a digital twin is fit for a particular operational decision. Apply the relevant property, accounting, information-management, security and professional requirements for each organisation, asset and jurisdiction.
Set the category boundary before selecting a platform
Separate portfolio and property records, lease administration, accounting feeds, spatial planning, BIM information, operational asset data, simulation and visualisation. Name which decisions each service must support and which adjacent systems remain authoritative, including finance, IWMS, maintenance, booking, BMS and document management. A broad suite label should not turn overlapping modules into one undifferentiated requirement.
Define outcomes and accountable owners
Translate ambitions such as portfolio visibility, obligation control, space optimisation or a digital twin into specific decisions, users, service levels and acceptance evidence. Assign an owner for every material data domain and workflow. ISO 41001:2018, including its 2024 climate-action amendment, provides a management-system context for facilities services but is under revision; it does not certify a property platform or prescribe a product architecture.
Establish authoritative identities and records
Define stable identifiers and ownership for legal entities, portfolios, properties, parcels, buildings, floors, spaces, leases, contracts, parties, assets, documents and models. Record the source of truth, effective dates, status, hierarchy and reconciliation rule for each object. Treat addresses, names and vendor-generated keys as attributes rather than dependable cross-system identities, and test mergers, subdivisions, renames, disposals and reacquisitions.
Keep lease abstraction, legal interpretation and accounting distinct
A lease record may support critical dates, options, obligations, payments, documents and workflow, but software extraction does not settle ambiguous terms or the accounting treatment. IFRS 16 sets principles for recognition, measurement, presentation and disclosure of leases and has related active projects; other jurisdictions and policies differ. Define accountable review, approval, change control and the hand-off to the finance ledger instead of treating a parsed clause or calculated schedule as final authority.
Control measurement basis and spatial versions
Record the measurement basis, standard, unit, geometry source, survey date, exclusions, rounding, status and approver for every reported area. IPMS: All Buildings provides a published cross-asset measurement framework. RICS says its older second-edition property-measurement statement is archived and that members should use the appropriate IPMS or current Code of Measuring Practice basis; the proposed seventh-edition code remained consultation material after the consultation closed on 13 October 2026. Do not mix bases or compare areas without an explicit conversion and audit trail.
Define what the digital twin must do
Specify the real-world entity, decision, update frequency, state variables, models, controls, users and consequence of stale or incorrect state. A three-dimensional model, data lake, dashboard or live sensor feed is not automatically a digital twin. NIST IR 8356 describes digital twins as electronic representations of real-world entities that can show state and transitions, while also identifying traditional and novel security and trust concerns. Require evidence for the claimed operational function rather than accepting the label.
Specify information requirements across the asset life cycle
Define what information is required, why, by whom, at which event, in which format, to what quality and for how long. ISO 19650-3:2020 remains the published standard for information management in the operational phase and was confirmed in 2024, but ISO marks it to be revised. ISO/DIS 19650-3 is an under-development draft and must not be treated as the current published requirement. Test transfer, validation, approval and continuity when an asset, operator, model or service provider changes.
Prove BIM exchange at the required profile and workflow
ISO 16739-1:2024 publishes the IFC data schema for information exchanged across construction and facility-management workflows. IFC conformance alone does not prove that the required objects, properties, classifications, relationships, units, geometry and change behaviour survive a round trip. Use explicit exchange requirements and, where suitable, buildingSMART Information Delivery Specification rules; test representative files, model-view assumptions, validation errors, extensions, coordinate systems and downstream use.
Test real-estate semantics and APIs separately
A transport or API description does not settle the meaning of a property, lease, area, option or occupancy record. OSCRE's Industry Data Model covers real-estate lifecycle use cases including lease administration and space management; adoption and implementation still require a governed mapping. OpenAPI 3.2.1 can describe HTTP interfaces but does not prove semantic alignment, data completeness or resilient operation. For each integration, test identifiers, fields, units, effective dates, permissions, events, ordering, retries, deletions, replay, reconciliation and monitoring.
Make data quality and provenance operational
Define completeness, validity, timeliness, consistency, uniqueness and fitness thresholds by decision, not as one generic score. Preserve source, observation time, effective time, transformation, approver, model version and supersession history. W3C's Data Quality Vocabulary can represent quality measurements, policies and annotations, but a vocabulary does not improve the underlying records. Route exceptions to named owners and show users when a scenario, map or dashboard rests on missing, estimated or stale inputs.
Govern scenarios, forecasts and automated recommendations
For portfolio, lease and space scenarios, retain the question, baseline, model version, assumptions, constraints, exclusions, horizon, sensitivity and accountable decision. Keep observed facts, contractual terms, forecasts and recommendations distinguishable. A space-release or investment scenario should not be presented as a realised saving, causal result or market benchmark, and a generated option should not change an authoritative record without approval.
Design security, privacy and control boundaries
Map users, service accounts, models, files, sensors, operational systems, remote support and data flows. Apply least privilege, segregation, encryption and key ownership, logging, retention, secure export, incident response and recovery proportionate to the use case. Treat any route from a twin or analytics service into building controls as a separate operational-technology decision with explicit authorisation, safe failure and manual override. Category membership or vendor headquarters does not establish legal applicability or compliance.
Separate generally available, preview and retired capability
For the quoted edition, region, hosting model and partner dependency, label every material module, connector, model, automation and AI feature as generally available, preview or beta, announced, limited rollout, deprecated or retired. Keep supplier assertions attributable and recheck them before approval and rollout. A roadmap promise, self-reported standards implementation or demonstration should not satisfy a mandatory requirement without a specific, enforceable commitment and acceptance test.
Rehearse migration, coexistence and rollback
Inventory sources, contracts, documents, hierarchies, identifiers, units, measurement bases, models, integrations, reports and historical versions. Profile duplicates, gaps and conflicting effective dates before design. Define mapping, enrichment, exclusions, freeze windows, pilot assets, reconciliation, cutover, coexistence, rollback and post-migration ownership. Test whether legacy and new systems can both change data, how conflicts are resolved and how users recognise the authoritative record.
Contract for lifecycle and exit evidence
Allocate responsibility across real estate, legal, finance, workplace, facilities, BIM, data, security, IT and suppliers. Contract for supported formats and API versions, model and rule versioning, security maintenance, data-quality reporting, change and deprecation notice, service levels, audit history, configuration and bulk-data export, archival access, model portability, escrow where justified, transition assistance and deletion evidence. Prove that the organisation can retain usable records and operate critical workflows after a supplier, module or asset changes.
Questions for procurement and operating teams
Which portfolio, property, lease, space, BIM and twin decisions are in scope, and which adjacent systems remain authoritative?
What stable identifiers, owners, hierarchies, effective dates and reconciliation rules apply to every core object?
Which lease terms may be extracted automatically, which require accountable interpretation and approval, and how does the result reach finance?
Which measurement basis, units, survey date, exclusions and spatial version support each area figure?
What real-world entity and operational decision does each claimed digital twin represent?
What state, latency, model, trust and failure requirements must the twin meet before anyone relies on it?
Which information requirements apply at acquisition, design, handover, operation, change, disposal and transfer?
Which IFC version, model view, IDS rules, classifications, properties and round-trip tests are required?
How are OSCRE or other real-estate semantics mapped to the organisation's canonical model?
For every API or event flow, what are the identifiers, fields, permissions, ordering, retries, deletions, replay and reconciliation controls?
Which data-quality dimensions, thresholds, provenance and exception owners apply to each decision?
How are observed facts, contractual terms, assumptions, forecasts and recommendations kept distinct?
Which users, models, sensors or integrations can influence operational systems, and what safe failure and manual override exist?
Which capabilities are generally available, preview or beta, announced, limited rollout, deprecated or retired for the quoted configuration?
What defects, mappings, coexistence rules, acceptance thresholds, reconciliation and rollback controls govern migration?
Which supported-format, API, security, export, archival, portability, deprecation and transition commitments are contractually testable?
International Organization for Standardization · Published standard with 2024 amendment; revision under development · April 2018; status checked 15 October 2026
Management-system requirements for facility management. It does not certify a property platform, product architecture or configured deployment.
International Organization for Standardization · Published and current; revision under development · July 2020; confirmed 2024; status checked 15 October 2026
Operational-phase information-management requirements. ISO marks this edition to be revised, so buyers should record the version used.
International Organization for Standardization · Draft International Standard under development; not final · Enquiry-stage status checked 15 October 2026
Proposed second edition. It is a draft and must not be treated as the current published ISO 19650-3 requirement.
International Organization for Standardization · Published International Standard, edition 2 · March 2024; source checked 15 October 2026
Open BIM data schema for exchange across construction and facility-management workflows. Schema conformance does not prove required content or end-to-end interoperability.
buildingSMART International · Current buildingSMART technical specification resource · Current source checked 15 October 2026
Machine-interpretable exchange requirements for objects, classifications, properties, values and units. Implementation still needs representative validation.
US National Institute of Standards and Technology · Final NIST Interagency Report 8356 · 14 February 2025; source checked 15 October 2026
Digital-twin concepts, characteristics, uses, cybersecurity and trust considerations. It is technical guidance, not product certification or a building-specific assurance conclusion.
OSCRE International · Current industry data-model resource · Source checked 15 October 2026
Real-estate lifecycle semantics, including lease-administration and space-management use cases. Adoption does not prove that a vendor mapping is complete or correct.
Royal Institution of Chartered Surveyors · Current sixth edition; proposed seventh edition remains consultation material · Seventh-edition consultation closed 13 October 2026; status checked 15 October 2026
RICS says the sixth edition and/or IPMS: All Buildings remain in use until a final successor is published. The consultation draft is not a final standard.
IFRS Foundation · Issued IFRS Accounting Standard; related active projects listed · Issued January 2016; current source checked 15 October 2026
Principles for recognition, measurement, presentation and disclosure of leases. Applicability and accounting treatment require accountable professional judgement.
World Wide Web Consortium · W3C Note · 15 December 2016; source checked 15 October 2026
Vocabulary for publishing data-quality measurements, policies and annotations. Using the vocabulary does not establish the quality or fitness of a dataset.
Evidence checked 16 October 2026 · Updated 16 October 2026
Data, BI, integration and AI automation
A buyer guide for creating dependable data, integration, analytics and automation services without confusing a connector, dashboard or AI demonstration with an operationally controlled decision system.
This guide frames buyer questions and evidence expectations. It does not endorse a supplier, certify an interface, dataset or AI system, declare a vendor legally compliant, or prove that an automated recommendation is suitable for a particular decision. Apply the relevant information-governance, security, privacy, operational and professional requirements for each organisation, deployment and jurisdiction.
Set the category boundary before selecting a platform
Separate data platforms, warehouses, lakehouses, catalogues, master-data services, business intelligence, integration platforms, workflow automation and AI-enabled orchestration. Name which cross-system decisions and services are in scope and which operational applications remain authoritative. A broad platform label should not turn maintenance, booking, access, BMS, finance or property workflows into undifferentiated data requirements.
Define decisions, users and accountable owners
Translate ambitions such as a single source of truth, real-time insight or intelligent automation into named decisions, users, inputs, tolerances, service levels and acceptance evidence. Assign an accountable owner to every material data domain, metric, integration, model and automated action. Decide which outcomes require human review and which can safely proceed without it before evaluating product features.
Establish authoritative identities and temporal rules
Define stable identifiers, ownership, hierarchies, effective dates and reconciliation rules for organisations, sites, buildings, floors, spaces, assets, people, suppliers, contracts, work orders and sensors. Treat labels, addresses and vendor-generated keys as attributes rather than dependable cross-system identities. Test renames, mergers, splits, late corrections, deletions and slowly changing relationships instead of assuming the latest value explains history.
Contract the data from source to consumption
Specify the owner, schema, semantics, units, null behaviour, allowed values, effective time, observation time, update method, quality thresholds, security classification and change policy for each dataset. Define how producers announce breaking changes and how consumers validate them. A successful pipeline run does not prove that the information is complete, current, comparable or fit for the decision using it.
Choose batch, change-data and event patterns deliberately
Match batch loads, change-data capture, streams and request-response APIs to the decision latency, recovery and cost required. Test initial loads, increments, duplicates, out-of-order messages, late data, corrections, backfills, replay, throttling and downstream failure. Record when state becomes effective as well as when it was observed and processed, especially where building, lease or maintenance data can arrive after the event.
Test HTTP API contracts beyond the specification file
OpenAPI 3.2.1 is the latest published OpenAPI specification and describes HTTP interfaces. It does not prove semantic alignment, complete coverage, availability or resilient operation. For every required flow, test authentication, authorisation, identifiers, fields, pagination, filtering, bulk operations, webhooks, versioning, rate limits, error responses, idempotency, retries, deletions, reconciliation and support for the quoted product edition.
Govern message and event contracts
AsyncAPI 3.1.0 describes message-driven APIs across protocols, while CloudEvents v1.0.2 is the latest stable CloudEvents core specification and the main branch remains a working draft. Neither proves that two configured products interoperate. Specify channels, schemas, event types, keys, ordering, delivery guarantees, duplicate handling, idempotency, retention, replay, dead-letter handling, access control, observability and version coexistence, then test representative failure conditions.
Make discovery, lineage and provenance usable
Catalogue datasets, interfaces, reports, metrics, transformations, models and owners at the level needed to investigate a decision. W3C DCAT 3 is a Recommendation for interoperable data catalogues, and PROV-O is a Recommendation for representing provenance; using either vocabulary does not create accurate lineage. Preserve source, transformation, code and model version, effective time, approver and supersession so a user can trace a displayed value or automated action.
Measure data quality against the decision
Define completeness, validity, accuracy, consistency, uniqueness, timeliness and representativeness thresholds by use case rather than publishing one generic score. ISO/IEC 5259-1:2024 provides terminology and examples for analytics and machine-learning data quality, ISO/IEC 5259-2:2024 defines measures, and ISO/IEC 5259-3:2024 addresses management requirements and guidance. W3C's Data Quality Vocabulary can represent measurements and policies, but none of these sources certifies the quality of a particular dataset.
Control metrics and the semantic layer
For each KPI, record the business question, grain, numerator, denominator, population, exclusions, unit, time zone, calendar, aggregation, effective-date rule, missingness treatment and accountable owner. Test drill-through to contributing records and reconcile against authoritative sources. Similar labels such as occupancy, utilisation, cost, failure or saving can represent different measures, and a dashboard total should not become an accepted fact without its definition and lineage.
Observe services and reconcile state
Monitor freshness, volume, schema change, quality exceptions, processing latency, failed records, queue depth, retries, duplicates and divergence between source and target. Define service levels by business consequence, not only platform uptime. Provide named routes for triage, correction, replay and user communication, and rehearse recovery after a partial load, expired credential, provider outage or downstream rejection.
Keep workflow automation within a safe control boundary
Distinguish suggestions, draft records, approval workflows and autonomous actions. Apply least privilege, separation of duties, scoped service accounts, secret rotation, input validation, idempotency, rate limits, transaction boundaries, audit logging, manual override and rollback. Treat any path into building controls, physical access, payments, safety processes or employment decisions as a separate high-consequence design with explicit authorisation and safe failure.
Apply AI governance to the organisation and use case
ISO/IEC 42001:2023 specifies requirements for an organisational AI management system; it does not certify a particular model or deployment merely because a supplier holds a certificate. NIST AI RMF 1.0 is voluntary, non-sector-specific guidance for organisations designing, developing, deploying or using AI systems, and NIST states that version 1.0 is being revised. Map governance, risk, testing, monitoring and accountability to the actual use case, affected people and operating environment.
Evaluate generative AI and retrieval separately
For assistants, retrieval-augmented generation and agentic workflows, retain the user question, authorised sources, retrieval results, prompt, model and tool versions, output, human decision and feedback where proportionate. NIST AI 600-1 is a cross-sectoral companion profile to AI RMF 1.0 for generative-AI risks. Test unsupported answers, source attribution, prompt injection, sensitive-data leakage, permission bypass, model change, evaluation coverage and behaviour when no reliable answer is available.
Separate generally available, preview and retired capability
For the quoted edition, region, hosting model and dependencies, label every connector, model, agent, automation, semantic feature and governance control as generally available, preview or beta, announced, limited rollout, deprecated or retired. Record model and third-party-provider dependencies and recheck supplier assertions before approval and rollout. A roadmap promise, demonstration or standards logo should not satisfy a mandatory requirement without an enforceable commitment and acceptance test.
Rehearse migration, coexistence and exit
Inventory source systems, identities, schemas, transformations, reports, metrics, histories, models, prompts, evaluations, workflows, credentials and retention obligations. Profile duplicates, gaps and conflicting effective dates before design. Define mapping, enrichment, exclusions, cutover, coexistence, reconciliation, rollback and post-migration ownership, then contract for supported exports, configuration and code portability, model and prompt history, deprecation notice, transition assistance and deletion evidence.
Questions for procurement and operating teams
Which cross-system decisions and services are in scope, and which operational applications remain authoritative?
Who owns each data domain, metric, interface, model and automated action?
Which stable identifiers, hierarchies, effective dates and reconciliation rules apply to every core object?
What schema, semantics, units, null behaviour, quality thresholds and change policy form each data contract?
Which batch, change-data, event or request-response pattern matches the required latency and recovery?
How are late, duplicated, deleted, corrected, backfilled and out-of-order records handled?
Which OpenAPI version, endpoints, permissions, limits, errors and versioning behaviour are acceptance-tested?
Which AsyncAPI or event contracts define schemas, ordering, delivery, idempotency, retention, replay and dead-letter handling?
Can a user trace a metric or automated action to its source, transformation, code or model version and approval?
Which data-quality dimensions and thresholds apply to each decision, and who resolves exceptions?
What numerator, denominator, population, grain, exclusions, time zone and missingness treatment define every KPI?
Which freshness, quality, latency and reconciliation signals trigger an operational response?
Which workflows create a suggestion, draft, approval or autonomous action, and what safe failure and rollback exist?
Which users, systems and data can each service account, model or agent access or change?
How are AI purpose, risk, evaluation, human oversight, monitoring and incident ownership defined for the actual use case?
How are generated answers grounded, attributed, tested and withheld when reliable evidence is unavailable?
Which capabilities are generally available, preview or beta, announced, limited rollout, deprecated or retired for the quoted configuration?
What mappings, coexistence rules, exports, histories, acceptance thresholds, transition support and deletion evidence govern migration and exit?
OpenAPI Initiative · Latest published OpenAPI specification · 10 September 2026; source checked 16 October 2026
Language-agnostic HTTP API description. An OpenAPI document does not prove semantic alignment, complete coverage, availability or resilient end-to-end integration.
AsyncAPI Initiative · Published specification · 31 January 2026; source checked 16 October 2026
Protocol-agnostic description for message-driven APIs. A specification document does not prove configured interoperability, delivery behaviour or operational resilience.
Cloud Native Computing Foundation · v1.0.2 latest stable core specification; main branch is a working draft · Repository status checked 16 October 2026
Common event-envelope specification and protocol bindings. Conformance does not settle domain semantics, ordering, delivery guarantees, replay or operational support.
World Wide Web Consortium · W3C Recommendation · 22 August 2024; source checked 16 October 2026
Vocabulary for interoperable data catalogues. Adoption does not establish that catalogue records, ownership, quality or lineage are complete or correct.
International Organization for Standardization · Published International Standard, edition 1 · July 2024; source checked 16 October 2026
Requirements and guidance for managing analytics and machine-learning data quality. It is not evidence that a vendor's dataset or deployment is reliable.
US National Institute of Standards and Technology · Published voluntary framework; NIST states that version 1.0 is being revised · 26 January 2023; status checked 16 October 2026
Voluntary, non-sector-specific and use-case-agnostic AI risk-management guidance. It is not product certification or proof of configured suitability.
US National Institute of Standards and Technology · Published NIST AI 600-1 cross-sectoral profile · 26 July 2024; page updated 8 April 2026; source checked 16 October 2026
Companion resource for managing generative-AI risks. It does not certify a model, retrieval system, agent or deployment.
Evidence checked 17 October 2026 · Updated 17 October 2026
AI and intelligent automation
A buyer guide for predictive models, computer vision, natural-language systems, optimisation and autonomous workflows in the built environment, with accountable decision rights, representative evaluation and safe operating boundaries.
This guide frames buyer questions and evidence expectations. It does not endorse a supplier, certify a model or AI system, determine legal or regulatory applicability, or prove that an output is suitable for a particular operational decision. Apply the relevant professional, safety, security, privacy and legal requirements for each organisation, use case, site and jurisdiction.
Start with the decision and the non-AI alternative
Define the decision, affected people and physical or commercial consequence before selecting a model. State what predictive analysis, computer vision, natural-language interaction, optimisation or automation must improve over the current process and a simpler rules-based alternative. Record the baseline, constraints, unacceptable outcomes and evidence needed to proceed; an impressive demonstration is not proof that AI is necessary or effective in the buyer's environment.
Draw the complete AI system boundary
Map the model, provider, prompts, retrieval sources, training or reference data, tools, sensors, integrations, users, reviewers and downstream actions as one system. Identify which party owns each component and which version, hosting region and product edition are included. An embedded feature or third-party model can materially change risk even when the main application is unchanged.
Assign governance and decision rights
ISO/IEC 38507:2022 addresses governance implications of organisational AI use, while ISO/IEC 42001:2023 specifies an organisational AI management system. Use them as governance context, then name the accountable executive, use-case owner, technical owner, risk owner, approver and operator for the actual deployment. Organisational certification does not certify a particular model, output or configured use case.
Classify consequence and preserve meaningful human authority
Separate information retrieval, recommendation, drafting, approval and autonomous action. Define which decisions require a person to understand the evidence, challenge the output, request more information and choose a different action without penalty or excessive delay. A nominal human-in-the-loop is not substantive oversight if the interface, workload, timing or organisational incentives make review ineffective.
Turn desired outcomes into representative acceptance tests
Define the target population, sites, seasons, operating conditions, comparison baseline, sample size, ground truth, exclusions, missingness and acceptance thresholds before testing. Report false positives, false negatives, calibration and subgroup or site variation where relevant, not one headline accuracy figure. Test the complete service from input and integration through output, review and action rather than evaluating a model in isolation.
Specify quality, robustness and change control
ISO/IEC 25059:2023 provides a published quality model for AI systems, while its edition-two successor ISO/IEC FDIS 25059 is under development and not final. Select quality characteristics that matter to the use case, including functional suitability, reliability, robustness, explainability and real-world performance. Define operating limits, adversarial and stress tests, drift signals, revalidation triggers and approval for changes to models, prompts, data, thresholds or providers.
Govern the data life cycle and provenance
ISO/IEC 8183:2023 describes data-life-cycle stages from acquisition and creation through development, deployment, maintenance and decommissioning. For every material dataset, record purpose, source, rights, collection context, population, transformations, quality limitations, effective dates, access, retention and deletion. Preserve enough provenance to reproduce an evaluation or explain an operational output, while limiting personal or sensitive data to what the use case genuinely requires.
Assess foreseeable impacts through the system life cycle
ISO/IEC 42005:2025 provides guidance for AI system impact assessment across effects on individuals, groups and society. Use an impact assessment to identify who may benefit, be burdened or be unable to contest an outcome; evaluate intended use, foreseeable misuse, accessibility, environmental and operational effects; and track mitigations and residual uncertainty. This is decision evidence, not a universal legal test or certification.
Evaluate generative AI, retrieval and tool use separately
NIST AI 600-1 is a cross-sectoral companion profile for generative-AI risks. For assistants and retrieval-augmented generation, test unsupported answers, source attribution, retrieval coverage, prompt injection, sensitive-data leakage, permission bypass, refusal, model change and behaviour when reliable evidence is unavailable. Retain the authorised sources, retrieval result, prompt, model and tool versions, output and human decision where proportionate to the consequence.
Bound agents and automated workflows
Give each model, agent and service account the least access and authority needed. Define approved tools, input validation, transaction boundaries, idempotency, rate limits, separation of duties, logging, spend or action limits, approval points, manual override, rollback and safe stop. Simulate duplicated requests, partial failure, stale context, malicious instructions and unavailable dependencies before permitting an automated action to change a system of record or physical operation.
Protect the operational-technology and physical-safety boundary
NIST SP 800-82 Revision 3 is current final guidance for operational-technology security and includes building automation; Revision 4 is an initial public draft, not final, with comments due 30 November 2026. Treat any AI route into building controls, access, alarms, maintenance priorities or safety processes as a separate high-consequence design. Preserve deterministic protections, local control, validated fallback, explicit authorisation, manual authority and tested recovery rather than allowing AI to silently override an engineered control.
Prove integrations and the operating model
Test the exact APIs, events, sensors, identity services, data sources and target actions for the quoted edition, region and hosting model. Verify identifiers, semantics, units, timestamps, permissions, quality flags, latency, rate limits, errors, retries, reconciliation and degraded behaviour. Assign monitoring, exception handling, incident response, user support and periodic re-evaluation to named teams; a connector logo or vendor assertion is not configured interoperability evidence.
Separate generally available, preview and retired capability
Label every material model, agent, connector, governance control and automated action as generally available, preview or beta, announced, limited rollout, deprecated or retired for the quoted configuration. Keep supplier claims attributable, record third-party model and service dependencies, and recheck status before approval and rollout. A roadmap promise or demonstration should not satisfy a current mandatory requirement without an enforceable commitment and acceptance test.
Monitor outcomes, incidents and material change
Monitor input and output quality, performance against the baseline, drift, overrides, complaints, near misses, incidents, unavailable dependencies and actions outside the validated operating range. Define thresholds for warning, suspension, rollback and accountable review. Reassess after a model, provider, data source, workflow, population, site or regulatory context changes; continuing service availability is not evidence that the system remains suitable.
Rehearse migration, coexistence and exit
Inventory data, labels, evaluations, models, prompts, retrieval indexes, workflows, tools, permissions, logs, configurations and downstream dependencies. Define coexistence, cutover, reconciliation and rollback before scale-up. Contract for usable exports, evaluation history, model and prompt version records, interface stability, deprecation notice, security support, transition assistance, deletion evidence and a workable non-AI or replacement process if the supplier or capability changes.
Questions for procurement and operating teams
Which decision, population and built-environment outcome are in scope, and could a non-AI method meet the need?
What model, provider, data, prompt, retrieval, tool, integration and human components form the complete AI system?
Who is accountable for the use case, risk, technical operation, approval, monitoring and incident response?
Which outputs inform, recommend, draft, approve or act, and where is meaningful human authority required?
What baseline, sample, ground truth, exclusions, missingness and acceptance thresholds support each performance claim?
How do false positives, false negatives, calibration and performance vary by site, season, condition or affected group?
What operating limits, stress tests, drift signals and change events trigger revalidation or suspension?
What are the source, rights, population, transformations, limitations, retention and deletion rules for every material dataset?
Who may benefit or be burdened, what foreseeable misuse exists, and how can an affected person obtain review or redress?
How are generated answers grounded, attributed, tested and withheld when reliable evidence is unavailable?
Which tools and records can an agent access or change, and what least-privilege, approval, idempotency and action limits apply?
What deterministic protection, local control, safe fallback and manual override exist at any OT or physical-safety boundary?
Which exact APIs, events, sensors, identities, permissions, semantics and failure behaviours are acceptance-tested?
Which capabilities are generally available, preview or beta, announced, limited rollout, deprecated or retired for the quoted configuration?
Which model, data, prompt, provider, workflow, population or site changes require fresh approval?
What monitoring, complaints, near-miss and incident evidence can operating teams inspect?
How will models, prompts, evaluations, data, configurations, logs and workflows coexist, export, reconcile and roll back?
What supported-version, security, deprecation, transition, deletion and non-AI fallback commitments are contractually testable?
International Organization for Standardization · Published International Standard, edition 1 · February 2023; source checked 17 October 2026
Guidance for integrating AI-specific risk management into organisational activities. It is not product certification or a deployment-specific assurance conclusion.
International Organization for Standardization · Published International Standard, edition 1 · December 2023; source checked 17 October 2026
Processes for defining, controlling, managing and improving AI systems across their life cycle. It does not prove that a supplier has implemented them effectively.
International Organization for Standardization · Published International Standard, edition 1 · July 2023; source checked 17 October 2026
Defines data-processing stages and actions across the AI system life cycle. It does not prescribe a particular tool or certify dataset quality or rights.
International Organization for Standardization · Published International Standard, edition 1; expected to be replaced · June 2023; status checked 17 October 2026
Current published AI system quality model. ISO identifies an edition-two FDIS successor, so buyers should record the edition used.
International Organization for Standardization · Final Draft International Standard under development; not final · Edition-two approval-stage status checked 17 October 2026
Proposed successor to ISO/IEC 25059:2023. It is under development and must not be presented as the current published standard.
US National Institute of Standards and Technology · Published voluntary framework; NIST states that version 1.0 is being revised · 26 January 2023; status checked 17 October 2026
Voluntary, non-sector-specific and use-case-agnostic AI risk-management guidance. It is not product certification or proof of configured suitability.
US National Institute of Standards and Technology · Published NIST AI 600-1 cross-sectoral profile · 26 July 2024; page updated 8 April 2026; source checked 17 October 2026
Companion resource for managing generative-AI risks. It does not certify a model, retrieval system, agent or deployment.
US National Institute of Standards and Technology · Ongoing profile-development concept note; not final guidance · Created 6 April 2026; updated 17 July 2026; source checked 17 October 2026
Signals issues NIST intends to address for AI in critical infrastructure, including facility and plant systems. It is a concept note, not a final profile or compliance test.
US National Institute of Standards and Technology · Final guidance · September 2023; status checked 17 October 2026
Final OT-security guidance, including building automation systems, with performance, reliability and safety considerations. It is not deployment certification.
US National Institute of Standards and Technology · Initial public draft; comments due 30 November 2026; not final · 21 September 2026
Draft successor guidance that expands OT coverage. It must not be treated as the current final publication or a mandatory requirement.
Evidence checked 18 October 2026 · Updated 18 October 2026
Energy, ESG, carbon and utilities
A buyer guide for energy and utility data, performance management, carbon accounting, demand flexibility and sustainability reporting across measurement, operations, evidence and disclosure.
This guide frames buyer questions and evidence expectations. It does not endorse a supplier, certify a product or inventory, verify reported savings, declare legal compliance or determine which reporting rules apply. Standards and disclosure frameworks still require organisation-, asset- and jurisdiction-specific scoping, competent review and tested implementation.
Define decisions, boundaries and owners
Separate operational energy management, utility procurement and billing, emissions accounting, target tracking, demand flexibility, investment appraisal and external disclosure. For each decision, define organisational and operational boundaries, sites, meters, fuels, emissions scopes, reporting periods, materiality rules, accountable owners and approval authorities. A single ESG dashboard should not silently become the authoritative source for every purpose.
Establish authoritative asset and meter identities
Create governed identities and effective dates for legal entities, portfolios, properties, buildings, tenancies, meters, submeters, accounts, tariffs, suppliers and equipment. Preserve parent-child relationships, meter exchanges, changes of occupier, acquisitions, disposals and shared services. Require reconciliation between the utility, finance, property and building-system views rather than assuming that matching labels represent the same boundary.
Preserve raw readings and data-quality evidence
Retain source readings, bills, intervals, timestamps, time zones, units, multipliers, quality flags, estimates, corrections and import receipts before transformation. Test missing intervals, duplicated values, resets, clock changes, negative readings, late bills and retrospective supplier adjustments. A complete dashboard can still rest on incomplete or estimated evidence, so procurement should specify exception queues, ownership, reconciliation and reproducible correction history.
Version energy baselines and performance indicators
ISO 50006:2023 provides guidance for establishing, using and maintaining energy performance indicators and energy baselines. Define baseline periods, relevant variables, normalisation, model uncertainty, change control and triggers for resetting a baseline. Keep absolute consumption, intensity, cost, demand and modelled performance distinct, and prevent portfolio changes or weather adjustments from silently rewriting past results.
Separate measurement from verified savings
A fall in consumption is not by itself proof that a project caused savings. ISO 50015:2014 remains current after confirmation in 2025, while IPMVP Core Concepts 2022 provides current performance-measurement and verification practice. Agree the measurement boundary, counterfactual, adjustment variables, uncertainty treatment, metering plan, non-routine events, exclusions and independent review before a performance claim is used for payment, investment or public reporting.
Make carbon calculations reproducible
For every emissions result, retain activity data, source, unit conversion, emission factor, factor geography and period, global-warming-potential basis, scope and category, ownership boundary, estimation method, exclusions and approval. Distinguish measured consumption from calculated emissions, and keep source data separate from supplier factors and reporting transformations. ISO 14064-1:2018 is published but marked to be revised; freeze the edition and calculation policy used for each reported period.
Control Scope 2 methods and contractual evidence
The GHG Protocol Scope 2 Guidance published in 2015 remains available while its revision is under development. Model location-based and market-based results separately where required, with explicit treatment of residual mixes, supplier-specific factors, certificates, contracts, temporal matching and evidence validity. The 2025–2026 consultation and feedback are development material, not a final replacement standard, so systems must preserve method versions and support restatement without overwriting prior submissions.
Plan for accounting-standard transition
GHG Protocol and ISO announced on 29 July 2026 that their corporate Scope 1, Scope 2, Scope 3, actions and market-instruments work and ISO 14064-1 will be consolidated. The current plan is a public consultation in Q2 2027 and a joint standard later, so it is announced development rather than generally available guidance. Contract for configurable methods, factor and taxonomy versioning, impact assessment, parallel runs and controlled migration rather than hard-coding one permanent calculation model.
Treat disclosure frameworks as versioned requirements
IFRS S2 is a disclosure standard, not proof that a software product or emissions inventory is compliant. The ISSB issued targeted greenhouse-gas amendments in December 2025 that apply for reporting periods beginning on or after 1 January 2027, with early application permitted. Jurisdictional adoption or other use varies, and IFRS distinguishes final profiles from in-progress snapshots. Record the exact rule set, effective period, reliefs, actor and approval basis for every reporting output.
Connect utility, building and portfolio data deliberately
Prove the full path from meter or bill to operational and reporting use. BACnet supplies building-automation messages and objects, Project Haystack 4.0.0 supplies semantic definitions, and Green Button Connect My Data supports authorised North American utility data exchange. None alone proves correct meter identity, interval coverage, units, tariff mapping, semantics, lineage or configured end-to-end interoperability. Test each required data path with representative suppliers, sites and exceptions.
Scope demand response and grid interaction separately
OpenADR 3 provides a RESTful route for demand-response functions and is not intended to replace OpenADR 2.0a or 2.0b. Specify the exact VTN and VEN roles, version, certification profile, event, price, baseline and report exchanges required. Test opt-in and opt-out, local constraints, stale events, communications failure, control authority, recovery and evidence retention before connecting events to operational controls or claiming grid-service outcomes.
Protect operational-technology boundaries
Where analytics can write to building, plant, storage or generation controls, define safe operating envelopes, human authority, segmentation, device identity, credential and certificate rotation, change approval, remote support, logging, manual override and fail-safe behaviour. NIST SP 800-82 Revision 3 is current final guidance; Revision 4 is an initial public draft, not final. Reporting convenience must not expand control authority or weaken safety and reliability controls.
Separate targets, plans and demonstrated results
Record target boundary, base year, interim milestones, scenario assumptions, responsible owner, approved interventions and dependencies. ISO 50100:2026 is a published edition-one standard for reducing energy-related Scope 1 and Scope 2 emissions and requires demonstration of absolute reduction aligned with targets, but it does not certify a supplier or a configured system. Keep targets, forecasts, projects, measured performance and verified outcomes as distinct records.
Design controls for audit and assurance
Require source-to-report lineage, calculation version, user and system changes, approvals, locked reporting periods, controlled reopening, evidence attachments and reproducible exports. Define who may change a factor, meter mapping, organisational boundary, estimate or restatement and how reviewers see the effect. Assurance workflows should reference immutable evidence and calculation versions rather than screenshots or mutable dashboards.
Plan migration, coexistence and exit
Inventory accounts, meters, interval history, bills, factors, methods, targets, disclosures, connectors, calculations, approvals and audit evidence. Define extraction formats, stable identifiers, semantic dictionaries, transformation code, reconciliation tolerances, parallel-run periods, cutover ownership, rollback and retention. Test that another team can reproduce material outputs without proprietary dashboards, opaque factors or continued supplier access.
Separate generally available capability from roadmap
For every material connector, factor library, calculation method, assurance workflow and regulatory template, record whether it is generally available, beta, announced or retired for the quoted edition, region and hosting model. Attribute vendor assertions, verify dependencies and deprecation terms, and recheck status before approval and each reporting cycle. Announced support must not satisfy a current mandatory requirement unless the commitment is specific, dated and enforceable.
Questions for procurement and operating teams
Which operational, financial, carbon-accounting, demand-response and disclosure decisions are in scope, and who owns each one?
Which entities, sites, tenancies, meters, accounts and tariffs are authoritative, and how are changes effective-dated?
Can every published figure be traced to raw readings, bills, factors, transformations, approvals and a frozen method version?
How are missing, duplicated, estimated, corrected, late and time-zone-affected readings detected and resolved?
Which ISO 50006 energy performance indicators and baselines are required, and what triggers controlled recalculation?
What measurement-and-verification plan separates observed consumption change from a supported savings claim?
Which emissions scopes, categories, factors, global-warming-potential basis and organisational boundaries apply to each output?
How are location-based and market-based Scope 2 results, instruments and residual mixes kept separate and evidenced?
How will current GHG Protocol and ISO methods coexist with the announced consolidated standard and later restatements?
Which IFRS S2 edition, amendments, effective period, jurisdictional adoption and reliefs are actually in scope?
Which BACnet objects, Haystack definitions, Green Button resources or other interfaces are required, at which versions?
How will meter identity, units, interval completeness, tariff semantics and lineage be acceptance-tested end to end?
For OpenADR, which VTN/VEN roles, versions, certification profiles, events and reports are mandatory?
Which commands can reach operational technology, who has meaningful human authority, and what happens during failure?
How are targets, forecasts, projects, measured performance and independently verified outcomes kept distinct?
Which calculation, factor, mapping and approval changes are immutable and visible to reviewers?
Can the buyer reproduce reports and calculations after export without the supplier's application or factor service?
What are the migration, coexistence, parallel-run, reconciliation, rollback and historical-retention requirements?
Which capabilities are generally available, beta, announced or retired for the contracted edition, region and deployment model?
What support, vulnerability, API, factor-library, standard-version and end-of-life commitments are contractually testable?
International Organization for Standardization · Published International Standard, edition 2; reviewed in 2024 · August 2018; status checked 18 October 2026
Requirements and guidance for establishing, implementing, maintaining and improving an energy-management system. It does not certify a product, dataset or reported result.
International Organization for Standardization · Published International Standard, edition 2 · May 2023; source checked 18 October 2026
Guidance for establishing, using and maintaining energy performance indicators and baselines, including measurement, monitoring and demonstrated improvement.
International Organization for Standardization · Published International Standard; reviewed and confirmed in 2025 · December 2014; status checked 18 October 2026
General measurement-and-verification principles for organisational energy performance. It does not verify a particular savings claim or project.
Efficiency Valuation Organization · IPMVP Core Concepts 2022 listed as the current edition · 2022; status checked 18 October 2026
Current M&V practice for energy- and water-efficiency, demand-management and renewable-energy projects. Access to the full document requires an EVO account.
International Organization for Standardization · Published International Standard, edition 1 · March 2026; source checked 18 October 2026
Requirements and guidance for reducing energy-related Scope 1 and Scope 2 emissions and demonstrating absolute reduction against targets. It does not certify a product or deployment.
International Organization for Standardization · Published International Standard, edition 2; marked to be revised · December 2018; status checked 18 October 2026
Principles and requirements for organisational GHG quantification and reporting. Programme-specific requirements remain additional, and a successor is under development.
Greenhouse Gas Protocol · Published corporate standard; revision programme in progress · Revised edition 2004; status checked 18 October 2026
Corporate-level Scope 1 and Scope 2 inventory framework. The current publication remains distinct from development work on a future consolidated GHG Protocol–ISO standard.
Greenhouse Gas Protocol · Published 2015 guidance; revision consultation closed and not final replacement guidance · 2015; consultation ran 20 October 2025–31 January 2026; checked 18 October 2026
Accounting guidance for purchased electricity and other energy. Consultation proposals and feedback are development material, not a final successor standard.
Greenhouse Gas Protocol · Official announcement; future consolidated standard under development · 29 July 2026
Announces consolidation of the corporate suite and ISO 14064-1, with consultation planned for Q2 2027. It is not generally available replacement guidance.
IFRS Foundation · Published ISSB Standard with December 2025 targeted amendments · June 2023; amendments effective 1 January 2027, with early application permitted
Investor-focused disclosure standard. Jurisdictional adoption, reliefs, effective dates and entity scope must be established separately; it does not certify software.
IFRS Foundation · Current jurisdictional profiles and in-progress snapshots · Page updated 24 September 2026; checked 18 October 2026
Distinguishes finalised jurisdiction profiles from preliminary snapshots. It is general guidance and not a substitute for jurisdiction-specific legal advice.
ASHRAE · Current official protocol resources · Source checked 18 October 2026
Building-automation communications messages, formats and rules. Protocol support does not establish point coverage, semantic quality or workflow fitness.
OpenADR Alliance · Published OpenADR 3 specification family; coexists with OpenADR 2.0a and 2.0b · OpenADR 3 launched 28 November 2023; status checked 18 October 2026
The OpenAPI YAML is normative for OpenADR 3 and certification is profile-specific. The standard does not prove safe configured control or realised grid-service outcomes.
US National Institute of Standards and Technology · Final guidance · September 2023; status checked 18 October 2026
Current final OT-security guidance, including building automation, with performance, reliability and safety considerations. It is not deployment certification.
US National Institute of Standards and Technology · Initial public draft; comments due 30 November 2026; not final · 21 September 2026
Draft successor guidance that expands OT coverage. It must not be treated as the current final publication or a mandatory requirement.
Evidence checked 19 October 2026 · Updated 19 October 2026
Indoor positioning, RTLS and asset tracking
A buyer guide for locating people, equipment and assets indoors while keeping measurement fitness, identity, interoperability, privacy, security and lifecycle evidence explicit.
This guide frames buyer questions and evidence expectations. It does not endorse a supplier, certify a product or deployment, verify an accuracy claim, declare legal compliance or determine whether tracking people is necessary or lawful. Radio, protocol and certification claims still require edition-specific, device-specific and site-specific verification.
Start with the decision and workflow
Define the operational decision before selecting a locating technology: finding mobile equipment, routing work, confirming zone entry, supporting safety, reducing search time, tracing material flow or maintaining custody. Specify who acts on a location event, how quickly, and what happens when the result is late, ambiguous or wrong. A map of moving dots is not by itself an operational outcome.
Turn the use case into acceptance measures
State the required zone, floor, room or coordinate result; horizontal and vertical error distributions; confidence; latency; update rate; availability; detection probability; false-positive and false-negative tolerances; dwell rules; and time to recover after failure. Test percentiles and difficult locations rather than accepting one average accuracy figure. Separate laboratory, line-of-sight and issuer claims from results in the intended buildings and workflows.
Choose technology by environment and behaviour
UWB, Bluetooth RSSI or angle methods, Bluetooth Channel Sounding, Wi-Fi Fine Timing Measurement, active or passive RFID, ultrasound, infrared, computer vision, cellular positioning and outdoor GNSS have different tag, anchor, power, privacy, coverage and infrastructure assumptions. They are not interchangeable. Model metal, liquids, shelving, lifts, dense equipment, moving partitions, body blocking, radio coexistence and cross-floor ambiguity before choosing a primary or hybrid architecture.
Keep asset identity separate from observed location
Create governed identities for assets, people, tags, badges, readers, anchors, zones, rooms and coordinate systems. Record binding and unbinding events, custody, tag reuse, replacements and effective dates. An observation should preserve the observed identifier, timestamp, location reference, confidence, method and processing version; the business system should not silently treat a tag identifier as permanent proof of asset identity or ownership.
Govern coordinates, maps and spatial context
Specify building, floor, room, zone and coordinate identifiers, origins, units, transforms, vertical references, map versions and effective dates. IndoorGML 1.1 can represent indoor spaces and navigation networks; IFC 4.3.2.0 can provide building and asset context. Neither automatically aligns a locating engine with live floor plans, so survey points, transformations and change control must be tested and retained.
Engineer coverage and survey evidence
Require a documented design and survey for representative spaces, heights, orientations, obstruction states and operating hours. Preserve anchor and reader placement, calibration, firmware, radio settings, interference observations and excluded areas. Agree who repeats acceptance testing after fit-out changes, racking moves, renovations, device replacement or radio-policy changes, and how unserviceable zones are made visible to users.
Design for stale, missing and conflicting events
Define clocks, time zones, synchronisation, sequence numbers, duplicate handling, buffering, event expiry, confidence thresholds and conflict resolution across edge and cloud components. Test network partition, power loss, clock drift, overloaded gateways, low batteries, missing anchors and replay after reconnection. Downstream systems must distinguish last-known, inferred and currently observed location instead of presenting stale data as live truth.
Separate the interoperability layers
Interoperability spans radio and ranging, tag and anchor profiles, coordinate and zone models, location-engine APIs, event semantics, identity mapping and business workflows. ISO/IEC 24730-1:2014 defines an RTLS application-programming-interface boundary and remains current after confirmation in 2025. IEEE 802.15.4-2024 supplies an active low-rate wireless PHY/MAC standard with precision-ranging modes. Neither proves that two selected products, their configured algorithms and a downstream application work together end to end.
Freeze editions, profiles and certification scope
Name the exact edition, profile, optional features, regional settings and certified device combination. FiRa certification addresses defined UWB device interoperability and security scope, not site accuracy or business workflow performance. An omlox Core Zone or Hub claim should identify the applicable specification and conformance evidence; the public omlox API documentation explicitly says it is not the official Hub standard. Treat logos and consortium membership as discovery evidence, not acceptance evidence.
Model events for reuse without erasing provenance
GS1 EPCIS 2.0.1 publishes normative artefacts for visibility events, including JSON-LD and OpenAPI resources. OGC API - Moving Features - Part 1 provides a REST interface and formats for time-varying location. Decide whether either fits the required event semantics, identifiers and consumers. Preserve source observations and transformations so a normalised event does not conceal device-specific confidence, coordinate conversion or filtering.
Integrate with operational systems deliberately
Map each accepted event into the CMMS, EAM, IWMS, warehouse, safety, security, building-management or workflow system that will act on it. Specify stable identifiers, ownership, API versions, authentication, rate limits, retries, idempotency, acknowledgements and reconciliation. OpenAPI 3.2.1 can describe an HTTP API, but a description does not prove semantic compatibility, data quality or configured end-to-end operation.
Minimise and govern people-location data
Tracking a badge, device or asset may still reveal a person. Define purpose, necessity, proportionality, granularity, visibility, retention, access, secondary use and deletion before collection. Separate safety or access use from performance monitoring. The NIST Privacy Framework 1.0 is current while version 1.1 remains an initial public draft; UK ICO worker-monitoring guidance is jurisdiction-specific and currently under review. Neither source determines applicability or replaces accountable legal and employee-relations review.
Secure the device-to-workflow chain
Assess tag and reader identity, secure ranging where applicable, key and certificate provisioning, firmware authenticity, debug interfaces, gateway hardening, network segmentation, cloud tenancy, API authorisation, logs and incident response. NISTIR 8259A supplies an IoT-device cybersecurity capability baseline as a starting point, not product certification. NIST SP 800-82 Revision 3 is current final OT guidance; Revision 4 is an initial public draft and must not be treated as final.
Budget for tag, battery and infrastructure lifecycle
Price tags, batteries, chargers, anchors, gateways, survey work, cabling, licences, connectivity, replacement stock, calibration, maps, firmware and operational support. Measure battery life in the contracted update pattern and environment, not only from a headline estimate. Specify supported firmware, vulnerability response, spare availability, recertification triggers, end-of-sale, end-of-support and safe disposal for every device class.
Plan coexistence, migration and exit
Inventory tag assignments, observations, zones, coordinates, transforms, maps, device configuration, calibration, identities, API contracts, rules and audit evidence. Define open export formats, event history, rate limits, parallel operation, reconciliation, cutover, rollback and decommissioning. Require a tested method to rebind tags and reproduce material events without continued supplier access or opaque proprietary coordinate conversion.
Pilot representative failure modes
Run a bounded pilot across representative buildings, materials, floors, asset speeds, densities, shifts and user groups. Pre-register acceptance thresholds and manual ground-truth methods. Include lift travel, stairwells, loading areas, metal plant rooms, outdoor transitions, device swaps, low batteries, lost connectivity and deliberate misbinding. Retain raw evidence and failed tests; do not convert a successful demonstration in one zone into a portfolio-wide performance claim.
Separate generally available capability from development
Record whether each radio mode, device profile, location service, API, connector and analytics function is generally available, beta, announced, in development or retired for the quoted hardware, software, region and hosting model. Bluetooth Core Specification 6.3 is adopted, while the Bluetooth SIG Channel Sounding page says the Ranging Profile is in development and that a hardware upgrade may be needed. IEEE P802.15.4ab is a draft enhancement project, not the current final IEEE 802.15.4 standard. ISO/IEC 18000-63:2021 is published for UHF RFID but is expected to be replaced by a revision project.
Keep business value and causation testable
Baseline current search time, loss, utilisation, response delay, inventory accuracy and manual effort with explicit definitions. Record adoption, operational changes and confounders during the pilot. A reported reduction in search time or missing assets is not automatically caused by the locating technology, and issuer accuracy claims do not establish value. Require a decision record that separates measured outcomes, source claims, assumptions and inference.
Questions for procurement and operating teams
Which decision or workflow requires location, and what action follows an event?
Is the required output a zone, room, floor, route, coordinate, proximity or custody event?
Which error percentiles, confidence, latency, update rate, availability and recovery measures are mandatory?
How will ground truth be collected in representative buildings and failure conditions?
Which technologies and hybrid methods are proposed, and what environmental assumptions does each make?
How are assets, people, tags, readers, anchors, zones and coordinate systems identified and effective-dated?
How are tag binding, unbinding, reuse, loss and replacement controlled and audited?
Which map, floor, zone, coordinate, transform and vertical-reference versions are authoritative?
Who owns the radio survey, calibration and retest after site or infrastructure changes?
How are last-known, inferred and current observations distinguished downstream?
Which ISO/IEC 24730, IEEE 802.15.4, Bluetooth, Wi-Fi, RFID, FiRa or omlox editions and profiles are required?
What does each certification or conformance result cover, and what remains a deployment test?
Which event model, API description and business identifiers are used at each integration boundary?
How are duplicates, late events, clock drift, conflicting engines, buffering and replay reconciled?
Which CMMS, EAM, IWMS, safety, security or building-system actions consume location data?
Could an asset, badge or device observation identify a person, and is that collection necessary and proportionate?
Who can see live and historical location, for which purpose, and for how long?
How are device identity, keys, firmware, gateways, APIs, logs and incident response secured?
What are the battery, tag, reader, anchor, survey, connectivity, support and replacement costs?
Which firmware, hardware, profile and API support periods and end-of-life commitments are contractual?
Can all identities, observations, maps, transforms, rules and evidence be exported in usable formats?
What parallel run, reconciliation, rollback, re-tagging and decommissioning steps are required?
Which capabilities are generally available, beta, announced, in development or retired for the contracted configuration?
Which claimed operational outcomes are measured, which are attributed source claims, and what causal uncertainty remains?
International Organization for Standardization · Published International Standard, edition 2; reviewed and confirmed in 2025 · July 2014; status checked 19 October 2026
Defines an RTLS application-programming-interface boundary. It does not prove device compatibility, site accuracy or workflow fitness.
IEEE Standards Association · Draft standards project; not a final published standard · Project status checked 19 October 2026
Development work for enhanced UWB capabilities. It must not satisfy a current requirement for a final standard unless the contract explicitly treats it as a roadmap dependency.
Bluetooth Special Interest Group · Adopted core specification · Status checked 19 October 2026
Current adopted Bluetooth core edition. Adoption of a core specification does not prove support for an optional feature, profile, device combination or site outcome.
Bluetooth Special Interest Group · Published feature overview; Ranging Profile described as in development · Source checked 19 October 2026
Describes phase-based ranging and round-trip timing, notes that algorithms are not defined by the feature and that hardware upgrades may be required. Performance statements are issuer claims, not site verification.
Wi-Fi Alliance · Current certification-programme resources · Source checked 19 October 2026
Resources for Wi-Fi Fine Timing Measurement location capabilities. Programme and accuracy statements come from the issuing alliance and do not guarantee configured site performance.
International Organization for Standardization · Published International Standard, edition 3; expected to be replaced · November 2021; status checked 19 October 2026
Air-interface parameters for RFID communications at 860 MHz to 960 MHz. A revision project is in development; this edition does not prove reader-tag interoperability or read performance in a particular site.
GS1 · Published EPCIS 2.0.1 and CBV 2.0.0 normative artefacts · Release 2.0 ratified June 2022; source checked 19 October 2026
Visibility-event specifications and validation artefacts, including JSON-LD and OpenAPI. Conformance does not establish correct identity mapping or fit for a locating workflow.
PROFIBUS & PROFINET International · Official catalogue listing omlox Core Zone 2026.08 and Hub 2023.10 specifications · Catalogue status checked 19 October 2026
Lists current published omlox specification downloads. The applicable edition, membership access, implementation and conformance evidence still need to be established for each procurement.
PROFIBUS & PROFINET International · Public developer documentation; explicitly not the official Hub standard · Source checked 19 October 2026
Useful public API documentation whose own page distinguishes it from the official member-only omlox Hub specification. Buyers should not treat it as the normative conformance source.
FiRa Consortium · Current consortium specifications; access is member-restricted · Source checked 19 October 2026
Defines UWB interoperability specifications used by the consortium. Restricted access and a device-level specification do not establish configured site performance.
FiRa Consortium · Current device certification programme · Source checked 19 October 2026
Certification addresses defined interoperability, security and ecosystem requirements. Its scope does not include site accuracy, workflow fitness or a legal-compliance opinion.
International Organization for Standardization · Published International Standard, edition 2; replaces the 2018 edition · November 2024; status checked 19 October 2026
IoT reference architecture with multiple architectural views. It does not certify a product, security design or deployment.
buildingSMART International · Official static IFC 4.3.2.0 documentation aligned with the ISO publication · Source checked 19 October 2026
Public building and infrastructure information-model documentation. It does not provide live location, guarantee identifier alignment or replace configured integration testing.
OpenAPI Initiative · Current published OpenAPI specification · Version 3.2.1; source checked 19 October 2026
Machine-readable description of HTTP APIs. An API description does not prove implementation conformance, semantics, security posture or workflow fitness.
US National Institute of Standards and Technology · Initial public draft; not final · Draft comment period closed 13 June 2025; status checked 19 October 2026
Draft update to the NIST Privacy Framework. Privacy Framework 1.0 remains the current published framework; neither publication determines legal applicability.
UK Information Commissioner's Office · Current UK guidance under review following legislative change · Status checked 19 October 2026
UK-specific data-protection guidance for monitoring workers. The page warns that it is under review; it is not universal guidance or an applicability determination.
US National Institute of Standards and Technology · Final NIST interagency report · May 2020; status checked 19 October 2026
Starting point for cybersecurity capabilities expected in securable IoT devices. It is not a product certification or complete deployment-security assessment.
US National Institute of Standards and Technology · Final guidance · September 2023; status checked 19 October 2026
Current final OT-security guidance covering systems including building automation, with performance, reliability and safety considerations. It is not deployment certification.
US National Institute of Standards and Technology · Initial public draft; comments due 30 November 2026; not final · 21 September 2026
Draft successor guidance with expanded OT coverage. It must not be treated as the current final publication or a mandatory product requirement.
Buyer decision criteria
A category is a starting boundary, not a shortlist.
Define the outcome, operating model, mandatory integrations, data constraints, assurance needs, geography and implementation capacity before treating category membership as relevance.
Common category risks
Product family and module names collapse into one record.
Integration claims omit direction, depth or edition.
Global availability is inferred from a marketing page.
Evidence coverage is mistaken for organisation-specific fit.
Latest research insight
Build evidence for the whole decision lifecycle
752 of 964 source-qualified, non-cyber built-environment records were coded at implementation, migration or operations. That is 78.0% of this failure-selected sample—not a market failure rate.
Real external cases, adapted with names and identifying details withheld. Original sources and claim records are retained internally. These are learning examples, not PROVE TDI customer results, vendor rankings or estimates of market-wide failure rates.
Facilities and asset management
Maintenance priorities need comparable asset data
A public-sector property portfolio needed to prioritise maintenance investment.
