37  Matter Interaction Model

Keywords

Matter interaction model evidence, Matter Read Write Subscribe Invoke, Matter commissioning review, Matter Timed Request review, Matter subscription evidence

Matter interactions are the evidence trail between a controller’s intent and a device’s accepted state change. A review should not only name Read, Write, Subscribe, Invoke, or Timed Request. It should prove the path, privilege, session, data-model target, report behavior, and failure handling that made the interaction safe for the scenario.

This chapter reviews Matter interaction evidence for advanced learners. It focuses on the interaction model, endpoint-cluster paths, subscription records, timed operations, commissioning handoffs, ACL boundaries, failure signatures, and bounded approval decisions.

37.1 Start With the Device Experience

Start with a user expecting a Matter device to join, advertise, and respond through a controller without caring which vendor built each piece. Matter Interaction Model is the evidence route for deciding whether that expectation is realistic.

Keep one device story in view: commissioning, fabric membership, interaction model, transport, and certification all have to line up. The advanced details are useful when they explain where that story can break.

37.2 In 60 Seconds

• Matter controllers use Read, Write, Subscribe, and Invoke operations against paths in the data model.
• Timed Request is a protective interaction pattern used when a following Write or Invoke must arrive within a short accepted window.
• Every accepted interaction should be tied to an endpoint, cluster, attribute, command, or event path, not only to a device name.
• Subscribe is not just “push updates.” It needs min/max interval evidence, report source, lifecycle state, and cancellation behavior.
• Commissioning moves a device from discovery and PASE into operational credentials, CASE sessions, ACLs, and first verified interactions.
• A clean review separates transport reachability from Matter authorization. A reachable device can still reject an operation correctly.
• Approval should state which interaction type, fabric, controller subject, target path, privilege, and evidence window were checked.

37.3 Learning Objectives

By the end of this chapter, you will be able to:

• Review Matter interaction evidence using data-model paths, session state, ACL privilege, and response status.
• Distinguish Read, Write, Subscribe, Invoke, and Timed Request evidence without collapsing them into generic message exchange.
• Evaluate subscription choices for constrained and mains-powered devices without relying on brittle traffic arithmetic.
• Trace commissioning from discovery through operational interaction approval.
• Diagnose common interaction failures such as wrong path, wrong privilege, stale subscription, timed-window mismatch, and commissioning handoff confusion.

37.4 Quick Check: Matter Interaction

37.5 Prerequisites

This chapter assumes you have reviewed:

• Matter Protocol Stack and Data Model, for endpoints, clusters, attributes, commands, and events.
• Matter Architecture, for nodes, fabrics, controllers, bridges, and administrative boundaries.
• Matter Fabric Security Evidence, for PASE, CASE, operational certificates, and ACL records.
• Thread Security and Matter, for the network layer beneath Matter over Thread.
• 6LoWPAN RPL Routing Evidence, for constrained IPv6 path evidence below application interactions.

37.6 Interaction Review Claim

Use a claim that can be checked against records:

Matter interaction review claim: A Matter interaction is ready for the reviewed scenario only when the controller subject, fabric, CASE or commissioning session, target path, required privilege, interaction type, response status, subscription or timed-window behavior, and retest trigger all support the same bounded decision.

The claim is intentionally narrow. Evidence that a phone can turn on one light does not prove a management write, a door-lock command, a second fabric, a sleepy sensor subscription, or a group command path.

37.7 Interaction Evidence Map

The first figure shows how an interaction record should connect intent to an approval decision.

Figure 37.1: Matter interaction evidence map.

This map prevents a common review mistake: treating a successful app screen as proof that Matter behavior is correct. The approval needs the device path, privilege, protocol state, and outcome record that explain why the interaction succeeded or failed.

37.8 Evidence Families

Matter interaction review uses several evidence families. Missing evidence usually means the decision should stay open.

Controller subject Record the fabric, controller node identity, and whether the subject is expected to perform the reviewed operation.

Session state Separate commissioning sessions from operational CASE sessions. Record whether the interaction occurred before, during, or after commissioning.

Target path Record the endpoint, cluster, attribute, command, or event target. Avoid approvals that only name the product or room.

Privilege fit Map the requested operation to the required ACL privilege. A connected controller is not automatically allowed to write or invoke.

