Two chapters in the recovery half, and neither one presses a button

You have come through the commissioning half of this guide: the daemon, the interface, the driver, the INI, the ETS preflight, the Home Assistant entity model, the safety test matrix. Part 7 opens the third stretch — running it, and recovering when it breaks — and an installer reasonably expects it to open with a backup job and a firewall review. It does not. It opens with two sheets of paper.

Chapter 17 defines backup scopes, restoration responsibilities and a de-identified evidence index. Chapter 18 identifies gaps in permissions, secrets, network exposure and approval workflows. Neither creates a backup. Neither restores one. Neither modifies a firewall, a credential, an account or a network. The output of both is a record, and the record is the thing you will be glad of at two in the morning when someone with physical access to the cabinet asks whether it is safe to put the project back.

Each chapter carries its own stop conditions, and they are worth reading before you pick up a pen rather than after somebody has already pasted something into a work order.

Both chapters sort every proposed action into the same four tiers, and the sorting does not change because the action sounds harmless.

flowchart TB
  subgraph OUT["Not done here"]
    direction LR
    O1["Isolated test
written approval, non-production rig,
admin present, limited network exposure,
stop-and-recovery plan"]
    O2["Approval required
viewing or changing a running
environment, read-only included"]
    O3["Never automate
group read or write, telegram,
ETS programming or downloads,
interface or bus connection,
control of physical equipment"]
  end
  subgraph IN["Safe: what Part 7 does"]
    direction LR
    I1["Offline pinned sources,
read only"]
    I2["Category and placeholder
worksheets, no live values"]
  end

One more framing to keep hold of, because it governs every sentence in both chapters. Everything this guide states is bounded by pinned sources — for Chapter 17, knxd/DOCS.md at the pinned KNXD Add-on 0.6.1 commit; for Chapter 18, that same file together with knxd/config.yaml. Those sources support what a field is called, what a document says, and what an options schema declares. They support nothing at all about what is running in your building, what is reachable on your network, or what is on your bus. Publication is not site validation.

Two claims you may write, and one you may not

Chapter 17 turns on a single distinction: the saved content is one thing, the index of the saved content is another. An external reviewer, an insurer, a client's IT department or the next installer on site usually needs only the second one.

The formal names for the four things that card is doing are backup scope, chain of custody, restoration responsibilities and de-identified evidence indexing. In this chapter you complete the card only. The existence of a backup does not prove a successful restore, and the integrity of a copy does not prove that an application can read it or restore state from it.

That gives three separate kinds of evidence, and the whole discipline of the chapter is refusing to let the cheap two vouch for the expensive one.

flowchart TD
  A["A copy exists"] --> A2["You may write:
copy recorded"]
  B["An offline integrity record matches"] --> B2["You may write:
controlled replica consistent"]
  A2 -.->|"does not prove"| C["Recoverable"]
  B2 -.->|"does not prove"| C
  C --> D["Needs accurate versioning, compatibility,
scope of approval, stopping conditions
and evidence of an independent exercise"]
  D --> E["Pinned sources do not support
that set of procedures.
Mark restoration unverified"]

Responsibility splits the same way. The backup role manages retention and expiration. The restoration role decides when a separate restoration exercise may begin. The independent-review role checks scope, evidence limits and privacy. A statement that “someone is responsible” cannot replace these three distinct assignments.

Filling in the card without filling in a single live value

Prepare a blank index that contains no live values, and fill every field with a category, a role or a status. Five columns, and each has a rule about what may go in it.

The responsibility column lists five roles and the step that fills it in names four of them — creation being the one the step leaves implicit, since somebody has already made the copy by the time the card is written. Fill in all five and you have satisfied both readings, which is the cheaper option when a reviewer is reading your card rather than the source.

Six steps, in order. They organize paper management information and nothing else — you will not open a formal project, nor create, import, or overwrite any content.

1. Step 1

   Write down the purpose of saving

   Explain in one sentence why backup management is needed, and state on the card that this chapter does not perform backup or restore. That second sentence is doing real work: the card outlives the afternoon you wrote it, and its next reader will not have this page open.

2. Step 2

   Define the backup scope

   List only the data categories that need to be saved and those that must be excluded. Do not fill in any live values. An exclusion category is as much a decision as an inclusion, and it is the half that gets left blank.

3. Step 3

   Assign responsibilities

   Assign custody, restoration decision-making, independent review and exception approval roles respectively. Then write the retention policy and the handover conditions. If a role has nobody, leave it visibly unassigned rather than quietly attaching it to whoever is nearest.

4. Step 4

   Create a privacy-safe index

   For each preservation category, document the status, the source version, the retention policy and the evidence limit. Replace actual content with Redacted or Pending Verification. Those two placeholders are not the same claim, and choosing between them honestly is most of the value of the row.

5. Step 5

   Mark the evidence limit

   Separate copy existence, offline integrity record and recoverability. The first two items cannot endorse the last one. Write the limit on the row itself, where the next reader will meet it, not in a note at the bottom of the sheet.

6. Step 6

   Submit the index for independent review

   Confirm that the index does not identify the environment and does not state unverified results as facts. If anything is missing, return it for correction rather than approving it with a comment.

The gate that matters most on this card is the one in front of an actual restore, because that is the request that arrives under pressure and from someone senior.

flowchart TD
  R["Someone asks for a restore"] --> Q1{"Is a restoration decision
role named on the card?"}
  Q1 -->|"no"| N1["Leave it unassigned and stop.
Custody does not inherit
the decision"]
  Q1 -->|"yes"| Q2{"Scope, written approval and
stopping conditions all present?"}
  Q2 -->|"no"| N2["Treat it as unapproved
and keep it stopped"]
  Q2 -->|"yes"| Y["A separate restoration exercise
can be planned under its own
approval. Chapter 17 presses nothing"]

The one instruction both chapters repeat, word for word

Each chapter states it four times over: in the preparation, in the steps, in the completion check and again in the FAQ. When a source repeats an instruction eight times across two short chapters it is not padding; it is a rule the author expects to be broken.

What you may use instead is narrow and conditional. When there is a real need for governance, and the data is not derived from live events and the environment cannot be identified, a reviewed formalized policy deadline or an abstract expiration status can be used. When precise dates are not required — and on these two sheets they generally are not — relative or status classifications are preferred.

This is why a status classification is the default and a date is the exception. A deadline that came out of a reviewed policy document describes an intention. A timestamp scraped from a log describes an event that happened in a real building, and once it is in a shared worksheet you cannot get it back.

Which doors did not need to be open in the first place

Chapter 18 starts from the opposite end to the way commissioning usually goes. Rather than asking what still needs opening to make the job work, it asks which openings could be closed without anybody noticing. Convenience is not a reason to retain exposure.

The formal names are least privilege, minimal network exposure, minimized secrets and traceable approvals. The worksheet turns them into four questions asked of every row: what is needed, who is responsible, when, and how to cancel. You record only categories and decisions — never a key's contents, never a door's location.

Draw the four columns before you collect any information. Every column carries the same six attributes: requirements, ownership roles, approval status, expiration policy, revocation method and evidence limit. What differs is what is permitted inside.

Two categories of information get confused constantly on jobs like this, and they leak by different routes. Secrets grant access directly. Environment-identifying data reveals asset relationships. Neither belongs in public guides, screenshots, log excerpts, work orders, or submission records — and the second one is the one that gets pasted, because it does not look like a secret.

The review produces a gap list, not a configuration

This review produces a list of gaps. It does not produce settings, commands, or live results. Six passes, in order.

1. Pass 1

   State the necessary purpose first

   Each column addresses only one requirement. Mark any item without an explainable purpose as a risk to remove. “It was already like that” is not a purpose, and neither is “the last engineer needed it.”

2. Pass 2

   Check the secret column

   Confirm that public records only show confidential processing status. Sharing stops the moment any secret value appears — not after the sheet is finished, and not after it has been sent to one more person for a quick look.

3. Pass 3

   Check the permissions column

   Separate reads, changes, approvals and reviews. Record a missing expiration policy, a missing revocation method or a missing owning role as a gap. These are three different absences and each gets its own line.

4. Pass 4

   Check the network-exposure column

   Use trust boundary categories to describe the necessary interfaces. Any exposure without a purpose, a role or a duration policy is listed as a gap. On a KNX job this is the column where a commissioning convenience quietly becomes a permanent route into the bus side of the building.

5. Pass 5

   Check the approval record column

   Verify that each exception has a scope, an approval role, an expiration policy, revocation conditions and a controlled record reference. An exception missing any one of those five is an exception in name only.

6. Pass 6

   Do an independent review

   A different role checks the four columns and the data minimization. The conclusion is written as one of three words, and no other.

Inside those passes, one row at a time, the sheet is really a four-gate test. A row that clears all four gates is complete; a row that fails any gate produces a named gap rather than a permission.

flowchart TD
  A["One row: a secret, a permission,
an exposure or an exception"] --> Q1{"Purpose
explainable?"}
  Q1 -->|"no"| G1["Risk to remove"]
  Q1 -->|"yes"| Q2{"Owning role
named?"}
  Q2 -->|"no"| G2["Governance gap.
Add no new permissions"]
  Q2 -->|"yes"| Q3{"Expiration
policy set?"}
  Q3 -->|"no"| G3["Incomplete. Do not replace
a missing decision with
permanent exposure"]
  Q3 -->|"yes"| Q4{"Revocation method and
controlled record reference?"}
  Q4 -->|"no"| G4["Exception in name only"]
  Q4 -->|"yes"| OK["Row recorded as complete"]

What each chapter counts as finished

Chapter 17 is complete when the index is safe for review — not when the environment is restorable. Eight checks:

• The purpose of preservation and the inclusion and exclusion categories are all clear, with no environmental values.
• Custody, restoration decision-making, independent review and exception approval each have a responsible role.
• The evidence index contains only category, status, retention policy and source version.
• No environment or event timestamps, log timestamps, backup creation times, execution times, or any time associable with family activities or system events.
• Where governance genuinely required a date, it is a reviewed formalized policy deadline or an abstract expiration status, not derived from live events and not identifying the environment.
• A copy's existence and its offline integrity are not described as proof of a successful restore.
• Accurate backup procedures, compatibility and restore results are still marked unverified.
• All environment, KNX bus, ETS and integration results remain unproven.

Chapter 18 is complete when the result is a de-identified governance list. It does not indicate that any control has been applied in a production environment. Eight checks:

• The secret field has no credentials, tokens, sessions, passwords, cookies, or retrievable connection information.
• The permission column separates read, change, approval and review, and records deadline policies and cancellation responsibilities.
• The network exposure column contains only requirements, trust boundary categories, owning roles and expiration policies.
• Each exception has an approval role, a scope, an abstract expiration status and revocation conditions.
• The record has no host, endpoint, account, path, serial number, address, topology or environment name.
• No environment or event timestamps, log timestamps, backup creation times, execution times, or any time associable with family activities or system events.
• Where a date was genuinely required for governance, it is a reviewed formalized policy deadline or an abstract expiration status.
• All field controls, execution environments, buses, ETS and integration results remain unproven.

The twelve ways these two sheets go wrong

Both chapters ship a troubleshooting list, and the entries are less about mistakes than about pressure — the moment where the honest answer is inconvenient and the sheet quietly gets a better one. Six from the backup card first.

Six more from the exposure sheet.

The ones that come up on site

Where to go from here