## Chapter 13 — Community order is the valid walk ### Lesson map Lesson 13. Map, example, EX059. ```mermaid flowchart TD V["valid, build order"] --> F{"Label is CLEAR or GREEN?"} F -->|Keep| P["GREEN domain, then the address"] F -->|Drop| A["AMBER skipped in between"] P --> Q{"Did CLEAR sort to the front?"} Q -->|No| K["Membership is not a sort"] ``` The pair `("TLP:CLEAR", "TLP:GREEN")` is a membership test. It does not rank the rows. ### Logical drawing ```text valid build order GREEN domain AMBER domain CLEAR address community print donate-elmfield.example 203.0.113.9 skipped between them elmfield-giftaid.example ``` ### Learning outcomes After this chapter, you should be able to: 1. Read the community list from top to bottom. 2. Explain why the address is second. 3. Refuse a list that leads with CLEAR because of the label. ### 13.1 The filter keeps a value where `valid` put it. It does not regroup by label. `public` walks `valid` and keeps a value when its label is in `("TLP:CLEAR", "TLP:GREEN")`. That tuple is the set of allowed labels. Writing CLEAR before GREEN inside the tuple does not sort CLEAR items first. The walk order is the order pairs were appended. The GREEN domain was appended first. The AMBER domain was appended second and then dropped. The CLEAR address was appended third and kept. The printed list is therefore the domain, then `203.0.113.9`. Python prints that list with brackets and single quotes, after the literal `shareable with community:`. The brackets are the representation. They are not a TLP colour. A classmate who moves the address to the front "because CLEAR is the wider label" has applied a ranking the comprehension does not have. A classmate who puts the AMBER name back to fill the gap has undone the filter. The invalid address never entered `valid`, so it cannot appear in this gap either. The gap is the dropped AMBER pair, not the rejected octet. | Position in `valid` | Community list | |---|---| | GREEN domain, first | Kept, first | | AMBER domain, second | Dropped | | CLEAR address, third | Kept, second | | The invalid address | Never present | ### 13.2 Worked example | Offered list | What the walk did | Decision | |---|---|---| | Domain, then `203.0.113.9` | Kept items in build order | Keep | | AMBER absent from the middle | The label test | Keep | | "CLEAR first, then GREEN." | The tuple is not a sort key | Refuse | | "Insert the AMBER name where it was skipped." | The filter removed it | Refuse | > **Synthetic case.** Two values are the whole community list. ### Errors and limits Do not reorder labels into a seriousness ranking. ### Apply - **EX059 — Filter order.** Why does `donate-elmfield.example` print before `203.0.113.9`, and why is the AMBER domain missing between them? *Rubric:* 3 = the walk follows valid build order; CLEAR-before-GREEN in the test tuple is not a sort; AMBER fails the label test and leaves a gap; the invalid address was never in valid;; 2 = build order, and AMBER is filtered out;; 1 = one value;; 0 = none. ### Continue studying — lesson 13 (chapter 13 of 20) [← Chapter 12](#ch-12) · [Course chapter index](../SUBJECTS.md) · [Chapter 14 →](#ch-14) Continue to the next authored lesson. ## Worked answers **EX059.** The walk follows valid build order. CLEAR-before-GREEN in the test tuple is not a sort. AMBER fails the label test. The invalid address was never in `valid`.