Outcome record Preserve accepted values, rejected status, subscription reports, event records, retry behavior, or timed-window failure evidence.

Retest trigger Record what would require another review: ACL change, fabric removal, firmware update, cluster revision, transport migration, or controller replacement.

37.9 Interaction Types as Review Objects

Matter interaction types are not interchangeable. Each one asks a different evidence question.

Read Proves that a controller can retrieve current attribute or event data from the target path. Review the path, data freshness, fabric filtering, and whether the read was authorized.

Write Proves that a controller can set a writable attribute within the target’s constraints. Review value range, access privilege, accepted status, and resulting report.

Subscribe Proves that the controller can receive initial reports, change reports, and heartbeat reports for selected paths. Review min/max intervals, lifecycle, and cancellation.

Invoke Proves that a controller can execute a command exposed by a cluster. Review command target, arguments, privilege, response status, and resulting state evidence.

Timed Request Proves that a security-sensitive Write or Invoke is accepted only inside an agreed time window. Review the timed request, deadline, following operation, and rejection behavior after expiry.

Report Data Proves what a device returned or emitted. Treat reports as first-class evidence for reads, subscriptions, events, and post-command state confirmation.

37.10 Interaction Verb Ledger

The core Matter verbs map cleanly onto the data model. Reads and Writes target attributes, Invokes target commands, and Subscriptions target attributes or events that should report over time.

Interaction	Acts on	Example evidence
Read	An attribute or event path	CurrentLevel returned from endpoint 1 / Level Control with response status and capture time
Write	A writable attribute	Target temperature accepted within constraints, followed by a confirming read or report
Invoke	A command on a cluster	Toggle invoked on an On/Off endpoint with command response and resulting state evidence
Subscribe	Attributes or events with report-on-change behavior	Initial report, change report, heartbeat report, and cancellation or loss handling
Timed Request	A following sensitive Write or Invoke	Timed window accepted, command sent inside the window, and late replay rejected

This ledger keeps the review anchored to protocol behavior rather than UI wording. For example, “turn on the light” should resolve to a concrete Invoke command path, while “show me whether the light is on” should resolve to Read or Subscribe evidence for the relevant attribute.

37.11 Data-Model Path Discipline

Every interaction should be anchored to a path. The reviewer should be able to answer:

• Which endpoint was targeted?
• Which cluster owns the attribute, command, or event?
• Is the target an attribute to read or write, a command to invoke, or an event/report source?
• Does the device type require that cluster and target, or is it optional behavior?
• Was the response from the expected endpoint and fabric-filtered view?

Path discipline catches mistakes that product demos often hide. A bridge may expose many endpoints. A dimmable light may support On/Off and Level Control. A lock may expose state attributes and security-sensitive commands. Treating those as one generic “device command” loses the evidence that matters.

37.12 Read Evidence

A Read review should prove more than “the value appeared in the app.”

Accepted evidence The controller subject, target path, response status, value, timestamp or capture window, and expected fabric-filtered view are recorded.

Open gap The page only shows a dashboard value, with no path, no freshness boundary, no fabric context, and no indication whether the value was cached.

Retest trigger Retest after cluster revision changes, bridge endpoint changes, controller cache changes, fabric removal, or firmware updates that alter report behavior.

37.13 Write Evidence

A Write review should prove that a writable attribute was changed inside its allowed boundary.

Accepted evidence The write target, proposed value, value constraint, required privilege, response status, and subsequent read or report confirm the intended state.

Correct rejection A rejection can be the right outcome if the controller lacks privilege, the attribute is not writable, the value is outside constraints, or the target path is unsupported.

Review warning Do not approve a write based only on a UI slider moving. The device must confirm the accepted value or return an explainable status.

37.14 Subscribe Evidence

Subscribe is often the best interaction for current-state visibility, but only when the subscription record is bounded.

Initial report The subscription should produce an initial report or equivalent evidence so the controller begins from a known state.

Change reports The review should show that relevant attribute or event changes produce reports without uncontrolled flooding.

Heartbeat behavior The max interval should support liveness without forcing a sleepy or battery device to wake more often than the scenario requires.

Lifecycle The record should show when the subscription was created, refreshed, dropped, or canceled, and how the controller handled loss.

