Docs menu
Composition across systems.
Field-layer discovery establishes what exists on the network. Control-layer protocols establish what a device means inside its own domain. This page covers the layer above both: how independent building systems are composed, scoped, and governed without hardcoded addresses.
Where the existing protocol layers stop.
Each layer of the stack solves a real problem and then stops at its own boundary. Neither discovery nor control was designed to answer questions that span systems.
- SRP and DNS-SD resolve names and services, but carry no access model, no semantics, and no change record
- BACnet gives devices rich object semantics that do not extend past the BACnet network boundary
- Modbus moves registers with no inherent meaning attached to them at all
- KNX and DALI are highly capable inside lighting and shading, and opaque outside it
- Bridging any two of them has traditionally meant a bespoke gateway and a pinned IP address
CNS/CP and the named-profile approach.
One emerging approach to this gap is CNS/CP — Connectivity Naming System with Connection Profile. Rather than addressing systems by DNS name or IP, it proposes that systems interact through named Connection Profiles scoped to a context, with each node declaring a role as provider or consumer, so a system of systems can be composed from independently owned parts.
- Systems are reached through named profiles rather than network addresses
- Nodes declare provider or consumer roles rather than assuming a client-server topology
- Public common metadata is used to validate entry points before systems compose
- The stated aim is secure, composable orchestration between independently operated digital systems
CNS/CP is an emerging approach aimed at system integrators and developers, not a ratified standard on the footing of SRP (RFC 9665) or BACnet (ISO 16484-5). We describe it because it names the architectural gap precisely. The sections below cover what CMS Buildings ships against that gap today, with status stated per capability.
Orchestration capabilities and their current status.
Each capability below is owned by another page in this section, which remains the authority on its detail and status. Nothing is rounded up.
| Capability | What it does | Status |
|---|---|---|
| Named queries as governed answers | One saved query, reusable as an API endpoint and an AI tool | Available |
| Scoped access on every query | Sessions see only what the caller's access rights allow | Available |
| AI proposes, humans accept | No accept tool is exposed to any model, by construction | Available |
| Immutable audit trail | People and AI actors recorded on the same append-only trail | Available |
| Cold, warm & hot data tiers | Historical retention, recent state, and live telemetry | Available |
| Bring-your-own-cloud deployment | Run inside your own environment, operated by your team | Available |
| Per-tool AI rate limits & quotas | Granular per-tool controls beyond session-level scoping | In progress |
| Self-service capability authoring | Your team packaging a new capability without our engineering | Roadmap |
Capability packaging is real architecture today, but it is first-party: new node types and integrations are built on the same pluggable node model your workspace already runs on. Customer-authored capabilities are roadmap — see Custom Nodes & Extensibility.
Named, scoped queries instead of point-to-point integration.
The unit of composition is a named query over governed data rather than a direct connection between two systems. That inverts the usual integration burden.
- A query is defined once, named, and becomes the single answer every consumer receives
- Consumers reference the name — not an IP address, a broadcast domain, or a vendor SDK
- Access scope travels with the query, so tenant, owner, and vendor each see their own slice
- The same named query serves a dashboard, an API client, and an MCP-native AI identically
- Changing the underlying connection does not break consumers, because the name is the contract
This is the practical answer to the composition gap: a lighting system and a security system interact through named, access-scoped queries over normalized data, rather than one learning to parse the other's telegrams.
Orchestration is not a replacement for the control layer.
- It does not replace BACnet, KNX, DALI, or Modbus — those keep running the systems they run
- It does not provide deterministic real-time control loops; safety and control stay where they are
- It does not by itself make an undiscoverable device discoverable — that is the field layer's job
- It does not remove the need for a gateway where a protocol has no IP-native path