Coordination relationships must be inspectable, not implicit backstage

What it is

The relationships between devices — what triggers what, what depends on what, who feeds data to whom — usually live only in backend configuration and cloud records, while the user interface shows an isolated device list. There is no viewable expression of "how my devices relate"; relationships surface only twice, indirectly: at creation (a flash in the pairing flow) and at failure (in the form of a fault).

"Inspectable" is a modest bar, but a concrete one: not a permanent display, but a relationship view producible on demand — which device connects to which, through what rule, each in what state. When coordination is invisible, the user effectively has no object to point at when talking about their own home automation.

Why it happens

Why does making relationships explicit deserve its own design slot? Because the cognitive load structure of relationships differs completely from that of devices:

• Devices have physical bodies propping up memory — visible, tangible, and re-scannable by glancing around the room; relationships are pure abstraction with no physical anchor, and their only memory source is the single act of configuration.
• Relationships are actively thought about only at configuration time, with zero reinforcement afterwards. Memory that doesn't decay from disuse doesn't exist — six months on, users' recall of the scenes they built approaches chance.
• Attribution at failure needs the graph. The symptom (light didn't come on) always appears on a device, while the cause lives in a relationship (the trigger went offline) — without a relationship view, attribution points naturally at the wrong layer (inspecting the bulb instead of the sensor).

The backend holds the complete relationship set, but storing is not reading: relationships buried under menus and per-item taps are, for the user's cognition, as good as absent — the difference only shows when the vendor's support team debugs.

Where it stops holding

• The need for inspectability rises with scale. A handful of scenes survives on memory; past ten devices, memory fails outright and the relationship view graduates from nice-to-have to the only entrance. Overbuilding it for small systems costs needless interface noise.
• A relationship graph is not an automation panel. The per-rule list (the common automation panel) is the rule view; diagnosis needs the device view — what triggers this device, what consumes it. Both are required; with only the former, users still reverse-engineer by hand.
• The view's freshness decides its usability. A graph that lags configuration changes is worse than none — a user troubleshooting from a stale map doubles down in the wrong direction.

Applying it

• Provide a device-centred relationship view: tap any device and see directly "which scenes it triggers, which scenes consume it, which sources it depends on" — the reverse chain attribution needs, in one click.
• Mark relationship changes (created, deleted, scenes affected by an outage) prominently on next view, instead of dissolving uniformly into history.
• Put the relationship view on the same screen as live state: topology alone doesn't say which segment is alive; topology plus real-time state (online / unreachable / last fired) is the graph diagnosis can use.
• How to check: give users an anomaly scenario ("the entry light doesn't respond") and watch the first move — tap the bulb, or tap the sensor that triggers it. After the view ships, the share of first moves pointing at the trigger source is the direct measure of it working.

Related

• Same group: Z1.06.1 Device coordination requires mutually readable state · Z1.06.2 Mixed-brand ecosystems: protocol differences block coordination · Z1.06.3 One device leaving the ecosystem degrades whole scenes
• Nearby: Z1.05.3 Invisibility erodes users' sense of the system boundary · Z5.03 Tracing causes
• Search terms: smart home automation visibility · device dependency graph · rule inspection