37.15 Subscription Report Lifecycle

Subscribe is the interaction that makes Matter efficient at scale. If a controller kept fifty devices current by polling, it would repeatedly read values whether or not anything changed. That wastes bandwidth, wakes sleepy devices, and can flood a low-power mesh with repeated reads that mostly return the same value.

A subscription inverts that pattern. The device sends an initial report, then reports selected attribute or event changes. The minimum reporting interval rate-limits rapidly changing values, while the maximum reporting interval forces a periodic report even when nothing changed. That maximum report acts as a liveness heartbeat: if the controller does not hear from the device before the maximum interval expires, it can distinguish “unreachable” from “quiet.”

Figure 37.2: Matter subscribe interaction lifecycle with controller subscription, initial report, change updates, and periodic heartbeats.

37.16 Invoke Evidence

Invoke is the command path. It should be reviewed as an action, not as an attribute write.

Command identity Record the cluster command and endpoint. “Turn on the light” should map to a concrete command path, not only a voice phrase.

Arguments Record command fields that change behavior, such as target level, transition, mode, or optional credential material.

Status and state Record the command response plus follow-up state evidence. A success status without expected state evidence may still need review.

37.17 Timed Request Evidence

Timed Request is used when the device requires a following operation to arrive inside an accepted window. Review it as a security boundary.

Window accepted The device acknowledged the timed request and expected the next operation within the active window.

Operation bound The following Write or Invoke is the security-sensitive operation under review, not a different command on a different path.

Expiry behavior The review should know what happens when the operation is late, repeated, or replayed outside the accepted window.

37.18 Quick Interaction Check

37.19 Commissioning Review Path

Commissioning prepares the device for operational interactions. The second figure keeps commissioning evidence connected to the first approved Matter operation.

Figure 37.3: Matter commissioning review path.

Commissioning should not be approved only because a QR code was scanned. The evidence should show how the device was found, how setup information established the commissioning session, how operational credentials were installed, which ACL entry was created, and which first interaction proves the intended operational state.

37.20 Commissioning Evidence Checkpoints

Use checkpoints that match the flow:

Discovery Record the discovery path used for the device state: BLE, soft access point, DNS service discovery, or already-operational discovery. Do not mix first-use discovery with post-commissioning discovery.

PASE setup Record that setup information established the commissioning session before operational credentials existed. This is bootstrap evidence, not ongoing fabric proof.

Network handoff Record Thread or Wi-Fi credential delivery and the point where the device becomes reachable on the intended IP network.

Operational identity Record fabric membership, operational certificate installation, and whether the device identity belongs to the intended administrative domain.

CASE operation Record the first operational secure session after commissioning. CASE evidence is separate from the earlier PASE session.

ACL and first action Record the subject, privilege, target, and first accepted Read, Subscribe, Invoke, Write, or Timed operation.

37.21 Multi-Admin Interaction Boundaries

Multi-admin Matter deployments add interaction review work. A second ecosystem does not inherit the first fabric’s approvals.

For each fabric, record:

• Which administrator or commissioner created the fabric membership.
• Which controller subject performed the interaction.
• Which ACL entry authorized the subject and target.
• Whether the interaction used the correct fabric-filtered view.
• Whether the device accepted, rejected, or reported differently across fabrics.
• Which fabric change would require retesting the reviewed interaction.

This avoids false approval such as “the device works with one app, so it works with all ecosystems.” It may work with both, but that claim needs separate fabric and interaction evidence.

37.22 Failure Signatures

Matter failures are easier to debug when the reviewer classifies the failure by evidence family.

Wrong path The endpoint, cluster, attribute, command, or event target does not exist on the device, or the bridge endpoint changed after a firmware update.

Wrong privilege The subject can connect but does not have the required ACL privilege for write, invoke, management, or administration.

Wrong session The record confuses PASE commissioning with CASE operation, or uses commissioning evidence to approve an operational command.

Subscription stale The controller shows old state after the subscription was dropped, not refreshed, or never received a valid change report.

Timed mismatch The protected operation is not sent inside the accepted timed window, or a replay/retry is accepted when it should not be.

Fabric confusion The test uses evidence from one fabric to approve another fabric with different subjects, certificates, or ACL entries.

