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
- Extends Matter from capability-based control to semantic interpretation
- Reduces the need to introduce new Device Types for semantic differentiation
- Improves user experience by separating display naming from system identity
- Enhances safety by preventing context-blind execution
- Enables more flexible, data-driven decision-making across platforms
- Enables context-aware decision-making before execution
- 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.
