The Matter SDK implements an in-progress Matter specification that may be in flux. Our stable checked-in XML data models (located in data_model/) represent a specific released baseline (e.g., 1.6).
When Pull Requests develop features for “next” or implement corrections for specification typos, they can cause Python Interaction Data Model (IDM) tests to fail against the stable baseline XMLs.
To bridge this gap without making unauthorized manual edits to the machine-generated XML files, the SDK provides a declarative Data Model Errata Engine.
The adaptations live in a single top-level overlay file: data_model/errata_future.yaml.
The YAML format requires an explicit revision compatibility guard and matches target objects by exact name.
# Authoritative Errata to bridge baseline XMLs with Matter 'next' PR development. # Guard to guarantee this overlay is only applied to compatible baseline revisions. compatible_specification_revisions: - 1.6 AmbientContextSensing: # Auto-matched Cluster Name (Mandates sanitized PascalCase) SimultaneousDetectionLimit: # Auto-matched Attribute or Command Name read_access: RV # Mapped to AccessControlEntryPrivilegeEnum.kView write_access: none # Redefine or clear access
During test execution, the Python testing harness (basic_composition.py) inspects the target device's SpecificationVersion attribute (from the BasicInformation cluster on endpoint 0) to determine which baseline XML data model directory (e.g., 1.6) to load.
By default, low-level specification parsing (spec_parsing.py) applies no errata, ensuring pure, strict certification validation. When executing Interaction Data Model (IDM) tests or in-progress PR validation suites, the harness explicitly enables errata loading (via the --enable-spec-errata-ci-only-disallowed-for-certification CLI flag or spec_errata_path configuration).
Right after assembling base and derived clusters, the parser invokes apply_errata (from matter.testing.data_model_errata). This verifies that the active specification revision matches the YAML's compatibility list, resolves element names via sanitized AST maps (_sanitize_name() matches keys to lowercase structures, ensuring spaces and punctuation like On/Off map to clean CamelCase) while actively rejecting raw XML names with spaces or slashes, and applies the specified overrides in memory.
read_access, write_access (Supports standard access privilege codes: RV, RO, RM, RA, none, or view, operate, manage, administer).invoke_access / privilege (Supports standard access privilege codes: RV, RO, RM, RA, none, or view, operate, manage, administer).If your development requires overriding XML elements or fields not currently handled by the engine (such as attribute conformance or event privileges), follow these steps to extend the engine core:
src/python_testing/matter_testing_infrastructure/matter/testing/data_model_errata.py._apply_attribute_errata or _apply_command_errata).if 'conformance' in overrides:).target_attribute.conformance = ...).events or structs), insert an additional lookup branch in _apply_element_errata (e.g., resolving against a sanitized event map).target_cluster.events and apply the intended alterations.test_data_model_errata.py verifying your new override key functions correctly and reports invalid inputs.data_model/errata_future.yaml.