#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 template of U.Mechanism.Intension and the U.MechAuthoring discipline; this pattern governs the SelectorMechanism-specific slots, operations, laws, admissibility, applicability, transport, plane, time, and audit obligations for that template. Other descriptions of SelectorMechanism cite A.19.SelectorMechanism:4.1 rather than restating SlotIndex, OperationAlgebra, LawSet, Admissibility, Applicability, Transport, PlaneRegime, time policy, or Audit content.

• 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 a selected set, specialist escalation, abstain, or other explicit escalation result whose singleton behavior, ordering, and policy basis are explicit.
• First output: write or cite one SelectionSlot with candidate set, comparison-result refs, criteria, admissibility frame, context, and selected-set result.
• 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): CandidateSetSlot + ComparisonResultSlot (admissible relation or poset tokens, typically produced by CPM) + CriteriaSlot + CNSpecSlot + CGSpecSlot + ContextSlot (+ TaskSignatureSlot?, + MinimalEvidenceSlot? override).
• Output (conceptual): SelectionSlot = selected set (a singleton is allowed only when explicitly demanded by criteria or by an explicitly declared upstream total order).
• 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 (e.g., TaskSignatureRef@edition(…), CGSpecRef@edition(…), evidence overrides) are planned fillers under the A.15.3 planned slot-filling ontic and are carried by SlotFillingsPlanItem rows (A.15.3 + A.19.CHR:4.7.2); executions only record effective refs and pins in Audit.
• 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 a selected set, specialist escalation, abstain, or other explicit escalation result whose singleton behavior, ordering, and policy basis are explicit.
• First output: write or cite one SelectionSlot with candidate set, comparison-result refs, criteria, admissibility frame, context, and selected-set result.
• 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): CandidateSetSlot + ComparisonResultSlot (admissible relation or poset tokens, typically produced by CPM) + CriteriaSlot + CNSpecSlot + CGSpecSlot + ContextSlot (+ TaskSignatureSlot?, + MinimalEvidenceSlot? override).
• Output (conceptual): SelectionSlot = selected set (a singleton is allowed only when explicitly demanded by criteria or by an explicitly declared upstream total order).
• 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 (e.g., TaskSignatureRef@edition(…), CGSpecRef@edition(…), evidence overrides) are planned fillers under the A.15.3 planned slot-filling ontic and are carried by SlotFillingsPlanItem rows (A.15.3 + A.19.CHR:4.7.2); executions only record effective refs and pins in Audit.
• 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 auditable.

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, making the CHR pipeline opaque and hard to reason about.

---

#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. Auditability vs conceptual minimalism. FPF stays conceptual. Audit obligations must be minimal yet decisive: editions and effective policy references must be visible without introducing tool‑level governance.

6. Evolvability vs didactic usability. The kernel must be stable enough to support SoTA wiring and specialisation chains, but also teachable: one place to learn the boundary, laws, guard behavior, and audit minimum.

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, archive policies), they must be cited from their declared defaults sources, not replicated or re-declared inside the kernel (A.19.CHR:4.3.5).

---

#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,
• an audit minimum that records effective editions and policy references.

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).

• Scope note: this intension is an instance authored to the U.Mechanism.Intension shape governed by A.6.1. It defines only the mechanism’s semantic boundary: slots, operations, laws, guards, and audit. It does not bind project-specific planned pins, and it does not emit GateDecision or GateLog; it emits Audit pins and a tri-state guard only.

• 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 (canonical target for the suite member named in A.19.CHR:4.2).

• 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).

• SubjectBlock:

  • SubjectKind: Selection.
  • GovernedValueDomain: candidate set plus admissible comparison-outcome relation token set.
  • SliceSet: U.ContextSliceSet.
  • ExtentRule: selection ranges over admitted candidates in the active context slice, constrained by explicit criteria and policies and by admissible comparison outcomes.
  • ResultKind?: U.Set.

• 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⟩.
  • ContextSlot : ⟨ValueKind = U.BoundedContext, refMode = U.BoundedContextRef⟩.
  • 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, ContextSlot, TaskSignatureSlot?, MinimalEvidenceSlot?) → SelectionSlot.

• 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: a conformant publication MUST consume ComparisonResultSlot as set‑valued or partial when it is set‑valued or partial. 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 (override) or the effective policy CGSpecSlot.MinimalEvidence, and it MUST evaluate the selection with tri‑state guards (no unknown coercion). Any candidate‑level ineligibility handling MUST be explicit (criteria and upstream outputs when used) and auditable (no silent dropping); the kernel MUST NOT invent new evidence thresholds.
  5. No competing defaults: PortfolioMode and dominance defaults (when relevant) MUST be sourced from their declared governing patterns (typically through TaskSignatureSlot and the selector conformance or default rules in G.5 when used), and MUST NOT be re‑declared inside the kernel.

