Classify tests and evidence with the safety matrix

Chapter overview

Bottom line: Classify everything first; this chapter performs no tests. You will divide the proposals into four categories: safe, isolated-test, approval-required, and never-automate; if a gate is incomplete, stop on paper.

Purpose

Use a four-category matrix before any action to determine whether the proposal can continue.

Prepare

A blank classification ticket with a placeholder-only text description of the proposal; no test environment is required.

Time

About 20 minutes

System change

No live-environment testing is performed; only test cases are separated offline into evidence and safety categories.

Expected result

Distinguish the four safety classes while keeping every environment-specific result unproven.

Stop conditions

• Connecting to a KNX bus, transmitting telegrams, reading or writing groups, and controlling physical equipment are prohibited.
• Evidence of isolation, written approval, stop conditions, or recovery is incomplete.

Scope and safety boundaries

A classification ticket is not permission to execute. This chapter does not connect, launch, reload, change, or collect live results. When a proposal contains multiple actions, they must be split and the most stringent category among them must be adopted.

• Safe: Offline read-only pinned sources, or stubs that do not access the execution environment at all; may not start daemons, touch endpoints or devices, or send KNX telegrams.
• Isolated test: Evaluate a proposal only when it has clear written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan. Physical bus-isolation testing is limited to separately approved exercises that genuinely require it. For lifecycle-only exercises, all KNX interfaces, USB/device mappings, physical buses, production KNX networks, ETS projects, and physical loads must remain disconnected. If any condition is missing, do not proceed.
• Approval required: Any proposal to review or change the running environment must first have clear written approval, limited maintenance scope and data identification. Even read-only viewing of the live/running environment requires approval and does not automatically make it safe; it cannot transmit KNX telegrams, perform ETS actions, or have physical control.
• Never automate: Guide or automation may not group read, group write, send telegram, execute ETS programming or downloads, connect to KNX interface or bus, collect or publish environment identification data, or physically control under any circumstances; the test bus is no exception. There are no gates to change this classification.

Joining the repository, installing or starting must also have all gates for isolation testing, as well as approved immutable artifact/image digest and source-to-build attestation. Stop if conditions are incomplete; this chapter does not perform these actions.

Core concepts

Evidence also has limits. The document only proves the content of the document; the approval only proves the scope of approval; the isolation plan only proves the preparation conditions. None proves a result for daemon, listener, KNX bus, ETS or Home Assistant integration.

Preparation and prerequisites

First make a completely offline classification ticket. If any field is unknown, write "Unknown and Stop."

• Goals and non-goals: Write in one sentence what you want to answer, and specify which systems you will not touch.
• Atomic actions: Each column can only have one offline reading, live/running environment viewing, change or transfer action; the two types of reading cannot be confused as safe.
• Environment category: Write offline, isolated-test candidate, or running environment; do not enter identifying information.
• Approval evidence: Record the approving role, scope, and validity policy; verbal consent does not count.
• Isolation evidence: Record physical isolation, non-production equipment, and physical loads disconnected from the production environment.
• Stop and recovery: First record trigger conditions, baselines, responsible roles, and escalation methods.
• Evidence limit: What can be said at most after writing is completed, and what must not be said.

Steps

After completing the process, no action will be performed.

1. Write down the smallest question. Remove sentences that preset live-environment outcomes, leaving only questions to review.
2. Break it down into atomic actions. Separate read, view, change, start and send; stop if not clear.
3. Identify never-automate actions first. Group reading and writing, telegram transmission, ETS programming or downloads, and physical control are not allowed. When any of these items appear, they are marked as never to be automated and removed.
4. Classify approval-required actions. All views or changes to the live/running environment are marked as requiring approval; read-only viewing is no exception. Stop without clear written approval, scope or de-identification.
5. Check the isolated-test gate. Verify written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan item by item. For lifecycle-only exercises, record that all KNX interfaces, device mappings, physical buses, production networks, ETS projects, and physical loads remain disconnected. Adding a repository, installing, or starting software also requires approved immutable provenance.
6. Confirm the safe class. Only offline read-only pinned sources, or placeholder work that does not access the execution environment at all and has no side effects, can be marked as safe.
7. Seal classified tickets. Note down the reasons for stopping, the evidence limit and pending items, and mark them as "not yet executed".

Verification and evidence

A valid classification ticket can prevent an unsafe action before execution. It contains no commands, test programs, or execution results.

• Each atomic action has only one four-category label, and in case of conflict, a stricter category is adopted.
• The safe-category items are all offline read-only pinned sources, or placeholder work that does not access the execution environment at all and has no side effects.
• Explicit approval, a non-production environment, administrator presence, limited network exposure, disconnection conditions, stop conditions, and recovery gates are all visible for an isolated-test candidate.
• Approval-requiring categories have clear written approval, limited scope, and de-identification requirements; read-only viewing of live/running environments is also listed in this category.
• Never automate items have been removed and there are no directives or alternative testing methods.
• All environment, bus, ETS and Home Assistant integration results remain unproven.

Next step: Go to Chapter 17, organize the paper management boundaries of backup and restore.

Troubleshooting

• A column acts like two categories at the same time: Break it down into smaller actions and apply the stricter categories first.
• Only verbal consent: Considered not approved and remains stopped.
• Only logical isolation: Does not count as isolation testing; must comply with canonical isolation gate. When only conducting lifecycle drills, all KNX interfaces, device mappings, physical buses, production networks, ETS projects and loads must be disconnected.
• No restoration baseline: Do not enter any change candidates, first complete the plan on paper.
• Add or install missing provenance: Stop, do not add the repository, do not install, do not start.
• Someone wants to change the prohibited action to a manual procedure: Refuse. Changing tools does not change the safety classification.
• Test results begin to appear on classified tickets: Remove results. This chapter only does pre-execution classification.

FAQ