#Unified Selection Kernel (SelectorMechanism)

A.19.SelectorMechanism · Stable · Architectural (A) · Normative (unless explicitly marked informative) · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative) Placement: Part A, CN-Spec cluster (A.19), CHR mechanism-governing patterns Source: FPF, CHR mechanism-governing patterns Modified: 2026‑01‑20

Governing-pattern note: this pattern governs the canonical U.Mechanism.Intension for SelectorMechanism.IntensionRef (CHR suite stage select). Mechanism-intension semantics are governed by explicitly designated governing patterns (E.20:4.2). A.6.1 governs the semantic content of a U.Mechanism declaration. This pattern specialises that content for selection through the exact EntityOfConcernRef, effective U.ReferenceScheme, direct signature components, SlotSpecs, OperationAlgebra, LawSet, AdmissibilityConditions, and Applicability. An F.9 bridge relation, dated selection U.Work, actual Select operation application with its SelectionSlot binding, any result episteme, A.10 evidence-provenance graph relation, G.11 currentness relation, and any publication relation remain neighboring objects and relations. Other descriptions of SelectorMechanism cite A.19.SelectorMechanism:4.1 rather than restating its declaration content or absorbing those neighboring objects and relations into mechanism fields.

• 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 slot fillings: concrete edition and policy pins are planned fillings under the exact A.15.3 declaration and are carried by SlotFillingsPlanItem rows (A.15.3 plus A.19.CHR:4.7.2). The selector declaration does not bind project-specific fillings. Dated selection U.Work remains the performed occurrence; an actual A.6.1 Select operation application carries effective argument bindings and the selected-set SelectionSlot binding; and its A.10 evidence-provenance path records the evidence and currentness basis used for replay.
• Transformation-flow use: when used as a node type in E.18, project-specific selector-instance refs and pin refs are planned fillers in SlotFillingsPlanItem rows; this pattern governs the intension that those instances cite.
• 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.

#Keywords

• selection kernel
• set-returning selection
• selected set
• SelectEligibility
• tri-state guard (pass|degrade|abstain)
• no hidden thresholds
• no hidden scalarization
• CriteriaSlot
• ComparisonResultSlot
• TaskSignatureSlot
• evidence gating
• CG-Spec.MinimalEvidence
• CHR suite stage select
• Bridge+CL/ReferencePlane transport
• penalties→R_eff only.

#Relations

#Content

#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 slot fillings: concrete edition and policy pins are planned fillings under the exact A.15.3 declaration and are carried by SlotFillingsPlanItem rows (A.15.3 plus A.19.CHR:4.7.2). The selector declaration does not bind project-specific fillings. Dated selection U.Work remains the performed occurrence; an actual A.6.1 Select operation application carries effective argument bindings and the selected-set SelectionSlot binding; and its A.10 evidence-provenance path records the evidence and currentness basis used for replay.
• Transformation-flow use: when used as a node type in E.18, project-specific selector-instance refs and pin refs are planned fillers in SlotFillingsPlanItem rows; this pattern governs the intension that those instances cite.
• 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.

---

#Problem frame

FPF’s Characterization (CHR) suite treats selection as a distinct mechanism boundary within the suite (authoritative membership: A.19.CHR:4.2). Suite membership is a set; order has no semantics. Any intended ordering is expressed only via suite_protocols (A.19.CHR:4.5), under suite obligations (A.19.CHR:4.3).

Within the suite‑closed protocol, SelectorMechanism appears as the select stage (after admissible comparison; optional stages remain explicitly optional per suite_protocols). The kernel’s role is concept‑level and governed by CN‑Spec and CG‑Spec:

• consume admissible comparison outcomes without collapsing them into a hidden scalar,
• apply explicit criteria and policy references, and
• return a selected-set result whose defaults are policy-bound and whose dated work, actual Select application, SelectionSlot binding, and evidence-provenance basis can be replayed.

The kernel uses the CHR suite SlotKind lexicon (A.19.CHR:4.2.1) to prevent SlotKind drift across specializations and across SoTA wiring layers.

---

#Problem

Engineering teams regularly need to make “a selection decision” under conditions that are normal in real projects:

