[Proposal] A Paradigm Shift in Matter IoT Development

[Jang-woo]

A Paradigm Shift in Matter IoT Development

From Selecting a Device Type to Defining an Action

A Proposed Shift in Design Thinking for Developers

1. The Structural Problems with Matter Development Today

Problem 0. The Entry Barrier: Matter Development Is Hard

Before writing a single line of actual behavior code, implementing a Matter device from scratch requires clearing a long series of hurdles.

ESP-IDF setup  →  Matter SDK build  →  Manual cluster mapping  →  Commissioning logic

NVS storage structure  →  GPIO conflict management  →  State management  →  … then, finally, behavior

Even when starting from a reference firmware, any deviation quickly requires digging into the SDK internals. Infrastructure code overwhelms actual behavior code.

Problem 1. The Core Issue: Actions Have No Names

The typical Matter/IoT development workflow looks like this:

• Pick the closest match from the platform-defined Device Type list
• Combine the features available within the clusters and attributes that Type supports
• Fit the hardware (GPIO pins, sensors) into the Type's structure
• Copy an existing example or reference firmware and modify it

This is not designing behavior. It is fitting hardware into a pre-existing template.

When a new behavior is needed, developers pick the closest existing Type and force-fit it. If the platform does not define it, you cannot build it.

Additional Problems in the Age of AI

Problem 2 — AI Does Not Know What a Device Actually Does → It Guesses

Without named Actions, AI has no way to know a device's intent. It reads the Device Type and cluster structure and infers meaning. This is not understanding — it is guessing.

In practice, diverse behaviors get reduced to simple on/off control patterns — not because they are the same, but because the system has no better way to describe them. A heater, a fan, and an electric blanket can all be controlled identically, not because they are equivalent, but because there is no structural way to express what they actually mean.

In the current Matter implementation, UserLabel (0x0041) is a user-editable display label. It is not used as a trusted system-level identifier. There is no official way to communicate to the system what an endpoint actually does.

Problem 3 — Actions Have No Safety Boundaries → AI Issues Commands Without Knowing the Limits

Constraints like maximum run time, risk level, and auto-shutoff conditions are hardcoded inside the firmware. They cannot be read from the outside.

AI issues commands without knowing what is allowed. It controls a kitchen light and an electric blanket in the same way. Safety conditions are guessed, not known.

2. The Proposal: Define the Action First

Instead of starting by selecting a Device Type, consider a structure where you think through everything about a single Action from the very beginning.

2-1. Nine Questions to Define an Action

① What is the intended action?

② What physical effect occurs?

③ What boundaries must never be crossed?  ← newly added question

④ In what context is this Action valid?

⑤ What event triggers the action?

⑥ What is the goal value?

⑦ What is the maximum execution time?

⑧ What conflicts must be checked before starting?

⑨ What protection conditions apply before stopping?

Once you can answer these questions, the Action has a name. A collection of named Actions becomes a device.

Devices that do not belong to any existing Device Type become possible.

Where conventional development starts with "Which Type should I pick and fit this into?", this approach starts with "What is this Action?"

2-2. Simplifying the Execution Model

To keep the execution model simple and explicit, every Action maps to one of two fundamental units.

Button  (immediate execution)	Switch  (state maintained)
Instantaneous pulse action e.g. doorbell, notification, one-shot trigger	Persistent state maintained e.g. light ON/OFF, keeping a heater running

These two are the starting point. Additional clusters can be added as needed for more precise control.

This has a practical benefit as well: since all behaviors map to a simple ON/OFF model, only the OnOff cluster is needed on the Matter side as a baseline. This can significantly reduce certification costs and time, while preserving flexibility at the action level.

3. Implementation Within the Existing Matter Structure

Without any spec changes, reinterpreting existing Matter cluster structures is sufficient to address both AI-era problems.

3-1. Solving Problem 2 — The endpointLabel Pattern (UserLabel 0x0041)

The name of an Action needs to be communicated in a form the system can trust. UserLabel is user-editable, making it unsuitable as a system-level identifier.

Proposal: Introduce a pattern (endpointLabel) that embeds a manufacturer-defined identifier within the label field.

// UserLabel (0x0041) usage pattern

"UserLabel": "endpointLabel:keep-warm|display:Keep Warm"

// AI and automation systems can directly read the endpoint identity

// via the endpointLabel key -- no inference required

// -> No spec change needed; works within existing structure

