The ambiguity sits between ecosystems
KNX describes control through group addresses in an engineering project. A vendor cloud brings external identifiers, account boundaries and changeable friendly names. A resident may rename or reassign an entity because the installer’s terminology is not useful in everyday life. These representations answer different questions; disagreement is not automatically a malformed input.
The FY2026 investigation examined whether one authored SuperChart model could remain consistent across these sources and serve downstream consumers. The unit of consistency became the individual attribute. A room assignment and a display name need not have the same authority, even when they belong to the same physical device.
Separate the acting principal from the owning tenant
An authenticated operator may configure a project on someone else’s behalf. Their token establishes who is acting, but cannot substitute for the ownership recorded on the authored device model. Field synchronisation exposed devices appearing under the wrong tenant when these concepts were conflated.
The correction made the chart’s recorded tenant authoritative for ownership, and Studio’s room assignment authoritative for spatial binding. This distinction is fundamental to multi-project engineering: successful authentication does not prove that the resulting entity has been placed in the correct scope.
Resolve identity before merging personalisation
An external vendor identifier must be resolved to the internal entity identity before overrides can be applied. The granularity of the write then matters. Replacing a home’s override records as one unit allowed an update to one device to erase another device’s independent resident configuration.
The recorded progression included a correction, a rollback after regressions elsewhere in publication, and a revised implementation using per-entity upserts. This sequence identifies a deeper constraint: a merge is only as reliable as its identity key and mutation scope. Resident naming must propagate to generated views without turning an unrelated update into a destructive replacement.
| Attribute | Authoritative context | Failure avoided |
|---|---|---|
| Room binding | Studio’s authored room assignment | Vendor or transport metadata placing an entity in an inappropriate space. |
| Tenancy | Ownership recorded on the chart | Synchronising under the acting operator’s tenant. |
| Identity | External-to-internal resolution per entity | Merging an override into the wrong object. |
| Resident naming | The entity’s resident override | Replacing the chosen name or erasing unrelated overrides. |
Generate views instead of maintaining parallel models
The App entity list, scene and automation detail surfaces, non-KNX configuration and edge artefacts are derived from the authored project. Consumers still have different responsibilities, but the room, device and ownership relationships originate from the same engineering context.
Generation makes disagreement diagnosable. When a consumer’s entity appears in the wrong room, the investigation can follow the attributed source, identity mapping and generated view. Separately maintained device models would obscure that chain beneath independent edits.
Treat project composition as an invariant
A cloud-only dwelling is a valid installation. Early first-publication failures exposed an assumption that every project had KNX content and an existing chart. The engineering path was revised to permit an empty KNX configuration and bootstrap the draft state needed for a first release.
The test space therefore includes KNX-only, cloud-only and mixed compositions. A model that only behaves correctly when all integrations are present has confused one deployment pattern with the domain itself. Consumer generation and publication should respect the capabilities actually present in the project.
Validate authority through observed disagreement
The research method was a capture–correct–retest loop on real mixed-vendor project data. Room mismatches, wrong tenancy, lost overrides and failed first publication were treated as evidence about model assumptions. The result is a set of explicit attribution rules supported by those reproduction cases.
This is a different evidence base from a universal accuracy benchmark or a formal convergence proof. The report records the rules and the failures that shaped them; continuous aggregate indicators were a subsequent direction. Further vendor populations may expose conditions not present in the original projects.
From an authored chart to layered profiles
The longer-term platform direction separates semantic identity, device capability, function scope and presentation. That would allow a physical entity’s engineering meaning to remain stable while its exposed functions and resident-facing views evolve.
This layered profile architecture is distinct from the SuperChart reconciliation implemented in the reporting period. Its value should be evaluated by whether authority becomes easier to inspect, new integrations preserve existing invariants and downstream consumers remain coherent through change.
