Source changed 2026-10-03 14:36:52 UTC · snapshot created 2026-10-03 14:38:14 UTC · last check 2026-10-03 15:25:20 UTC
A.19.SelectorMechanism:0 - At a glance — didactic, informative
What it is: a universal set-returning selection kernel: it takes candidates, admissible comparison outcomes, and explicit criteria, and returns a selected set, not a forced single winner.
What it is not: it is not a hidden scoring model, not a comparator, not a gate, and not a telemetry or publishing step.
Why it exists: to prevent three recurring failure modes: hidden thresholds, silent scalarization, and winner‑take‑all defaults under partial orders and uncertain evidence.
Use this when: the current project question is selection from admitted candidates under explicit criteria after comparison has already been made or cited.
What this buys: the practitioner gets one selected-set value whose criteria, finite basis of exact upstream binary CPM applications, required comparison coverage, token provenance, scope, predicate basis, plane, window, and policy bindings are explicit. degrade and abstain remain eligibility values, not selected-set members or alternative result kinds.
First output: read the by-value candidate set bound to SelectionSlot. Read the candidate universe, finite upstream CPM application basis, required pair coverage, derived comparison-token union, selection conditions, claim scope and context slices, reference plane, evaluation window, eligibility value, and evidence use from the actual Select application and direct neighboring relations; they are not fields inside the selected set.
How it evolves: method semantics and SoTA algorithm families connect via G.2 packs and wiring modules; the kernel signature stays stable and teachable.
Suite stage:select (ordering lives only in A.19.CHR:4.5 and suite_protocols; suite membership is a set in A.19.CHR:4.2).
Inputs (conceptual): admitted candidates; a finite by-value basis of exact upstream binary CPM applications, each with its exact pair, realized GuardDecision, and own ComparisonResultSlot binding when produced; the exact union of justified relation or poset tokens from those bindings; explicit CriteriaSlot, CNSpecSlot, CGSpecSlot; one U.ClaimScope with selected A.2.6 U.ContextSlice members; the same A.19 predicate basis when one governs the comparisons or selection criteria; effective reference plane; explicit evaluation window; and optional TaskSignature and MinimalEvidence policy refs.
Output (conceptual): the by-value SelectionSlot candidate set. A singleton is allowed only under explicit selection conditions or an admissible upstream total order. The output is not a decision log, guard value, result episteme, generic result relation, publication, or replay record.
Non-goals: does not normalize (UNM), indicatorize (UINDM), score (USCM), fold (ULSAM), compare (CPM), define acceptance thresholds, publish, or emit telemetry; it is a selection step over already-admissible inputs.
Planned use: an A.15.2 baseline selects editions and policies. A.15.3 and SlotFillingsPlanItem apply only to independently declared receiving positions under A.19.CHR:4.7.2. The actual Select application carries its effective arguments and SelectionSlot binding under §4.1. Dated selection Work and an A.10 provenance account retain their independent grounds.
Transformation-flow use: an E.18 node cites this declaration. Planned refs use A.15.3 typed filling only for independently declared receiving positions; actual Select bindings remain governed by §4.1.
Failure mode: tri‑state guard (pass|degrade|abstain); missing or unknown evidence never coerces to pass.
Mental model:SelectEligibility gates the step; Select applies explicit criteria to set‑valued comparison outcomes; the result is a selected set whose “single winner” behavior must be explicit.