Chapter overview
Bottom line: Draw only an offline responsibility map and sort settings into labeled drawers. Do not enter values, write files, or apply settings.
- Purpose
- Use labeled drawers to separate INI sections, options, and generation responsibilities.
- Prepare
- A blank sheet of paper with the responsibility classifications for Chapters 7–8; no configuration files or execution data required.
- Time
- About 20 minutes
- System change
- Do not modify the INI or start or stop the Add-on; only read the pinned version of the managed template offline.
- Expected result
- Relate INI sections and options to the component that generates them without treating the template as deployable live configuration.
- Stop conditions
- You need to fill in the real environment values or write the template directly into the system.
- Steps require applying settings, installing or restarting the Add-on.
Scope and safety boundaries
This chapter is only classified on paper. Do not paste hosts, addresses, ports, devices, serial numbers, secrets, or live settings. Do not read local results, and do not use the template as the current setting.
This chapter does not add the repository, install or start it. This site lacks approved immutable artifact/image digest and source-to-build proof, so all execution is blocked.
Do not connect the interface or KNX bus. Group reading, group writing, telegram transmission, ETS programming or downloads and physical control are prohibited. Paper comparisons cannot prove daemon, listener, integration or bus results.
Core concepts
Read the label first, then identify the responsibility. Do not place any live-site material in the drawer.
Labeled file drawers
Think of it this way: The office uses different drawers to collect different types of forms. The drawer label only says what is collected here, it does not prove that the form has been filled out, nor does it mean that someone has worked according to the form.
Formal term: INI sections, options, and managed-template responsibilities. A background program (daemon) is an execution role that this chapter does not verify.
Options define input categories. Sections organize related settings. Managed templates are source material. None represents a live result.
Your diagram only needs four drawers: "Main Responsibility", "Service Responsibility", "Record Responsibility" and "Interface Responsibility". If a piece of information cannot be classified based on pinned sources alone, it is put into "pending evidence".
Preparation and prerequisites
Take a piece of paper and draw five empty frames. The first four boxes are the four accountability drawers. The fifth box is "Evidence to be supplemented". Only put category words in each box.
- Write "Offline Responsibility Chart" at the top of the paper.
- Write "does not contain live values".
- Write "No execution results were generated, applied, or read."
- Address version differences under Versions and compatibility; do not mix content from other versions.
If the information at hand contains environmental identification content, do not copy it. Record only "requires confirmation by authorized personnel at a controlled location".
Steps
- Put the main responsibilities first. Put the overall connection and coordination roles into the main drawer. Do not fill in any value.
- Then put the service responsibility. Put roles waiting for handover from other software into the service drawer. Do not infer that the service exists.
- Separate documentation responsibilities. Put message levels and record categories into the record drawer. Do not copy local logs.
- Separate interface responsibilities. Write device, filter, or network inputs as categories only. Don't put paths or endpoints.
- Mark source boundaries. Each category card indicates that it comes from an input schema or a managed template. Don't write two sources as if they were the same thing.
- Write a limited conclusion. Finally, just write "Offline responsibilities have been compared" or "There are still gaps." Do not write deployed or ready for use.
Verification and evidence
The finished product must be a responsibility map without live values. It identifies which category owns each type of data but does not describe what a system is currently doing.
- I have five drawers: main, service, record, interface and pending evidence.
- I label input schemas and managed templates separately.
- My image has no host, address, port, path, serial number, secret or live settings.
- I did not write files, apply, install, start or stop, or read execution results, nor did I declare any bus or integration results.
Next step: Go to Chapter 10, use handover checkpoints to distinguish the evidence layers of driver, interface and bus.
Troubleshooting
- You do not know which drawer applies: Put the item in "Pending evidence." Do not guess from its name.
- Someone posted the official value: Stop sharing and remove content. Responsibility diagrams only keep categories.
- The template looks complete: Still marked as source material. A complete appearance does not mean it has been generated or applied.
- The input schemas do not match the template: Record the two sources separately and mark the gaps. Don't make up the relationship on your own.
- Someone asked for immediate application: Stop. There is no writing, installing, or starting or stopping programs in this chapter.
FAQ
Advanced note: Technical boundaries of managed templates and source input
Fixed input schemas for Add-on 0.6.1 describe the data type, whether it can be omitted, and whether the source declares a default. Fixed managed INI templates describe the main, service, record and interface section roles. The former is a source input contract; the latter is managed source material.
The two sources support offline comparison of responsibilities, but they do not support claims about the template-generation method, current file content, read results, or application results. A source default is not a recommendation for a live environment. This chapter provides no execution-environment exchange format or results.
Is the drawer label the setting value?
No. Tags only represent responsibility categories and cannot be used to write into the system.
Does the completeness of the template mean that the current settings are complete?
No. The template and the current file are different kinds of evidence.
Can source defaults be used as recommendations?
No. A default exists only as a source fact, not as a production live-environment recommendation.
Is the daemon status still not proven after the comparison is completed?
Yes. Paper classification cannot prove program, driver, listener, interface or bus status.
How should I handle missing evidence?
Record the classification and responsible role. Do not use live-system access or guesswork to fill in gaps.
Evidence and sources
Evidence class: source-bounded
Feature crosswalk: addon-options-schema, addon-managed-ini-template
Pinned sources support only the documented scope. This page does not represent validation of any local environment, hardware, network, or KNX bus.