• comparisons are partial, multi‑criteria, or set‑valued,
• evidence is incomplete or policy‑gated, and
• different stakeholders ask for different “best” notions.

If selection is not a first‑class mechanism boundary with stable semantics, the same high‑risk drift happens repeatedly:

• Silent winner forcing: partial orders get collapsed to a single winner by ad‑hoc tie‑breakers or hidden weights.
• Hidden thresholds and constants: thresholds, weights, dominance regimes, and default PortfolioMode fields get smuggled into implementations and become invisible in discussion and audit.
• Scalarization by convenience: set‑valued comparison outcomes get replaced by a scalar “score summary” that is treated as decision‑relevant without being declared as such.
• Evidence coercion: missing or unknown evidence gets treated as “good enough” (implicit pass) rather than yielding explicit degrade or abstain.
• Boundary erosion: selection quietly performs comparison, scoring, aggregation, or publishing.
• Selection-boundary drift: a selected-set label is reused after candidate universe, finite upstream comparison-application basis or its required coverage, selection conditions, A.19 predicate, claim scope, selected context slices, reference plane, or evaluation window changed.
• Guard-output collapse: degrade or abstain is treated as a selected-set member or as a generic selection result.

---

#Forces

1. Set‑valued reality vs single‑winner convenience. Many admissible comparisons are partial orders. The kernel must preserve set‑valued semantics while still allowing single‑winner outcomes when explicitly requested by criteria.

2. Policy primacy vs method freedom. Criteria and defaults must be explicit and policy‑bound, while multiple method families and decision styles must remain add‑able without mutating the kernel.

3. No hidden thresholds vs usability pressure. Engineers often want “just pick one.” If the spec does not constrain this, hidden thresholds and tie‑breakers become de facto policy.

4. Evidence discipline vs delivery pressure. Under uncertainty, teams default to coercion (unknown → pass). The kernel must enforce tri‑state eligibility and fail‑closed discipline.

5. Replayability vs conceptual minimalism. The mechanism declaration stays small, while dated selection work, the actual Select application and its argument and SelectionSlot bindings, and the evidence-provenance path retain the effective editions, policies, candidates, and selected set needed for replay.

6. Evolvability vs didactic usability. The kernel must be stable enough to support SoTA wiring and specialisation chains, but also teachable: one place states the mechanism boundary, laws, eligibility behavior, and the neighboring replay basis for realized use.

7. Planned slot filling and gate and guard separation. Planned fillers and pins live in SlotFillingsPlanItem rows. Selection must not mutate into a gate pattern: no GateDecision or decision logs inside the mechanism boundary.

8. No competing defaults. If defaults exist for PortfolioMode, dominance regime, or archive policy, cite their declared sources rather than re-declaring them in the kernel.

9. Scope continuity vs legitimate reselection. Selection may narrow candidates or apply explicit policy, but it may not silently change the finite upstream comparison-application basis, its required pair coverage, any member's predicate basis, claim scope, selected context slices, reference plane, or evaluation window. A justified change is a new selection application and may require new binary comparisons.

---

#Solution

SelectorMechanism is the canonical selection kernel for CHR and for selector specializations. It provides:

• a stable mechanism boundary for select,
• a stable SlotKind field set (via the CHR lexicon),
• a minimum law set that preserves set‑valued semantics and forbids hidden thresholds and hidden scalarization,
• a tri‑state admissibility guard that is fail‑closed under missing admissibility or evidence,
• a replay basis that separates effective occurrence bindings, the selected-set result, and supporting evidence from reusable selector semantics;
• an explicit selection-use boundary that keeps candidate universe, the finite upstream comparison-application basis and required coverage, the derived token union, selection conditions, scope, predicate basis, plane, and window distinct; and
• output discipline: SelectionSlot contains only the selected candidate set, while eligibility, evidence use, provenance, currentness, result epistemes, and publications remain separate.

Method semantics and SoTA algorithm families do not live inside the kernel: they connect via G.2 SoTA packs and wiring modules, and via admissible specializations ⊑ and ⊑⁺ that obey the specialisation-chain discipline (A.6.1:4.2.1).

#Mechanism.Intension — normative core

Archetypal Grounding — Mechanism.Intension (normative).

