The deliverable is a table, and that is not a consolation prize

Chapter 19 produces a symptom triage sheet. Chapter 20 produces an anonymous offline decision tree. Neither produces a working link, and neither claims one. Both are budgeted at about twenty minutes, and both list, in their own words, a set of stop conditions that fire the moment the work starts to want a live system.

Read the second column of that table again. Chapter 20's bottom line is blunt about what you do not do: you do not look at the device list, you do not copy paths or serial numbers, and you do not try the driver, reboot, or touch the bus. Chapter 19's is the same shape: you put only the symptom concepts that appear in the pinned source into the offline triage table, and you do not restart the service, try changing drivers, probe endpoints, connect to the bus, or post any previous internal errors.

There is one more thing both chapters refuse, and it is the one that catches teams out. Earlier internal link errors are not a public result of this work. Even with the text obscured, an internal error cannot be rewritten as something this site observed, reproduced or verified. If the material in front of you came from a real incident, it stays inside the controlled internal process it came from.

The layer a symptom belongs to, and the layer it says nothing about

The formal name for what Chapter 19 asks you to build is a documented symptom classification for the process layer, the listener layer, the driver layer, the interface layer and the KNX bus layer. The informal name is a triage desk. A file arrives, the desk reads the symptoms on the outside of it and sends it to one of five desks. The reviewer at that desk does not decide the equipment inside the box is broken because of what is written on the box, and does not announce that the whole road is open because one document turned up.

What makes this more than filing is the second half of every row: the evidence ceiling. Each layer's vocabulary describes that layer and stops there.

