Documenting a cadence is not a license to operate

You have spent eight parts on the same side of a boundary. Part 9 does not cross it either, and it is worth saying why an operations chapter of all things still contains no commands.

The whole series is bounded by pinned sources: the KNXD Add-on 0.6.1 managed INI template and its init and service scripts, and the KNXD 0.14.72 upstream documentation. Those sources support statements about what a file is responsible for. They support nothing about what is running, what is reachable, or what happened on a bus. A chapter that told you to restart a service would be making a claim its sources cannot carry — and this is equipment that moves lights, blinds and HVAC in an occupied building, so a claim that cannot be carried is not a small thing.

So the two chapters behind this part produce documents instead. Chapter 21 states its own bottom line without hedging: you create only an offline change record that lists source review, approval, observation boundary, stop, restoration decision and evidence notes in sequence. That log does not provide commands, does not bypass approvals, and does not allow you to operate a running system. Chapter 22 is blunter still: when an incident occurs, first stop unauthorized activity and contact the responsible person.

Both chapters carry the same four-way classification of work, and it decides what you may do before it decides how. Work through it for any task somebody brings you during this part.

flowchart TD
  A["A task somebody wants done"] --> N{"A group read or write, a telegram,
ETS programming or download, connecting
an interface or bus, or moving equipment?"}
  N -->|"yes"| NA["Never automate.
The test bus is no exception"]
  N -->|"no"| L{"Does it touch a live or running
environment at all, viewing included?"}
  L -->|"yes"| AP["Approval required. Read-only approval
does not include change, privilege
or a wider data scope"]
  L -->|"no"| O{"An alternative project on a
non-production test environment?"}
  O -->|"yes"| IT["Isolated test. Written approval, admin present,
limited network exposure, proven stop and recovery.
Not covered by these two chapters"]
  O -->|"no"| SF["Safe. Offline pinned sources,
blank fields, abstract categories"]

The Approval required class deserves its own sentence, because it is the one people argue about. Viewing or changing a live or running environment falls into it. Read-only viewing is not a safe activity that slipped into the wrong column; it is approval-required, and read-only approval does not include modification, elevation of privileges, or expansion of data scope. Chapter 22 adds the version of that rule you will actually be tested on: the urgency of an event does not automatically cancel approval.

Six fields, and every one of them starts stopped

The purpose of Chapter 21 is a maintenance rhythm that can be stopped, can be handed over, and cannot bypass approval. What you prepare is small: a six-field blank change record and the pinned source. What you must not bring in is execution environment data. Budget about 20 minutes.

The rule that makes the form work sits above all six fields. Complete each field before considering the next one, and a blank field does not imply consent. All six are marked stopped by default. A field that has no qualifying content may not be filled in by a maintenance window, by convention, by verbal consent, or by administrative authority.

Those six doors have formal names, and this is what goes behind each one.

Filled in that order, with a stop available at every door, the record looks like this.

flowchart TD
  S["A blank record.
All six fields start marked stopped"] --> F1["1 Source review"]
  F1 --> F2["2 Approval"]
  F2 --> F3["3 Observation boundary"]
  F3 --> F4["4 Stop rules"]
  F4 --> F5["5 Restoration decision"]
  F5 --> F6["6 Evidence notes"]
  F6 --> R{"Second person: sequence kept,
approval not bypassed,
no identifying data?"}
  R -->|"yes"| C["Marked complete"]
  R -->|"no"| H["Stopped because evidence is missing,
or referred for a separate decision"]
  F1 -.-> X["Field incomplete: stop there and
hand it back to the responsible role.
A blank field is not consent"]
  F2 -.-> X
  F3 -.-> X
  F4 -.-> X
  F5 -.-> X
  F6 -.-> X

Seven passes over one sheet of paper

The six fields are filled in sequentially, offline. If any field is incomplete, you stop at that field and return it to the responsible role — you do not skip ahead and come back.

1. Step 1

   Complete the source review

   Document the managed templates, the initialization responsibilities and the daemon calling responsibilities separately. Three distinct responsibilities, three separate notes. Do not treat source content as live-environment settings, and cite the pinned version with a plain statement that no inference about deployment results follows from it.

2. Step 2

   Check the approval status

   Confirm only whether there is a controlled record, a responsible role, a purpose, a data category and a validity status. If any one of those is missing, mark the record unapproved and do not create an alternative path. Not a narrower path, not a temporary one — none.

3. Step 3

   Draw the observation boundaries

   Describe the allowable scope and the explicit exclusions using abstract data categories. If the proposal involves live read-only, it is still marked approval-required at this step, and this chapter does not give you a read method to use once it is approved.

4. Step 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 outright. Record the responsible handoff roles as you stop, so the record names who it went back to.

5. Step 5

   Document responsibility for the restoration decision

   Specify which role determines whether to restore, inside the independent approval process, and what evidence has to be available before that decision is made. Do not list candidate actions. The field answers who decides and on what, never what to run.

6. Step 6

   Add the evidence notes

   Mark every column as source fact, approved observation, inference, or unknown, and write the evidence limit and the masking status alongside. An unknown that is honestly labeled is worth more here than a confident sentence with nothing behind it.

7. Step 7

   Second-person review, then close the record

   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. Those are the three outcomes. There is no fourth.

Because a record can move backwards as easily as forwards, it helps to hold the states in your head rather than the steps.

stateDiagram-v2
  state "Every field stopped" as Stopped
  state "Fields being filled" as Filling
  state "Second person review" as Review
  state "Complete" as Complete
  state "Referred" as Referred
  [*] --> Stopped
  Stopped --> Filling: a field qualifies
  Filling --> Stopped: a field is incomplete
  Filling --> Review: all fields filled
  Review --> Complete: checks pass
  Review --> Stopped: evidence missing
  Review --> Referred: separate decision
  Complete --> [*]
  Referred --> [*]

What counts as finished

A qualifying result is traceable to a six-field offline record. It proves that the document fields and the manual gates have been reviewed. It proves nothing about maintenance, changes, or restores having been completed in any environment. Read down this list before anybody signs it off.

• The source review cites only the pinned version, and states that no inference about deployment results can be drawn from it.
• The approval field contains purpose, data category, role, valid status and controlled references — with no verbal shortcuts.
• The observation boundary states clearly that live read-only is still approval-required.
• The stop field covers change, privilege, connection, hardware, ETS, telegram, group and physical control requirements as things that may not be carried out.
• The restoration field records independent decision-making responsibility and prerequisites only, with no execution instructions.
• The evidence notes separate source facts, approved observations, inferences and unknowns.
• The record contains no commands, no identifying information, no environment times, and no description of a field success.

The form you reach for on the bad morning

Chapter 22 is the incident version of the same idea, and it exists because urgency is where documentation discipline dies. Its purpose is to get incidents to the right people without triggering a live-environment investigation or remediation. You prepare a five-box event table with no environmental values in it, and a list of the responsible roles that already exist in your organization. Budget about 15 minutes.

Before the fields, the order of operations. It has one branch, and that branch comes before everything else. Chapter 22 states its stop conditions above the form, not at the end of it, and they are the first thing to read on the morning you need the form at all.

flowchart TD
  A["An incident is reported"] --> B{"Unexpected physical movement, a safety risk,
or any concern for people, the building, door locks,
lighting, HVAC or actuators?"}
  B -->|"yes"| B1["Leave this form. The person responsible for the site
takes over immediately. Contact the live-environment
person in charge and safety professionals
under the existing emergency procedure"]
  B -->|"no"| C["Stop your own unapproved trial and error.
Stop public posting"]
  C --> D["1 Symptom classification"]
  D --> E["2 Containment decision"]
  E --> F["3 Privacy-safe evidence"]
  F --> G["4 Escalation ownership"]
  G --> H["5 Restoration ownership"]
  H --> I["Second reviewer checks the five fields,
then hands the form to incident command"]

Five fields, and they establish a decision and responsibility chain, nothing else.

Seven moves, and none of them touch the system

The runbook instructs people to stop, report and hand over. It does not direct the live system at any point.

1. Step 1

   Stop, and find someone

   Stop all unapproved trials and all public posts. If there are physical safety concerns, contact the live-environment person in charge and safety professionals immediately, following the established emergency procedure. This step is first because everything after it assumes nobody is still experimenting.

2. Step 2

   Fill in the symptom classification

   Select only from the available categories: User Visible Function Category, Initialization Responsibility Thread, Daemon Call Responsibility Thread, Driver File Type, or Insufficient Information. Do not specify a root cause. If the honest answer is the last of those five, that is a complete answer.

3. Step 3

   Complete the containment decision

   The incident command role decides which personnel activities must stop, which public information must be restricted, and who takes over. Do not enter service start or stop actions, configuration changes, connection steps, or hardware measures. The field constrains people, not machines.

4. Step 4

   Fill out the privacy-safe evidence form

   Record the controlled evidence reference, the evidence category, the masking status, and the boundary between fact and inference. Original material remains in a controlled location, handled by authorized actors — it does not get pasted into the form to save a trip.

5. Step 5

   Fill out the escalation ownership form

   Assign the roles that should take over, by category: security, privacy, source version, or unknown responsibility. If a role is missing, stop and notify incident command. A gap in the chain is a reason to halt, not a reason to improvise a substitute.

6. Step 6

   Fill out the restoration ownership form

   Name the role with authority to initiate the independent approval decision, and the role responsible for reporting the assessment results back. Do not propose candidate remediation or verification actions, however obvious one of them looks from where you are sitting.

7. Step 7

   Review and hand over

   A second reviewer confirms that all five fields are complete, with no identifying values and no live procedures, then hands the form to incident command. The status is one of three words: handover, stopped because evidence is incomplete, or waiting for responsible role.

What counts as finished

The completion standard for this chapter is a clear chain of responsibility, not a recovered system. Even when an independent process returns a status, this form accepts only a handover summary that has been reviewed, de-identified, and accompanied by an evidence limit.

• Symptom classifications describe functional or documented responsibility categories, with no root cause claims.
• The containment decision limits unauthorized personnel activity and information spread only, and includes no live-system action.
• Public evidence carries only controlled references, categories, masking status, unknowns and evidence limits.
• Escalation responsibility names incident command, site security, privacy review, or another responsible role explicitly.
• Restoration responsibility sits with an independent approval process outside this chapter, which contains no remediation or verification step here.
• There are no commands, probes, restarts, configuration changes, telegram, ETS, group, physical or bus actions anywhere in the form.
• KNX bus, ETS, integration, group operation and physical control results remain unconfirmed.

Fourteen sentences you will hear, and what each one is worth

Both chapters end with the same kind of table, and both are worth reading before you need them. These are not hypothetical objections. They are the things said out loud in a corridor while somebody waits for you to agree.

During routine operations

During an incident

The objections worth answering properly

Where to go from here