• Declaration boundary: this A.6.1 intension declares Select and SelectEligibility; it does not bind project-specific pins or create selection scope, dated work, an actual operation application, gate decision, selected-set episteme, evidence use, provenance path, currentness relation, or publication relation. Each neighboring object or relation uses its direct governor.

• Canonicality note: this is the canonical U.Mechanism.Intension for SelectorMechanism.IntensionRef and is intended to be cited by CHR suite publications and by any wiring layers; other mentions are Tell + Cite only.

• IntensionHeader: id = SelectorMechanism, version = 1.0.0, status = stable.

• IntensionRef: SelectorMechanism.IntensionRef designates this U.Mechanism episteme as the canonical suite member named in A.19.CHR:4.2; it is not the EntityOfConcernRef of the declared operation family.

• Tell. Universal set‑returning selection kernel over candidates and criteria; defaults remain policy‑bound; no hidden thresholds.

• Purpose: universal set‑returning selection kernel over candidates and criteria; defaults remain policy‑bound; no hidden thresholds.

• Imports: A.6.1:4.2.1 (specialisation relation chains), A.6.5 (slot discipline; SlotIndex as projection), A.19.CN (CN‑Spec governance card), C.22 (TaskSignature as a policy-reference artifact when used), G.5 (selector conformance and default selection policy), G.0 (CG‑Spec admissibility and evidence gates), A.19.CHR:4.2.1 (CHR SlotKind Lexicon).

• EntityOfConcernRef: the selection operation family declared by Select and SelectEligibility in this section.

• Effective U.ReferenceScheme: the CHR suite reference scheme in which the A.19.CHR SlotKind lexicon, CN-Spec, CG-Spec, and any current TaskSignature tokens are interpreted.

• Direct signature components:

  • SubjectKind: Selection.
  • RangedValueKind: pair of values <admitted candidate set, relation or poset token set over the same candidate universe>.
  • ResultKind: U.Set of selected candidate values.
  • SliceSet: U.ContextSliceSet.
  • ExtentRule: selection ranges over one admitted candidate set and the exact union of justified relation or poset tokens from a finite basis of binary CPM applications whose pair endpoints lie in that candidate set and whose coverage satisfies the explicit selection conditions, all in one exact U.ClaimScope; selected U.ContextSlice values are members of that scope under A.2.6 and do not create duplicate membership.

  These are direct A.6.0 declaration components. They do not form another selector-content container, and they do not absorb candidate admission, comparison work, dated selection work, result, evidence-provenance, or replay relations.

• SlotIndex: derived projection from SlotSpecs (and any guard‑only SlotSpecs) per slot discipline; uses A.19.CHR:4.2.1 SlotKind tokens; has no independent semantics.

  • CandidateSetSlot : ⟨ValueKind = U.Set (candidates), refMode = ByValue⟩.
  • ComparisonResultSlot : ⟨ValueKind = U.Set (relation or poset tokens), refMode = ByValue⟩.
  • CriteriaSlot : ⟨ValueKind = U.Set (selection criteria or clauses, including explicit tie‑breakers; **acceptance thresholds are not criteria** and remain governed by the cited acceptance declarations and applied only via SelectEligibility), refMode = ByValue⟩.
  • TaskSignatureSlot? : ⟨ValueKind = TaskSignature, refMode = TaskSignatureRef⟩ optional; when present, SHOULD be the single policy-default slot or ref for selector defaults (e.g., PortfolioMode or dominance regime), but it does not replace CNSpecSlot or CGSpecSlot governing spec refs.
  • CNSpecSlot : ⟨ValueKind = CN‑Spec, refMode = CNSpecRef⟩.
  • CGSpecSlot : ⟨ValueKind = CG‑Spec, refMode = CGSpecRef⟩.
  • MinimalEvidenceSlot? : ⟨ValueKind = MinimalEvidence, refMode = MinimalEvidenceRef⟩ optional override; otherwise the effective evidence policy is CGSpecSlot.MinimalEvidence.
  • SelectionSlot : ⟨ValueKind = U.Set (selected set), refMode = ByValue⟩.