37.23 Worked Review Records

37.23.1 Record 1: Light State Looks Correct but Is Stale

Scenario: A mobile app shows a light as on after a group scene changed the room, but the device was later toggled from another controller.

Evidence found: The app had an old read value. There was no active subscription record for the On/Off path and no change report after the second controller acted.

Decision: Do not approve real-time state visibility. Require a bounded subscription record with initial report, change report, heartbeat behavior, and stale-state handling.

37.23.2 Record 2: Lock Command Rejected After Successful Read

Scenario: A controller reads a lock state but cannot invoke the unlock command.

Evidence found: The read path succeeded under a limited privilege, but the unlock command required stronger privilege and timed-operation evidence.

Decision: Treat rejection as expected until ACL and Timed Request evidence support the command. Do not classify the network path as failed.

37.23.3 Record 3: Second Ecosystem Commissioning Fails

Scenario: A device already works in one fabric, but a second ecosystem cannot add it.

Evidence found: Operational interactions in the first fabric were healthy, but the commissioning window for the second fabric was not active and no new PASE session completed.

Decision: Keep first-fabric operation approved, but keep second-fabric onboarding open. Reopen commissioning and capture discovery, PASE, operational credential, ACL, and first interaction evidence for the second fabric.

37.24 Common Mistakes

• Approving an interaction because the device is reachable over IP, without checking Matter authorization.
• Treating Read, Write, Subscribe, Invoke, and Timed Request as generic request/response traffic.
• Using one successful fabric as proof of another fabric.
• Replacing subscription evidence with polling screenshots that do not prove report lifecycle behavior.
• Ignoring rejected statuses even when the rejection is the security behavior the device should enforce.
• Approving a timed operation without checking what happens after the accepted window expires.
• Keeping tool commands in learner-facing content instead of reviewing the evidence those commands should produce.

37.25 Match the Evidence to the Interaction

37.26 Order the Commissioning Evidence

37.27 Commissioning Decision Check

37.28 Review Checklist

Use this checklist before accepting an interaction claim:

Scope The decision names the specific fabric, controller subject, device, endpoint, cluster, and interaction type.

Authorization The required privilege is identified and matched to the ACL record for the subject and target.

Outcome The record includes response status, returned value, report data, resulting state, or expected rejection.

Lifecycle Subscriptions, timed windows, commissioning windows, session renewal, and controller replacement have clear boundaries.

Failure handling Rejected, stale, timed-out, unsupported, and wrong-fabric cases are classified rather than hidden.

Retest The decision states what change invalidates the evidence and requires a new review.

37.29 Summary

Matter interaction review is strongest when it keeps operation type, path, privilege, session, and outcome tied together. Read proves data retrieval. Write proves constrained attribute change. Subscribe proves report lifecycle. Invoke proves command execution. Timed Request proves a protected window for sensitive operations. Commissioning evidence prepares the device for operation, but it does not replace current operational interaction evidence.

37.30 Key Takeaway

Matter Interaction Evidence should map device types, clusters, attributes, commands, events, subscriptions, user behavior, and deployment evidence.

37.31 Concept Relationships

• Read and Subscribe: Read gives a point-in-time value; Subscribe maintains a report relationship with lifecycle evidence.
• Write and Invoke: Write changes writable attributes; Invoke executes commands exposed by clusters.
• Timed Request and Security-Sensitive Commands: Timed Request adds a temporal boundary to protected writes or invokes.
• PASE and CASE: PASE bootstraps commissioning before operational credentials exist; CASE protects operational interactions after commissioning.
• ACL and Interaction Outcome: ACL privilege explains why an operation is accepted or rejected.
• Fabric and Multi-Admin: Each fabric needs separate interaction evidence even when the physical device is the same.

37.32 What’s Next

• Matter Fabric Security Evidence deepens the certificate, PASE, CASE, ACL, and multi-admin trust review behind these interactions.
• Matter Device Types and Clusters maps interaction evidence to conformance expectations for device types and clusters.
• Matter Implementation connects review records to implementation workflows.
• Matter Device Implementation and Commissioning focuses on production commissioning behavior and recovery evidence.
• Matter Testing and Certification explains how formal test evidence supports interoperability approval.