Proposal: Clarifying Device Identity and Safety Semantics in Matter Using Existing Labels

[Jang-woo-AnnaSoft]

Proposal: Clarifying Device Identity and Safety Semantics in Matter Using Existing Labels

1. Context

The Matter ecosystem is evolving beyond simple remote control toward automation and AI-driven execution.

However, current implementations primarily rely on Device Type to interpret device behavior, while existing label fields such as UserLabel and FixedLabel are not utilized for semantic interpretation.

This creates a gap between what a device can do and what it actually represents in the physical world.

---

2. Problem Statement

2.1 Mutable Labels Cannot Be Trusted for Safety

User-editable labels (e.g., UserLabel) are mutable and therefore cannot be used as a reliable source for safety-critical decisions.

2.2 Lack of Semantic Meaning

While Device Type defines capability, it does not convey:

• Intended usage
• Risk level
• Operational context

This limitation becomes critical as systems begin to trigger real-world actions.

2.3 Platform Limitation

Across multiple platforms, device interpretation is effectively limited to:

• Device Type
• UI-only labels (not used for system logic)

As a result, systems cannot distinguish between devices with identical capabilities but vastly different safety implications.

---

3. Proposal

This proposal introduces a structured usage pattern of existing Matter label fields, without requiring any changes to the Matter specification.

---

3.1 Identity: Separation of Display Label and System Identity

We recommend separating user-facing labels from system-level identity.

• UserLabel remains user-editable for display purposes
• A system-readable identifier should be embedded or derived to ensure stable endpoint identification

Recommended Pattern

• Embed identifier within label
• Example: [endpointLabel:<function_id>]
• Or apply a consistent parsing rule for system-level identification

Roles

• Manufacturer: defines the intended function of the endpoint
• System: extracts and maintains identity based on embedded identifier

Platforms are encouraged to adopt a consistent method for extracting system-level identifiers from labels to ensure stable device identity across renaming and UI changes.

---

3.2 Safety Semantics: Manufacturer-Guaranteed Meaning via FixedLabel

We propose using FixedLabel to define non-editable semantic properties provided by the manufacturer.

These properties act as action boundaries for systems.

Example

Device	FixedLabel (Semantic Info)	System Interpretation
Smart Plug	usage:heater, safety:high-risk	Identified as high-risk heating device. Avoid unattended operation
Kitchen Light	room:kitchen, type:ambient	Low-risk lighting. Freely usable in automation
Door Lock	access:security, safety:critical	Requires additional authentication before control
Electric Blanket	category:heating, timer:required	Must enforce automatic shutoff after a defined duration

---

Recommended Tagging Format

To ensure interoperability across platforms, a lightweight key-value tagging format is recommended:

purpose:heating; risk:high; auto-off:300s

This enables consistent parsing and interpretation of semantic properties across ecosystems and prevents fragmentation in label usage.

---

4. Alignment with Matter Specification

Field	UserLabel	FixedLabel
Author	User / Platform	Manufacturer
Mutability	Writable	Read-only
Role (Current)	Display text	Manufacturer metadata
Role (Proposed)	Display + optional identifier carrier	Semantic identity + safety boundary

This proposal does not modify the data structure but redefines how the fields are used.

---

5. Advantages

• No changes to the Matter specification required
• Fully backward compatible with existing devices
• Enables context-aware execution of device actions
• Preserves platform UI flexibility
• Reduces ambiguity in device interpretation across ecosystems
• Reduces reliance on hard-coded device logic
• Provides manufacturer-defined safety boundaries supporting liability and compliance

---

6. Expected Impact

1. Extends Matter from capability-based control to semantic interpretation
2. Reduces the need to introduce new Device Types for semantic differentiation
3. Improves user experience by separating display naming from system identity
4. Enhances safety by preventing context-blind execution
5. Enables more flexible, data-driven decision-making across platforms
6. Enables context-aware decision-making before execution
7. Enables context-aware automation without complex rule definitions

For example, systems can distinguish between low-risk ambient lighting and high-risk heating devices and apply different execution constraints accordingly.

---

7. Conclusion

This proposal introduces a practical and non-intrusive way to enhance Matter devices with semantic identity and safety context, using existing label structures.

It provides a foundation for safer and more context-aware automation without requiring changes to the core specification.

[Jang-woo-AnnaSoft]

I posted a working implementation of this proposal on Hackster.io that may be relevant to this discussion:
→ https://www.hackster.io/Jang-woo/json-based-matter-device-framework-for-llm-agents-esp32-c6-749329

The core issue raised here — that physically different actions are treated as the same "switch" — is exactly what motivated the build. A kitchen light and an electric blanket both appear as On/Off Switch to an LLM agent. The agent infers what they are. That inference is the problem.

The implementation runs on ESP32-C6 within existing Matter infrastructure, without spec changes.

The approach:

• Each action is declared via JSON (9 structured questions covering intent, physical effect, safety boundary, context, and start/stop constraints)
• A firmware runtime reads the JSON and generates a valid Matter endpoint automatically — cluster mapping, commissioning, GPIO conflict protection, state management
• Manufacturer-defined safety information is stored in FixedLabel (0x0040) as read-only boundaries
• User context and intent are declared through UserLabel (0x0041)
• The LLM agent reads both declarations and executes within them — no inference required

This maps directly to what Section 3.2 of this proposal describes.

FixedLabel carries the semantic safety boundary. UserLabel carries the execution context. The separation means the agent doesn't need to guess — it reads what each owner has already declared.

Detailed information regarding the JSON structure and runtime behavior has already been released on GitHub.