• OperationAlgebra suite stage = select, per A.19.CHR:4.5; canonical stage op = Select

  • Select(CandidateSetSlot, ComparisonResultSlot, CriteriaSlot, CNSpecSlot, CGSpecSlot, TaskSignatureSlot?, MinimalEvidenceSlot?) → SelectionSlot.

  For an actual n-candidate use, the ComparisonResultSlot argument is the exact set-union of justified tokens from the finite basis members' own CPM output bindings. It carries no application reference, pair, eligibility value, scope, or replay metadata; those remain separate selection-use bindings. A CPM abstain with no output binding contributes no token.

• Selection-use bindings for each actual application (required A.6.1 occurrence arguments; not CHR SlotKinds and not another container kind):

  • one finite by-value comparison-application basis whose every member identifies an exact actual binary CPM Compare application, its exact left/right pair, realized GuardDecision, and its own ComparisonResultSlot binding when one was produced;
  • the finite set of required binary comparisons derived from the candidate universe, CriteriaSlot, and effective selector policy, including pair direction or comparator distinction when it changes the selection condition; every required comparison is discharged by an exact basis member, and every candidate excluded under degrade is named by the bound failure behavior;
  • a trace from every token in the Selector's ComparisonResultSlot argument to the basis member output binding that produced it; no missing pair, empty output, or abstain may be converted into a relation token;
  • one exact U.ClaimScope for the candidate universe and selection use;
  • selected U.ContextSlice members under A.2.6, without copying membership;
  • the same by-value A.19 CharacteristicSpacePredicate basis used by the relevant basis members or an explicit none when no predicate governs the use;
  • effective U.ReferenceScheme and reference plane;
  • explicit selection-evaluation point or interval; and
  • effective selection conditions: the by-value CriteriaSlot, current selector policy and defaults, and explicit failure behavior for degrade.

  The comparison-application basis is an occurrence binding and replay projection, not a new U-kind, SlotKind, relation, result container, batch CPM application, generic context input, model-use-structure field, or replay record. Acceptance and admission predicates remain with their direct declarations. Evidence use retains its own A.2.4 claim scope and relevance window.

• LawSet (minimum): the selection kernel is set-returning and policy-bound

  1. Set‑returning by default: a conformant Select MUST return a declared selected set by default. It MUST NOT silently collapse partial orders or incomparabilities to a single winner; if a singleton outcome is required, it MUST be an explicit criterion (or a declared upstream total order).
  2. No hidden thresholds or constants: a conformant publication MUST NOT smuggle thresholds, weights, dominance rules, or tie‑breakers. Selection‑level commitments MUST be explicit in CriteriaSlot and, where needed, in explicit policy defaults exposed through TaskSignatureSlot. Admissibility and acceptance thresholds are applied only via SelectEligibility using CNSpecSlot.acceptance and the effective evidence policy (MinimalEvidenceSlot? or CGSpecSlot.MinimalEvidence).
  3. No hidden scalarization or token aggregation by assertion: a conformant publication MUST consume ComparisonResultSlot as the exact union of the finite basis members' justified set-valued or partial outputs. Every consumed token MUST be traceable to at least one exact producing CPM application. Scalar summaries or relation tokens inferred from a missing pair, empty output, degrade, or abstain are forbidden; scalar summaries, if produced at all, are report-only unless explicitly promoted by policy outside suite closure.
  4. Evidence gating is explicit: when selection depends on evidence, it MUST cite either MinimalEvidenceSlot or the effective CGSpecSlot.MinimalEvidence policy and evaluate selection with the tri-state predicate. Candidate-level ineligibility handling MUST be explicit in current criteria or upstream results and recorded by the dated selection occurrence; the kernel MUST NOT invent evidence thresholds.
  5. No competing defaults: effective PortfolioMode, dominance regime, and other defaults come from declared policy refs and are bound by the actual application.
  6. No silent boundary change: Select does not silently change candidate universe, comparison-application basis membership, required comparison coverage, any member's pair, eligibility or output binding, selection conditions, A.19 predicate basis, claim scope, selected context slices, reference scheme or plane, or evaluation window. A changed binding is another selection application and may require new binary comparisons.
  7. Guard-output separation: GuardDecision is not a selected-set member. On abstain, no SelectionSlot value is fabricated. A degrade eligibility value permits a reduced set only under the explicitly bound failure behavior and criteria.

