A.19.SelectorMechanism:4.2 - Boundary and layering rules

0. Selection conditions are explicit values, not a new object kind. The actual application binds CriteriaSlot plus effective selector-policy refs, defaults, and degrade failure behavior. Acceptance and admission predicates remain separate. SelectionSlot contains only the resulting candidate set; eligibility, conditions, scope, evidence, and replay metadata stay outside it.

1. Selection consumes a traceable finite basis of upstream CHR products; it does not invent them. Any indicator-derived scoring or comparison input retains its exact A.19 basis and the UINDM positions selected under that declaration. A changed basis requires the affected upstream position resolution and result again; the selector cannot carry old naked indices into the new declaration. The actual use binds exact binary CPM applications separately and supplies ComparisonResultSlot only as the union of their justified outputs. The kernel MUST NOT perform normalization (UNM), indicatorization (UINDM), scoring (USCM), folding (ULSAM), comparison (CPM), batch-result fabrication, or missing-pair completion inside Select. If a scalar “overall score” is desired, it must be declared upstream as an admissible scoring or comparator choice, not invented inside selection.

2. Threshold discipline (acceptance is not selection). Acceptance and admission thresholds are not selection criteria: they remain in their governing declarations and are applied only through SelectEligibility. Selection-level tie-breakers, PortfolioMode, and selected-set constraints may exist, but they MUST be explicit in current criteria or policy refs and bound by the actual selection application, never hidden as unnamed constants.

3. Report‑only summaries inside suite closure. Any scalar summaries, illumination metrics, or auxiliary “why not chosen” telemetry are report‑only unless explicitly promoted by policy, and MUST NOT be used as hidden dominance rules (A.19.CHR:4.3.3). Publishing and telemetry remain outside suite closure and are handled by established publication forms such as G.10 or PTM, not as hidden tails inside selection.

4. Specializations are explicit and disciplined. A proposed specialization of SelectorMechanism must retain these local restrictions:

   • SlotKind invariance for inherited operations,
   • no new mandatory inputs to inherited Select,
   • added capabilities appear as explicitly declared new operations or additional results under the local ⊑⁺ notation.

   For the exact refinement, conservative-extension or equivalence claim, apply its own A.6.1 §4.8 test, preserving the applicable operation, application and binding meanings. CC‑A19SelectorMechanism‑10 retains the exact predicate, endpoint facts and A.6.RCD gap branch.

5. Planned use and actual binding. An A.15.2 baseline selects TaskSignature, CG-Spec and evidence-policy editions. A.15.3 supplies planned filling only for an independently declared receiving position. Actual Select arguments and returns are established under this declaration; the planned values remain available for a separately governed comparison with what occurred.