Use controlled operations and change records

Chapter overview

Bottom line: You create only an offline change record that lists source review, approval, observation boundary, stop, restore decision and evidence notes in sequence. This log does not provide commands, does not bypass approvals, and does not allow you to operate a running system.

Purpose

Use a six-field offline record to establish a maintenance rhythm that can be stopped, handed over, and cannot bypass approval.

Prepare

A six-field blank change record and pinned source; do not bring in execution environment data.

Time

About 20 minutes

System change

Do not apply settings or start or stop services; only create offline change records and manual gates.

Expected result

Create an offline operating cadence and change-record template that preserves approval, evidence, stop, and restoration responsibilities.

Stop conditions

• Complete isolation, written approval, an immutable artifact/image digest, or source-to-build attestation is missing.
• Group operations, telegram transmission, ETS actions, and physical control are prohibited.

Scope and safety boundaries

Documenting a cadence is not a license to operate. Safe work is limited to offline, read-only pinned sources or placeholder records that never access an execution environment. Read-only access to any live or running environment requires approval and, when approved, must remain within the authorized data categories and scope.

• Safe: Review locked sources, design blank fields, mark evidence levels and responsible roles.
• Isolated test: Alternative projects must first have clear written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan; they are not covered in this chapter.
• Approval required: Viewing or changing the live/running environment falls into this category; read-only approval does not include modification, elevation of privileges, or expansion of data scope.
• Never automate: Do not read or write groups, send a KNX telegram, perform ETS programming or downloads, connect a KNX interface or bus, or control physical equipment. The test bus is no exception.

Joining the repository, installing or starting also requires full isolation gates, written approval, approved immutable artifact/image digest and source-to-build attestation. Stop if any item is missing.

Core concepts

Add-on 0.6.1's managed INI templates, initialization scripts, and service scripts can describe only the source structure, configuration preparation, and daemon calling responsibilities. They are not a deployment record and do not prove the status of the listener, KNX bus, ETS, Home Assistant or hardware.

Preparation and prerequisites

First create six fields, all of which are marked “stopped” by default. Fields that do not have qualifying content may not be filled by maintenance windows, conventions, verbal consent, or administrative authority.

• Source review: Record pinned sources, version boundaries, and the strongest conclusion each source supports.
• Approval: Approved roles, purpose, data categories, expiration policies and controlled record references are recorded, without names or environmental identifiers.
• Observation boundary: Only allowed and disallowed data categories are listed; live read-only still requires additional explicit approval.
• Stop: List stop conditions such as unclear scope, need to change, identification data, or invalid approval.
• Restore decision: Record only the decision-making role, independent approval requirements, stop-and-restore conditions and controlled plan references.
• Evidence notes: Distinguish source facts, approved observations, inferences and unknowns, do not post original content.

Environment or event time, log time, device path, host, endpoint, address, serial number, account number, secret or site name are not allowed. If governance requires a deadline, use reviewed abstract states such as "valid", "pending review", or "expired".

Steps

The six fields must be filled in sequentially offline. If any field is incomplete, stop at that field and return to the responsible role.

1. Complete source review. Document managed templates, initialization responsibilities and daemon calling responsibilities separately; do not treat source content as live-environment settings.
2. Check approval status. Confirm only whether there are controlled records, responsible role, purpose, data category and validity status. If one item is missing, mark it as unapproved and do not create an alternative path.
3. Draw observation boundaries. Use abstract data categories to describe allowable scope and explicit exclusions. If the proposal involves live read-only, it is still marked as approval-required, and this chapter does not provide a read method.
4. Apply the stop rules. Stop if the proposal requires writing or applying settings, starting or stopping services, elevating privileges, connecting systems, contacting hardware, or using ETS. Telegrams, group operations, and physical control are prohibited; record the responsible handoff roles.
5. Document responsibility for restoration decisions. Specify which role will determine whether to restore or not in the independent approval process, and the evidence that must be available before making the decision; do not list candidate actions.
6. Add evidence notes. Each column is marked as source fact, approved observation, inference, or unknown, and the evidence limit and concealment status are written.
7. Second-person review and record closure. A second person confirms the six-field sequence, verifies that approval was not bypassed, and checks for identifying data or operational content. The reviewer then marks the record "complete," "stopped because evidence is missing," or "referred for a separate decision."

Verification and evidence

Qualifying results are traceable to a six-field offline record. It proves only that document fields and manual gates have been reviewed, not that maintenance, changes, or restores have been completed in any environment.

• Source reviews only cite the pinned version and state that no inferences about deployment results can be made.
• The approval field contains purpose, data category, role, valid status, and controlled references; there are no verbal shortcuts.
• The observation boundary clearly indicates that live read-only is still approval-required.
• The stop field covers changes, privileges, connections, hardware, ETS, telegram, group and physical control requirements that are not allowed to be implemented.
• In the restoration field, only independent decision-making responsibilities and prerequisites are recorded, without execution instructions.
• Evidence notes separate source facts, approved observations, inferences, and unknowns.
• The record contains no commands, identifying information, ambient times, or any description of field successes.

Next step: Go to Chapter 22, put the same set of stop, handover and evidence boundaries into the offline incident runbook.

Troubleshooting

• Approval only says "routine maintenance": The purpose and data scope are incomplete and remain suspended.
• Some people say that read-only does not require approval: Refuse. Read-only viewing for live/running environments is still approval-required.
• The source is different from the live-environment statement: Only version or evidence gaps are recorded, and the system is not modified to achieve consistency.
• The maintenance window has begun: A time window does not authorize an operation; work must remain stopped while any field is incomplete.
• The restore decision-maker and executor are the same: Independent approval, stopping conditions and responsibility boundaries must still be left in separate columns and cannot be omitted.
• Someone asked for a quick command: Refuse. There are no operational commands or authorized detours for this chapter.
• Unsafe evidence summary: The original content will not be published, only "subject to controlled review" and the responsible role will be recorded.

FAQ