• AdmissibilityConditions (tri-state guard; fail-closed on missing admissibility, comparison coverage, token provenance, or evidence)

  • SelectEligibility(CandidateSetSlot, ComparisonResultSlot, CriteriaSlot, CNSpecSlot, CGSpecSlot, TaskSignatureSlot?, MinimalEvidenceSlot?; selection-use bindings) → GuardDecision ∈ {pass|degrade|abstain}.
  • pass requires: (i) every basis member's exact pair lies inside CandidateSetSlot; (ii) the basis covers every binary comparison required by the candidate universe and explicit selection conditions; (iii) every consumed relation token traces to a member's own output binding; (iv) explicit selection conditions and tie-breakers; (v) compatible A.19 predicate basis, claim scope, selected A.2.6 context slices, reference plane, and evaluation window across the basis and selection; (vi) coherent CN-Spec and CG-Spec editions; and (vii) satisfied admission, acceptance, and effective MinimalEvidence predicates under their direct owners.
  • If MinimalEvidenceSlot is absent, SelectEligibility MUST evaluate evidence against CGSpecSlot.MinimalEvidence by explicit rule, and missing or unknown evidence MUST NOT yield pass.
  • A basis member with GuardDecision = degrade may support a reduced set only when a current selector policy names the exact candidate-level failure behavior and the remaining basis still covers the comparisons required for that reduced use. The actual selection application binds that policy and its own realized eligibility value.
  • A missing required comparison, untraceable token, or required basis member with GuardDecision = abstain makes SelectEligibility = abstain; selection does not proceed and no selected-set output is created.

• Applicability:

  • Intended for the CHR select stage after the required finite set of admissible binary comparisons and produces a selected-set value. Selection remains distinct from comparison, acceptance, gate decision, publication, and telemetry.
  • Applicable only when CNSpecSlot, CGSpecSlot, explicit criteria, the effective evidence policy, and a finite comparison-application basis with complete required coverage and token provenance are current for the candidate universe. Missing declarations or coverage fail closed.
  • Inside the CHR suite, A.19.CHR:4.5 alone determines stage ordering and optionality.
  • Every actual selection binds one exact U.ClaimScope, selected A.2.6 U.ContextSlice members, the finite basis of exact binary CPM applications and their pair, eligibility, and output bindings, the derived token union, A.19 predicate basis, effective reference plane, selection conditions, and explicit evaluation point or interval. There is no implicit latest value and no default window inherited from the predicate or comparison label.
  • Cross-reference-scheme or cross-plane use requires an explicit F.9 Bridge. The Bridge does not supply candidate universe, comparison-application basis or coverage, relation tokens, selection conditions, scope, predicate, or time.

• Neighboring bridge relation:

  When candidates or comparison tokens require interpretation across reference schemes or planes, state the F.9 bridge relation separately. Name its exact endpoints, preserved and lost selection meaning, applicable use, CL value, and any R_eff penalty. Adding or changing that bridge does not by itself change the selector declaration.

• Neighboring dated work, operation application, result binding, and evidence relations:

  A dated selection run is A.15.1 U.Work. Its actual A.6.1 Select application binds the candidate set, finite comparison-application basis, required coverage, derived token union, selection-use arguments, policies, and selected-set SelectionSlot. A.2.4 separately governs evidence use with its own claim scope and relevance window; A.10 governs provenance; G.11 governs source or assertion-edition currentness. A durable selected-set episteme, when needed, is governed by C.2.1, and any current entity-identity inception claim by A.15.PROD. No universal work-result, comparison-result, or selection-result relation is presumed. To replay the selection, recover:

  • the candidate set and required binary comparisons; for every basis member, the exact CPM application, pair, realized GuardDecision, and its own output binding or explicit absence; and the trace from every consumed token to its producing member;
  • one U.ClaimScope, selected A.2.6 context slices, A.19 predicate basis, effective reference scheme and plane, and evaluation point or interval shared as required by the selection conditions;
  • CNSpecRef.edition, CGSpecRef.edition, and TaskSignatureRef.edition when TaskSignature is used;
  • the effective MinimalEvidence policy, either the explicit override or CGSpecSlot.MinimalEvidence;
  • the Selector's realized GuardDecision and, for degrade or abstain, the current failure-behavior policy;
  • the candidate-set value and exact derived union bound to the Selector's ComparisonResultSlot argument;
  • the effective criteria and selector-default refs; and
  • the selected-set result and any current F.9 bridge, CL, and ReferencePlane refs.

  These neighboring objects support replay. The finite basis is a binding of the actual selection application, and none of them is selector-declaration content or a generic result container.