• AdmissibilityConditions (tri‑state guard; fail‑closed on missing admissibility or evidence)

  • SelectEligibility(CandidateSetSlot, ComparisonResultSlot, CriteriaSlot, CNSpecSlot, CGSpecSlot, ContextSlot, TaskSignatureSlot?, MinimalEvidenceSlot?) → GuardDecision ∈ {pass|degrade|abstain}.
  • pass requires at minimum: (i) ComparisonResultSlot is compatible with CandidateSetSlot (same candidate universe), (ii) all selection criteria and any tie‑breakers are explicit (via CriteriaSlot and TaskSignatureSlot when used), (iii) admissibility and acceptance gates (CNSpecSlot.acceptance, evidence) do not fail, and (iv) CNSpecSlot and CGSpecSlot are coherent for the comparison tokens being consumed (no mixed CN-Spec and CG-Spec pairings).
  • If MinimalEvidenceSlot is absent, SelectEligibility MUST evaluate evidence against CGSpecSlot.MinimalEvidence by explicit rule, and missing or unknown evidence MUST NOT yield pass.
  • degrade is permitted only when an explicit, auditable failure behavior exists (policy‑bound), e.g., “exclude ineligible candidates” or “sandboxed probe only”; abstain is used when selection cannot proceed admissibly under the declared criteria and policies.

• Applicability:

  • Intended as the last stage of CHR selection after admissible comparison, producing a selected-set-valued result.
  • Cross‑context selection is allowed only via explicit Transport (Bridge, CL, and ReferencePlane) and cannot bypass CG‑Spec admissibility.

• Transport: declarative‑only: no embedded CL, Φ, or Ψ tables and no new transport edges; crossings are via cited Bridge, CL, and ReferencePlane declarations; penalties are assigned to R_eff only.

• Γ_timePolicy: point by default, no implicit latest.

• PlaneRegime: declarative‑only; does not introduce plane crossings. If selection spans planes, it MUST cite the applicable ReferencePlane and CL^plane policy; penalties are assigned to R_eff only.

• Audit:

  • Must record: CNSpecRef.edition, CGSpecRef.edition.
  • If TaskSignatureSlot? is present, must record TaskSignatureRef.edition.
  • If MinimalEvidenceSlot? is present, must record MinimalEvidenceRef; otherwise must cite CGSpecSlot.MinimalEvidence as the effective evidence policy.
  • SHOULD record: the realized GuardDecision (pass|degrade|abstain) and, when non‑pass, the policy‑bound failure behavior reference that justified it.
  • SHOULD record: a stable identity for CandidateSetSlot and ComparisonResultSlot or a citable upstream Audit anchor that already fixes these identities; the goal is traceability without duplicating upstream semantics.
  • MUST record: a stable identity for SelectionSlot.
  • SHOULD record: a stable description (or citable reference) for the effective selection criteria record or reference (e.g., criteria record ids when criteria are reference‑backed; TaskSignatureRef when used).
  • SHOULD record: the realized policy-relevant selector defaults (e.g., PortfolioMode or dominance regime) when they are not fully determined by a referenced TaskSignatureRef or an explicit selector policy reference; the point is auditability, not re‑declaring defaults.
  • SHOULD record: any Bridge, CL, and ReferencePlane ids when Transport was used.

#Boundary and layering rules

1. Selection consumes upstream CHR products, it does not invent them. ComparisonResultSlot is an input: the kernel MUST NOT perform normalization (UNM), indicatorization (UINDM), scoring (USCM), folding (ULSAM), or comparison (CPM) 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 ≠ selection). Acceptance and admission thresholds are not selection criteria: they live in AcceptanceClauses, TaskSignature, or GateProfile records per A.19.CHR:4.3.5 and are applied only via SelectEligibility. Selection‑level tie‑breakers, PortfolioMode, or selected-set constraints MAY exist, but MUST be explicit and auditable (typically as criteria records or explicit policy references), never 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. Execution visibility is via Audit, not by mutating plan objects at run time.

---

#Archetypal Grounding — informative

#Tell

When comparisons are partial or set‑valued, selection must not pretend there is a single “best” by default. SelectorMechanism makes selection explicit, policy‑bound, and auditable: 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}

• ComparisonResultSlot includes tokens such as:

  • OptionA ≼ OptionB on latency,
  • OptionB ≼ OptionA on cost,
  • OptionC incomparable with both on risk evidence (missing attestations).

• CriteriaSlot contains explicit clauses:

  • “return all non‑dominated candidates under ParetoOnly,”
  • “candidates missing required evidence must not pass.”

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

Outcome.

• SelectEligibility returns degrade (or abstain, depending on the declared failure behavior) because OptionC fails evidence gating; selection excludes OptionC under an explicit policy relation rather than coercing unknowns.
• SelectionSlot returns {OptionA, OptionB} as a selected set, rather than forcing a single winner.
• Audit records CGSpecRef.edition, the effective evidence policy, and the stable identity of the selected set result.

#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}

• ComparisonResultSlot is produced by admissible comparison on declared indicators and evidence gates.

• 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.
• Audit records TaskSignatureRef.edition, enabling reproducibility and post‑hoc 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 publishing into selection. Risk: teams want a one‑stop “select and report.” Mitigation: keep reporting in post‑suite publication or reporting patterns and record only minimal audit pins here.
• 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 auditability and teachability: one governing pattern location for selection semantics and its guards.
• 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”.

---

#Relations

• Builds on

  • A.6.1 and CC‑UM.* for the mechanism intension shape 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.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 the planned slot-filling ontic and SlotFillingsPlanItem rows carrying edition and policy pins (cited as planned slot fillings, not duplicated in Intension).

• 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 pins are planned fillers in SlotFillingsPlanItem rows, and effective pins appear in Audit.

• Coordinates with

  • CPM and other admissible comparison stages as producers of ComparisonResultSlot.
  • 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-06-21 — this section last modified in upstream FPF commit 9b6d71cf (github.com/ailev/FPF)