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

Jang-woo — Mon, 13 Apr 2026 03:34:23 GMT

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.

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

JethroEliLapp — Wed, 15 Apr 2026 08:11:58 GMT

It sounds like a wonderful start

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

Jang-woo — Tue, 12 May 2026 07:57:10 GMT

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.

topic Proposal: Clarifying Device Identity and Safety Semantics in Matter Using Existing Labels in Smart Home Developer Forum

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

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

1. Context

2. Problem Statement

2.1 Mutable Labels Cannot Be Trusted for Safety

2.2 Lack of Semantic Meaning

2.3 Platform Limitation

3. Proposal

3.1 Identity: Separation of Display Label and System Identity

Recommended Pattern

Roles

3.2 Safety Semantics: Manufacturer-Guaranteed Meaning via FixedLabel

Example

Recommended Tagging Format

4. Alignment with Matter Specification

5. Advantages

6. Expected Impact

7. Conclusion

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

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