#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. 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 dated selection occurrence, 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. Any refinement or extension of SelectorMechanism must follow A.6.1:4.2.1:

   • SlotKind invariance for inherited operations,
   • no new mandatory inputs to inherited Select,
   • added capabilities appear as new operations or as ⊑⁺ extensions.

5. Planned slot filling is preserved. Planned fillers for TaskSignatureRef@edition, CGSpecRef@edition, evidence-policy overrides, and other pins live in SlotFillingsPlanItem rows. Dated selection U.Work binds effective values as occurrence parameters; its result and evidence-provenance relations make their use replayable without mutating the plan.

---

#Archetypal Grounding — informative

#Tell

When comparisons are partial or set-valued, selection must not pretend there is a single best candidate by default. SelectorMechanism makes selection explicit, policy-bound, and replayable: it returns a set unless criteria explicitly demand otherwise.

#Show, U.System example

Scenario. A platform team must pick a set of deployment options for a subsystem under multiple criteria: latency, cost, and regulatory risk. Comparisons are multi-criteria and do not induce a total order.

• CandidateSetSlot = {OptionA, OptionB, OptionC}.

• CriteriaSlot requires Pareto selection over the three unordered pairs {A,B}, {A,C}, and {B,C}, returns all non-dominated admissible candidates, and preserves the full selected set unless an explicit current criterion requires a singleton.

• The finite upstream comparison-application basis covers all three required pairs:

  • exact Compare(OptionA, OptionB, ...) has GuardDecision = pass and its own ComparisonResultSlot binds the justified tokens OptionA ≼ OptionB on latency and OptionB ≼ OptionA on cost;
  • exact Compare(OptionA, OptionC, ...) has GuardDecision = degrade because OptionC lacks the required risk attestation, and its output binding contributes no relation token about OptionC; and
  • exact Compare(OptionB, OptionC, ...) has the same explicit degrade basis and likewise contributes no relation token about OptionC.

  The Selector's ComparisonResultSlot argument is exactly the union of those justified member outputs, so its two tokens both trace to the {A,B} CPM application. No equality, worse-than, or abstain token is fabricated for OptionC.

• MinimalEvidenceSlot? is absent, so evidence is evaluated against CGSpecSlot.MinimalEvidence.

• The actual selection binds the three exact CPM applications and their pair, eligibility, and output bindings; the required-pair coverage and token trace; the deployment-option claim scope and selected regulatory U.ContextSlice members; the same predicate basis or explicit none; the reference plane and evaluation interval; and a degrade policy that permits exclusion of OptionC.

Outcome.

• Under that explicitly bound degrade policy, SelectEligibility returns degrade, excludes OptionC without coercing unknown evidence, and SelectionSlot returns {OptionA, OptionB}.
• If either required comparison involving OptionC instead had GuardDecision = abstain, that basis member would have no output binding, SelectEligibility would return abstain, and no selected-set value would be created. Neither guard value is a member of ComparisonResultSlot or SelectionSlot.
• The dated selection U.Work, actual Select application, finite CPM application basis, evidence-policy and SelectionSlot bindings, and A.10 evidence-provenance path preserve why the reduced-set branch proceeded and why the abstain branch did not.

#Show, U.Episteme example

Scenario. A methods group selects a declared set of analysis methods for a task. Candidates are method family refs. The group wants diversity in the selected set, but does not want diversity metrics to silently become dominance criteria.

• CandidateSetSlot = {Family1, Family2, Family3, Family4}

• The selection conditions declare which binary method-family comparisons are required. A finite basis identifies every relied-on CPM application, its exact pair, eligibility value, and own output binding; the Selector's ComparisonResultSlot argument is their exact justified-token union.

• TaskSignatureSlot is present and is the single policy-default slot or ref:

  • PortfolioMode and dominance regime,
  • budgeting and telemetry hooks (when used).