flowchart TD
  P["Process layer
Words about the daemon being up or down"]
  L["Listener layer
Words about who waits to receive work"]
  D["Driver layer
Driver family names and documented failure states"]
  I["Interface layer
Neither pinned source reaches this far"]
  B["KNX bus layer
Neither pinned source reaches this far"]
  P -. "cannot prove" .-> L
  L -. "cannot prove" .-> D
  D -. "cannot prove" .-> I
  I -. "cannot prove" .-> B

Four columns, six steps, and a sentence you write before anything else

Set the sheet up before you have a symptom to put in it. Four columns, and the discipline lives in what each one is allowed to hold.

A column stops the work rather than getting filled in whenever it has an unknown source, whenever it makes a cross-layer inference, whenever it asks for a live-environment action, or whenever it still contains identifying information. Those four are stop conditions, not warnings.

What you bring to the desk matters as much as the columns. Two pinned sources and a blank table. No internal logs, no screenshots, and nothing you remember an error saying.

1. Step 1

   Pin the source

   Confirm that the symptom concept in front of you comes from one of the pinned versions this chapter lists. If the source is unknown, stop. Not “write it down and check later” — stop.

2. Step 2

   Choose a layer

   Put the concept into the process, listener, driver, interface or bus column according to the responsibility the document gives it. Where there is not enough information to place it, mark it unclassified and leave it there.

3. Step 3

   Write an evidence limit

   On the same row, in your own words for that concept: process vocabulary cannot prove the listener, listener vocabulary cannot prove the endpoint, and driver vocabulary cannot prove the interface or the bus. This is the column people skip, and it is the column the sheet exists for.

4. Step 4

   List the unknown items

   Compatibility, hardware, wiring, endpoint reachability and bus status all stay unknown. Do not pick the most plausible root cause among them. A plausible cause written into a triage sheet becomes, three days later, a cause somebody remembers being told.

5. Step 5

   Exclude internal results

   Delete anything reading “seen”, “reproduced” or “displayed locally”, and any wording like it. What is left is the abstract classification the document supports, and nothing else.

6. Step 6

   Submit to independent review

   A second reader checks that every column carries a source, a layer, an evidence limit and its unknown items, and that there is no prompt anywhere in the sheet to go and do something live.

flowchart TD
  A["One symptom concept in hand"] --> B{"Is the wording from one of
the two pinned files?"}
  B -->|"no"| S1["Stop. Unknown source"]
  B -->|"yes"| C{"Does it match exactly one
documented responsibility?"}
  C -->|"no"| U["Mark it unclassified"]
  C -->|"yes"| D["Write the layer, then the evidence
limit, on the same row"]
  D --> E{"Does the row still name a host, endpoint,
path, serial number or time?"}
  E -->|"yes"| S2["Delete the row. Rewrite it from
the source abstraction"]
  E -->|"no"| F["Leave hardware, wiring, compatibility,
reachability and bus status unknown"]
  F --> G["Hand it to a second reader"]

The sheet is done when all six of these are true of it.

• Each symptom concept corresponds to a pinned source and to a single primary layer.
• Programs, listeners, drivers, interfaces and buses are not mixed together into one conclusion about success or failure.
• Each column states clearly what it supports and what it does not support.
• Hardware, wiring, compatibility, endpoint reachability and bus status remain unknown.
• Earlier internal bugs have not been published as observations, reproductions or verification results.
• There are no hosts, endpoints, paths, serial numbers, accounts, secrets, addresses, ranges or times anywhere in the table.

USB and serial, with the identifying half of every symptom removed

Chapter 20 narrows to USB and serial interfaces, and it narrows the evidence with it. The formal name is anonymous symptom classification for missing candidate, path-change and driver-category. Three symptom cards, none of which carries a live-environment value.

Each card has a strict definition and, more importantly, a strict list of what may not go on it.

Three of those are branches; the fourth is what you reach for when a statement does not qualify as a branch. Read the three terms literally, because each is smaller than it sounds. A candidate is only an abstract item that the source describes for configuration preparation. A path change indicates only that a category relationship changed. A driver category indicates only a documented responsibility. None of the three prove anything about USB, about a serial interface, or about hardware status.

The worksheet inherits the same prohibition as the triage sheet, extended to hardware identity. No device paths, no USB serial numbers, no hosts, no endpoints, no addresses, no accounts, no secrets, no environment names, and no times that can be tied back to a site. If the material handed to you contains any of that, you do not copy it across — you return it to the controlled privacy process it should have stayed in.

Draw the tree before you go looking for a device

The order here is the safety measure. You draw the decision tree first, while there is nothing to be tempted by. The root node asks one question and only one: which symptom matches the existing de-identified description? Every branch other than the three is marked insufficient information.

flowchart TD
  R["A de-identified symptom statement"] --> G{"Sourced, single, and free
of live-environment values?"}
  G -->|"no"| D["Unknown card.
Stop classifying"]
  G -->|"yes"| Q{"Which description does it match?"}
  Q -->|"no candidate"| A["Missing candidate card
No candidate appeared
for the expected category"]
  Q -->|"category changed"| B["Path change card
The reference type
differs from before"]
  Q -->|"driver wording"| C["Driver clue card
A documented
responsibility, no more"]
  A --> E["Only document classification supported.
Live availability not confirmed"]
  B --> E
  C --> E

1. Step 1

   Confirm the source boundaries

   Accept only the initialization responsibilities and the documented driver concepts described in the pinned version. No source means insufficient information, and insufficient information means the unknown card.

2. Step 2

   Remove the live-site details

   Keep abstract descriptions — “missing”, “different reference categories”, “driver responsibility category”. If what you are left with could still identify the environment, stop there rather than trimming further.

3. Step 3

   Evaluate the first branch

   If the description says only that the expected category was not a candidate, add a missing-candidate card. Do not guess at hardware, at permissions, or at reasons. “Probably the cable” is a reason.

4. Step 4

   Evaluate the second branch

   If the description says only that the reference category differs before and after, add a path-category-change card. Do not record the old value, the new value, or the enumeration method that produced either.

5. Step 5

   Evaluate the third branch

   If the description can only correspond to a driver responsibility or a failure concept in the document, it goes on the driver-category clue card. Do not generate trial suggestions from it.

6. Step 6

   Limit the conclusions

   Every card carries the same closing sentence: Only document classification supported; all live-environment availability not confirmed. On every card, not once at the bottom of the page.

7. Step 7

   Independent review

   A second reader confirms that each branch is single, that it comes from a pinned source, that it holds no identifying values, and that there are no commands, enumerations, tryouts, restarts or bus actions anywhere in it.

The finished worksheet is an anonymous offline decision tree. It is not a diagnosis, and it does not indicate that any device has been viewed, detected or verified. Six things have to be true of it.

• The root node accepts only de-identified symptom statements that pinned sources support.
• The three branches are precisely the lack of candidate items, candidate path category changes, and driver-category clues.
• Each card carries a source category, a symptom category, an evidence limit, its unknown items, and a responsible role.
• There is no device path, USB serial number, host, endpoint, address, environment name or time to associate.
• There are no commands, no device enumeration, no driver testing, no hardware plugging, no service restarting and no bus actions.
• USB, serial interface, driver, KNX bus, ETS, integration, group and physical control results all remain unconfirmed.

Both chapters spend half their length refusing requests

Look at the troubleshooting lists in these two chapters and you notice something unusual: most of the entries are not faults in the sheet. They are people asking you to do the sensible next thing. Both chapters answer the same way, and it helps to know where the line falls before somebody is standing over you asking.

flowchart TD
  R["Someone asks for the next obvious thing"] --> Q1{"Does it touch a running
environment at all?"}
  Q1 -->|"no"| P["Safe. It is paperwork"]
  Q1 -->|"yes"| Q2{"Is it read-only viewing?"}
  Q2 -->|"yes"| AP["Approval required. Neither chapter
supplies a viewing method"]
  Q2 -->|"no"| Q3{"Group read or write, telegram, ETS
programming, interface or bus, or
physical equipment?"}
  Q3 -->|"yes"| N["Never automate.
The test bus is no exception"]
  Q3 -->|"no"| IT["Isolated test only, behind written approval,
a non-production rig, an administrator present,
limited network exposure and a proven
stop-and-recovery plan"]

The refusals from Chapter 19, with what to do instead.

And the same list from Chapter 20, where the temptations are hardware-shaped.

The objections these two chapters get

Where to go from here