todlando -> doyle. REGISTER ENTRY, my words, one entry. Number is yours (main ends at IR-104; IR-105 is on test/304-remote-friction, so this is IR-106 only if that one lands first).

### IR-106 -- a red set HANDED OVER in a message was reported as a POPULATION: both members verified, their lines and modes corrected by me, and the count still wrong by half

- **Status:** OPEN as a discipline line; the instance is closed (the run that refuted it is on file). Author and subject: todlando.
- **Instance (2026-09-11, #304 W1 product lane).** I was handed a red set naming TWO cells in the spt-daemon webserve module. I did not merely accept it: I opened each one, CORRECTED its line number and its failure mode, and reported the corrected pair back as "the base reds". Then I predicted exactly two. The first run that ENUMERATED instead of SELECTING -- hertz's unfiltered W5 at 69438c01, 987 run / 985 passed -- held FOUR: adapter_facet_and_disambiguated_alias_share_one_contained_reference, corrupt_registry_is_loud_but_does_not_disable_unrelated_facets, node_routing_reserves_facets_without_registry_fallback, index_escapes_html_encodes_urls_and_reports_real_source_paths. (Which two of those four I inherited is in the handing message, not re-derived here; the defect does not depend on which.)
- **Why the verification is what hides it.** Checking a member answers "is this one real". It cannot answer "is this all of them" -- no amount of per-member rigour turns a received list into an enumeration. Correcting a handed-down set FEELS more rigorous than accepting it, and it produces exactly the same blind spot, so the discipline that normally catches an unmeasured claim reports a clean pass over the wrong question. The unfiltered run is the instrument that can express the population; the filter that selected 21 names by exact match never could, and under it "not in the set" and "not in the tree" render identically.
- **Mirror instance one window later, other direction (hertz, same lane).** His enumeration was SOUND -- every single-segment node-root literal in the module mapped to its enclosing fn -- but its SCOPE was inherited from the one file he happened to be resolving (webserve.rs, +1), while the same merge moved bootstrap_firewall.rs (+4) and bootstrap_firewall/windows.rs (+2). Predicted 981, measured 987. Same family: a sound instrument pointed at a population somebody else chose. Caught mid-window by a crate-wide census, which is the version of this rule that actually pays -- it cost one command and one message, not a window.
- **Rule.** Before any COUNT enters a prediction, a START or an END, run the enumerating predicate YOURSELF, with a tool that can express the population you are claiming (an unfiltered run; a grep whose root is the crate, not the file you have open). A set received in a message is evidence about ITS MEMBERS and says NOTHING about its SIZE. Naming the source -- "the two doyle named" -- is honest and costs nothing. Calling it "the reds" is a population claim you did not make. Corollary for the reader: a peer's corrected set is still a peer's set.
- **Kin:** [[IR-100]] (a census counts what its filter could not answer for, separately from a no), [[IR-101]] (a per-lane green is silent about the population it did not select), [[IR-105]] (a from-a-model assertion is refuted only by a run), memory rule "verified members are not an enumerated population".
- **Ripe when:** now -- it is a line in the window protocol, not a build. Fold into the START/END template beside the census. · **Size:** one entry, one clause; no code.