• CriteriaSlot declares that diversity signals are telemetry unless explicitly promoted by policy.

Outcome.

• SelectionSlot returns a selected set; any archive‑style behavior is a specialization and policy choice, not a hidden kernel default.
• The dated selection U.Work, actual Select application with its TaskSignatureRef.edition and SelectionSlot bindings, and A.10 evidence-provenance path support later explanation without embedding tool tokens into the kernel.

---

#Bias-Annotation — informative

This pattern intentionally biases selection authoring toward explicitness and admissibility.

• Governance bias. Bias toward explicit criteria and policy-reference records rather than implicit constants. Risk: perceived overhead. Mitigation: keep criteria records minimal, and centralize defaults via TaskSignatureSlot when used.
• Architecture bias. Bias toward set‑return semantics and against forced total orders. Risk: consumers may expect a single winner. Mitigation: make single‑winner selection an explicit criterion or a declared comparator outcome, not an implicit kernel behavior.
• Epistemic bias. Bias toward fail‑closed evidence handling and against unknown coercion. Risk: more degrade or abstain early. Mitigation: improve evidence pins and policy clarity; do not relax the kernel.
• Practice bias. Bias against embedding telemetry and publication into selection. Risk: teams want one step to select and report. Mitigation: keep those relations under their governing patterns; retain replay through dated selection work, the actual Select application and result binding, A.10 evidence provenance, and G.11 currentness.
• Didactic bias. Bias toward one governing pattern and “Tell + Cite” elsewhere. Risk: refactoring work. Mitigation: the result is a spec that can be read and taught without scavenger hunts.

---

#Conformance Checklist

---

#Common Anti-Patterns and How to Avoid Them — informative

---

#Consequences

Benefits

• Preserves correctness under partial orders by making set‑valued outcomes first‑class.
• Eliminates a major source of decision drift: hidden thresholds, hidden weights, and silent scalarization.
• Improves replayability and teachability: one governing pattern states selection semantics and guards, while dated work and direct relations preserve each realized use.
• Supports evolvability: new method families and selection styles can be wired without changing the kernel signature.

Costs and trade-offs

• Selected-set results can require explicit downstream handling when a single decision is needed.
• Strict evidence discipline increases early degrade or abstain until criteria and evidence policies are explicit.
• Teams must invest in explicit criteria records instead of relying on implicit conventions.

---

#Rationale

Selection is where many systems accidentally convert admissible but nuanced information into an unjustified scalar decision. Making selection a separate, explicit mechanism boundary achieves two things that matter for engineering management:

1. Technical integrity: it enforces admissibility and evidence discipline at the decision boundary without smuggling heuristics.
2. Organizational clarity: it makes defaults and thresholds discussable, reviewable, and maintainable as explicit policy references.

The set‑returning default is not a preference for large retained sets; it is a correctness safeguard when the order is not total. Single‑winner outcomes remain possible, but only by explicit criteria or declared admissible comparators.

---

#SoTA-Echoing

SoTA vs popular note. This section records alignment to post‑2015 evidence‑backed practice. It is not a mandate to use fashionable methods; method semantics stay in SoTA packs (G.2) and wiring modules, while this pattern fixes the stable selection boundary.

Concrete selector-family SoTA packages are cited through their current Part G pack or claim sheet when one governs the use. They connect through CriteriaSlot and TaskSignatureSlot references while kernel semantics remain unchanged.

#SoTA alignment map (normative)

Notes per row (1–2 sentences; why to adopt, adapt, or reject):

• Selected-set-as-output (QD framing): adopt the decision framing (declared selected set as a first-class result) while keeping concrete QD or retained-set algorithms out of the kernel; they belong in G.2 packs and wiring modules, preserving evolvability.
• Archive retained sets (diversity as result): adapt archive thinking by keeping diversity and illumination signals report‑only unless an explicit CAL policy promotes them to dominance; this prevents silent scalarization and preserves governing-pattern defaults (typically G.5 and CAL).
• Open‑ended environment–method pairing: keep the kernel unchanged; open‑ended pairing is expressed by shaping candidates and criteria (and, when needed, admissible specializations ⊑ and ⊑⁺) with explicit edition pins and transfer and validity rules in planned baseline, not by mutating Select.
• Reject or abstain under uncertainty: adopt the rejection‑option stance as a tri‑state guard with fail‑closed semantics; explicit abstain is preferable to forced choice under missing admissibility and evidence.
• Governing-pattern architecture discipline: adopt governing-pattern + Tell‑and‑Cite to keep the spec teachable and reviewable; this directly reduces drift and “second centers of gravity”.