This pattern has been proposed to the Matter SDK repository (issue #71521). It works within the existing structure without any spec changes.

3-2. Solving Problem 3 — Reinterpreting Fixed Label (0x0040)

The Fixed Label cluster (0x0040) is manufacturer-defined and read-only. Until now, it has only been used for physical orientation labels and UI labels.

By storing an Action's safety boundaries declaratively in this cluster, the device itself can announce its own limits to the outside world.

// Fixed Label (0x0040) -- declaring safety boundaries

"FixedLabel": [

    { "label": "purpose", "value": "heating" },

    { "label": "risk",    "value": "high" },

    { "label": "auto-off","value": "300s" }

]

// Safety conditions hardcoded inside firmware -> unreadable from outside

// Conditions declared in Fixed Label -> AI, automation systems, other devices

//                                       can read them directly, without inference

Key point: Rather than safety conditions being hidden inside firmware,

the action itself declares its own limits.

Both of these work within the existing Matter structure, with no spec changes required.

4. Current Approach vs. Proposed Approach

Current Approach	Proposed Approach
Starting point: Select a Device Type Design direction: Hardware → fit into template New behavior: Force-fit closest Type AI recognition: Infers from cluster structure Safety boundaries: Hardcoded in firmware Behavior change: Rewrite firmware + reflash Undefined device: Cannot be implemented	Starting point: Define an Action Design direction: Intent → map to hardware New behavior: Add an Action directly AI recognition: Reads endpointLabel directly Safety boundaries: Declared in Fixed Label (read-only) Behavior change: Update via configuration Undefined device: Can be implemented

5. Why This Matters

The key outcomes of this proposal:

• Behavior is defined in units of Actions, not Device Types
• Safety boundaries stored declaratively via Fixed Label (0x0040) — readable by AI and automation systems without inference
• Stable endpoint identification via the endpointLabel pattern in UserLabel (0x0041)
• Action definitions are machine-readable — enabling AI/automation integration without hardcoding

This approach requires no Matter spec changes. Reinterpreting existing structures is sufficient.

Behavior is no longer code.

It becomes data that can be inspected and validated.

A Note on Execution

This is not about giving AI more control. AI does not decide actions. It validates predefined meaning and boundaries before execution.

Responsibility Model

To make this work in the physical world, responsibility must be clearly separated:

• Manufacturers define the meaning of actions and safety boundaries
• AI validates those definitions before execution
• Users decide what is allowed based on those rules

Every device built so far was designed to be operated by humans.

Devices built from now on should be designed to be understood by AI.

A device is not a type.

A device is a composition of actions.

It starts with giving Actions a name.

[Jang-woo]

While reviewing the discussion, I realized that one of the examples in the original document used an incorrect representation:

"UserLabel": "endpointLabel:keep-warm|display:Keep Warm"

This was a mistake during the drafting/editing process, and it also violates the Matter Value length constraint.

The intended structure is:

"UserLabel": {
"LabelList": [
{ "Label": "endpointLabel", "Value": "Keep Warm" }
]
},

"FixedLabel": {
"LabelList": [
{ "Label": "purpose", "Value": "heating" },
{ "Label": "risk", "Value": "high" },
{ "Label": "auto-off", "Value": "300s" }
]
}

The core idea of the document can be summarized very simply:

1. If platforms define common identifiers for UserLabel usage, development of simple Matter devices becomes much easier, allowing many more products to be created without introducing new Device Types.

2. If platforms encourage structured FixedLabel usage like the example above, it could contribute to safer AI-assisted control by exposing semantic intent and operational boundaries in a machine-readable form.

[Jang-woo]

This proposal does not require any changes to the Matter specification.

Matter already defines User Label and Fixed Label structures. Today, these fields are often treated only as optional metadata or UI hints, but they may also provide a lightweight semantic layer for platforms and controllers.

For example:

* UserLabel can expose user-facing action names
* FixedLabel can expose manufacturer-defined semantic information such as purpose, risk level, or operational boundaries

This approach does not modify device capabilities, interoperability, certification behavior, or existing Device Types. It is simply an interpretation layer built on top of structures that already exist in Matter.

Most importantly, this can already be explored entirely at the platform level without requiring CSA specification changes. Home Assistant already experimented with exposing UserLabel through the UI last year, showing that interpretation of these fields is ultimately a platform decision.

As AI systems begin interacting more directly with physical devices, semantic interpretation becomes increasingly important. Matter may be one of the few ecosystems where this can be explored realistically today because it already provides:

* standardized device capabilities
* interoperable controller structures
* endpoint-level metadata
* existing label mechanisms

The goal is not to redesign Matter, but to explore whether these existing structures can support a lightweight semantic validation layer for AI-assisted physical control.