---

#Currentness and smallest reopen rule

Qualification basis and window. The stable kernel claim is qualified by the current editions of A.6.1/A.6.5 operation and slot discipline, A.19.CPM binary application and output semantics, A.19.CN and G.0 admission and evidence rules, G.5 selector-policy discipline, A.2.6 scope semantics, and the exact current G.2 selector pack or claim sheet cited by an actual use. For that use, the effective qualification window is the intersection of those bound editions' currentness and any validity interval declared by the selector pack, TaskSignature, or policy; post-2015+ is an orientation label, not an indefinite freshness claim.

Reopen the SelectorMechanism kernel only when. Reopen the smallest affected selector rule when a direct governor changes set-return semantics, inherited SlotKinds or specialization constraints, criteria or policy binding, tri-state eligibility, the finite CPM application-basis and token-provenance boundary, selection scope, or the separation of selected set, evidence, provenance, result episteme, and publication, or when qualified evidence contradicts one of those commitments. A new selection algorithm, archive or diversity method, candidate-generation method, tie-breaker, PortfolioMode, rejection calibration, or domain policy that still satisfies those commitments changes its G.2 pack, G.5 policy, CriteriaSlot, TaskSignature, or other direct policy binding rather than this kernel.

Smallest affected locus. A signature, basis, coverage, or output change reopens only the corresponding direct-signature, selection-use-binding, OperationAlgebra, or LawSet passage in A.19.SelectorMechanism:4.1; an admissibility or failure-semantics change reopens the matching AdmissibilityConditions clause. Update only the nearest exercising case in A.19.SelectorMechanism:5.2 or :5.3 and the corresponding CC-A19SelectorMechanism row. Source-family or policy churn that changes no kernel commitment updates the direct pack, policy, or claim sheet and, when its summary is stale, only the affected row or note in this SoTA map.

#Relations

• Builds on

  • A.6.1 and its conformance checklist for mechanism identity, declaration content, applicability, and specialisation-chain discipline.
  • A.19.CHR for suite membership, suite protocol closure, SlotKind lexicon, and threshold and default discipline.
  • G.0 for CG‑Spec admissibility and evidence declarations.
  • A.19 for the exact CharacteristicSpacePredicate basis when one governs selection.
  • A.19.CPM for every exact binary Compare application in the finite basis, its pair, realized eligibility value, and own set-valued output binding.
  • A.2.6 for U.ClaimScope identity and exact U.ContextSlice membership.
  • A.19.CN for CN-Spec governance card used as an explicit input.
  • C.22 for TaskSignature as a policy-reference artifact when used.
  • A.6.5 for slot discipline (SlotIndex as projection; SlotKind invariance).
  • A.15.3 + A.19.CHR:4.7.2 for planned slot fillings.
  • C.27.TA for the explicit selection-evaluation point or interval.
  • A.2.4, A.10, and G.11 for evidence-use scope, provenance, and currentness, separately from selection scope and output.

• Used by

  • A.19.CHR as the canonical select stage in CHR pipelines.
  • G.5 as the primary conformance and specialization context for selector-based method dispatch and PortfolioMode policies.
  • E.18 when selector instances are used as transformation-flow structure nodes; planned refs remain SlotFillingsPlanItem values, while dated selection work binds effective refs and cites its direct result and evidence-provenance relations.

• Coordinates with

  • CPM and other admissible comparison stages as producers of the exact result bindings whose justified-token union fills the Selector's ComparisonResultSlot argument.
  • ULSAM and other admissible aggregation stages that must remain explicit rather than hidden inside selection.
  • E.20 governing-pattern discipline and F.18 naming or alias handling when a source term needs a bridge.

#A.19.SelectorMechanism:End

---

Last Updated: 2026-08-04 — upstream FPF commit 7ba40a95 (github.com/ailev/FPF)