#Unified Selection Kernel (SelectorMechanism)

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

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

Semantic owner note (Phase‑3 canonicalization): this pattern is the designated single semantic owner of the canonical U.Mechanism.Intension for SelectorMechanism.IntensionRef (CHR suite stage select). This matches the “single‑owner route map” discipline (E.20:4.2): mechanism‑intension semantics live in an explicitly designated mechanism‑owner pattern. A.6.1 remains the owner of the template of U.Mechanism.Intension and the U.MechAuthoring discipline; this pattern owns the SelectorMechanism‑specific slots/ops/laws/admissibility/applicability/transport/plane/time/audit obligations for that template (single‑owner at the instance‑semantics level).

ID continuity note. When migrating away from any legacy “card location”, preserve public anchors: keep the legacy section heading/ID as a Tell + Cite stub (or dock aliases via F.18) rather than deleting or silently renaming it.

Canonicalization hook (ID‑continuity‑safe): any other appearances of the SelectorMechanism intension content (e.g., a legacy grounding stub in A.6.1 or suite prose in A.19.CHR) SHALL be reduced to a Tell + Cite stub pointing to A.19.SelectorMechanism:4.1, while preserving the original section headings and their public PatternId:SectionPath IDs for continuity (alias‑dock legacy tokens rather than deleting them). Such stubs MUST NOT restate SlotIndex / OperationAlgebra / LawSet / Admissibility / Audit content (no “second center of gravity” via near‑duplicate prose).

• ID‑continuity‑safe: if content is moved from an earlier location, preserve the earlier heading and its IDs as a stub that cites A.19.SelectorMechanism:4.1.
• Alias‑dock, don’t break: if any legacy tokens exist (e.g., a historical UNSELM name token), dock them via F.18 + E.10 rules; do not mint a competing head.
• No shadow semantics: derived summaries MAY be informative, but MUST NOT restate SlotIndex / OperationAlgebra / LawSet / Admissibility / Audit; they may only summarise and cite.

• What it is: a universal set‑returning selection kernel: it takes candidates, lawful comparison outcomes, and explicit criteria, and returns a portfolio 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.
• 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 / suite_protocols; suite membership is a set in A.19.CHR:4.2).
• Inputs (conceptual): CandidateSetSlot + ComparisonResultSlot (lawful relation/poset tokens, typically produced by CPM) + CriteriaSlot + CNSpecSlot + CGSpecSlot + ContextSlot (+ TaskSignatureSlot?, + MinimalEvidenceSlot? override).
• Output (conceptual): SelectionSlot = portfolio 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‑lawful inputs.
• P2W seam: concrete edition/policy pin bindings (e.g., TaskSignatureRef@edition(…), CGSpecRef@edition(…), evidence overrides) are chosen in planned baseline artefacts (A.15.3 + A.19.CHR:4.7.2); executions only record effective refs/pins in Audit.
• TGA use: when used as a node type in E.18 (E.TGA), selector instances are chosen in planned baseline artefacts (P2W); this pattern owns the intension that those instances cite.
• Failure mode: tri‑state guard (pass|degrade|abstain); missing/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 portfolio set whose “single winner” behavior must be explicit.

#Keywords

• selection kernel
• set-returning selection
• portfolio 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, lawful comparison outcomes, and explicit criteria, and returns a portfolio 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.
• 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 / suite_protocols; suite membership is a set in A.19.CHR:4.2).
• Inputs (conceptual): CandidateSetSlot + ComparisonResultSlot (lawful relation/poset tokens, typically produced by CPM) + CriteriaSlot + CNSpecSlot + CGSpecSlot + ContextSlot (+ TaskSignatureSlot?, + MinimalEvidenceSlot? override).
• Output (conceptual): SelectionSlot = portfolio 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‑lawful inputs.
• P2W seam: concrete edition/policy pin bindings (e.g., TaskSignatureRef@edition(…), CGSpecRef@edition(…), evidence overrides) are chosen in planned baseline artefacts (A.15.3 + A.19.CHR:4.7.2); executions only record effective refs/pins in Audit.
• TGA use: when used as a node type in E.18 (E.TGA), selector instances are chosen in planned baseline artefacts (P2W); this pattern owns the intension that those instances cite.
• Failure mode: tri‑state guard (pass|degrade|abstain); missing/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 portfolio 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 lawful comparison; optional stages remain explicitly optional per suite_protocols). The kernel’s role is concept‑level and contract‑bound:

• consume lawful comparison outcomes without collapsing them into a hidden scalar,
• apply explicit criteria and policy routing, and
• return a set/portfolio 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 portfolio modes” 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 routing to 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 lawful 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 routing must be visible without introducing tool‑level governance.

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

7. P2W separation and gate/guard separation. Planned binding of fillers and pins lives in WorkPlanning (P2W). 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 portfolio mode, dominance regime, archive policies), they must be cited from their declared single 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 surface (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 legality or evidence,
• an audit minimum that records effective editions and policy routing.

Method semantics and SoTA algorithm families do not live inside the kernel: they connect via G.2 SoTA packs and wiring modules, and via lawful specializations ⊑/⊑⁺ that obey the ladder 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 owned by A.6.1. It defines only the mechanism’s semantic surface (slots/ops/laws/guards/audit). It does not bind project‑specific pins (P2W), and it does not emit GateDecision/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 artefacts 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 (multi-level specialisation ladders), A.6.5 (slot discipline; SlotIndex as projection), A.19.CN (CN‑Spec governance card), C.22 (TaskSignature as a policy routing surface when used), G.5 (selector conformance and default routing), G.0 (CG‑Spec legality and evidence gates), A.19.CHR:4.2.1 (CHR SlotKind Lexicon).

• SubjectBlock:

  • SubjectKind: Selection.
  • BaseType: U.Set (candidates) + U.RelationTokenSet (lawful comparison outcomes).
  • SliceSet: U.ContextSliceSet.
  • ExtentRule: selection ranges over admitted candidates in the active context slice, constrained by explicit criteria/policies and by lawful 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/poset tokens), refMode = ByValue⟩.
  • CriteriaSlot : ⟨ValueKind = U.Set (selection criteria / clauses, incl. explicit tie‑breakers; **acceptance thresholds are not criteria** and remain owned by the cited acceptance surfaces and applied only via SelectEligibility), refMode = ByValue⟩.
  • TaskSignatureSlot? : ⟨ValueKind = TaskSignature, refMode = TaskSignatureRef⟩ optional; when present, SHOULD be the single routing surface for selector defaults (e.g., portfolio mode / dominance regime), but it does not replace CNSpecSlot / CGSpecSlot contract surfaces.
  • 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 (portfolio), 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 set/portfolio 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/constants: a conformant publication MUST NOT smuggle thresholds, weights, dominance rules, or tie‑breakers. Selection‑level commitments MUST be explicit in CriteriaSlot and/or in explicit policy routing surfaced by TaskSignatureSlot. Admissibility/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/partial when it is set‑valued/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 route the operation through tri‑state guards (no unknown coercion). Any candidate‑level ineligibility handling MUST be explicit (criteria and/or upstream outputs) and auditable (no silent dropping); the kernel MUST NOT invent new evidence thresholds.
  5. No competing defaults: portfolio/dominance defaults (when relevant) MUST be sourced from their declared single owners (typically via TaskSignatureSlot routing and/or the selector conformance/default surfaces in G.5), and MUST NOT be re‑declared inside the kernel.

• AdmissibilityConditions (tri‑state guard; fail‑closed on missing legality 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/or TaskSignatureSlot), (iii) admissibility/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/CG-Spec pairings).
  • If MinimalEvidenceSlot is absent, SelectEligibility MUST evaluate evidence against CGSpecSlot.MinimalEvidence by explicit rule, and missing/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 “sandbox/probe‑only”; abstain is used when selection cannot proceed lawfully under the declared criteria/policies.

• Applicability:

  • Intended as the last stage of CHR selection after lawful comparison, producing a portfolio‑valued result.
  • Cross‑context selection is allowed only via explicit Transport (Bridge+CL/ReferencePlane) and cannot bypass CG‑Spec legality.

• Transport: declarative‑only: no embedded CL/Φ/Ψ tables and no new transport edges; crossings are via cited Bridge+CL/ReferencePlane surfaces; penalties route 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 route 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 surface (e.g., criteria artefact ids when criteria are reference‑backed; TaskSignatureRef when used).
  • SHOULD record: the realized routing‑relevant selector defaults (e.g., portfolio mode / dominance regime) when they are not fully determined by a referenced TaskSignatureRef or an explicit CAL policy surface; the point is auditability, not re‑declaring defaults.
  • SHOULD record: any Bridge/CL/ReferencePlane ids when Transport was invoked.

#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 a lawful scoring and/or comparator choice, not invented inside selection.

2. Threshold discipline (acceptance ≠ selection). Acceptance/admission thresholds are not selection criteria: they live in AcceptanceClauses / TaskSignature / GateProfile surfaces per A.19.CHR:4.3.5 and are applied only via SelectEligibility. Selection‑level tie‑breakers and portfolio constraints MAY exist, but MUST be explicit and auditable (typically as criteria artefacts or explicit policy routing), 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 routed via established publication surfaces (e.g., G.10 and/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. P2W seam is preserved. Planned bindings for TaskSignatureRef@edition, CGSpecRef@edition, evidence policy overrides, and other pins live in WorkPlanning (P2W). 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 route rather than coercing unknowns.
• SelectionSlot returns {OptionA, OptionB} as a portfolio set, rather than forcing a single winner.
• Audit records CGSpecRef.edition, the effective evidence policy, and the stable identity of the selected portfolio.

#Show, U.Episteme example

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

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

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

• TaskSignatureSlot is present and is the single routing surface for policy defaults:

  • portfolio mode and dominance regime,
  • budgeting/telemetry hooks (when used).

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

Outcome.

• SelectionSlot returns a portfolio 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 legality.

• Governance bias. Bias toward explicit criteria and policy routing surfaces rather than implicit constants. Risk: perceived overhead. Mitigation: keep criteria artifacts 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/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 routing patterns and record only minimal audit pins here.
• Didactic bias. Bias toward one semantic owner 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 owner location for selection semantics and its guards.
• Supports evolvability: new method families and selection styles can be wired without changing the kernel signature.

Costs / trade-offs

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

---

#Rationale

Selection is where many systems accidentally convert lawful 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 legality 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 surfaces.

The set‑returning default is not a “preference for portfolios”; it is a correctness safeguard when the order is not total. Single‑winner outcomes remain possible, but only by explicit criteria or declared lawful 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.

Pack note, Phase‑3: this pattern does not currently cite a SelectorMechanism‑specific G.2 pack or ClaimSheet. If and when such packs are introduced, they should connect via CriteriaSlot and TaskSignatureSlot routing, keeping kernel semantics unchanged.

#SoTA alignment map (normative)

Notes per row (1–2 sentences; why adopt/adapt/reject):

• Portfolio-as-output (QD framing): adopt the decision framing (portfolio as a first-class result) while keeping concrete QD/portfolio algorithms out of the kernel; they belong in G.2 packs and wiring modules, preserving evolvability.
• Archive portfolios (diversity as result): adapt archive thinking by keeping diversity/illumination signals report‑only unless an explicit CAL/policy promotes them to dominance; this prevents silent scalarization and preserves single‑owner defaults (typically G.5/CAL).
• Open‑ended environment–method pairing: keep the kernel unchanged; open‑ended pairing is expressed by shaping candidates/criteria (and, when needed, lawful specializations ⊑/⊑⁺) with explicit edition pins and transfer/validity rules in planned baseline, not by mutating Select.
• Reject/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 legality/evidence.
• Single‑owner architecture discipline: adopt single‑owner + 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 specialization ladder discipline.
  • A.19.CHR for suite membership, suite protocol closure, SlotKind lexicon, and threshold and default discipline.
  • G.0 for CG‑Spec legality and evidence surfaces.
  • A.19.CN for CN‑Spec governance card used as an explicit input.
  • C.22 for TaskSignature as a policy routing surface when used.
  • A.6.5 for slot discipline (SlotIndex as projection; SlotKind invariance).
  • A.15.3 + A.19.CHR:4.7.2 for the P2W planned baseline seam for edition/policy pin bindings (cited as seam, 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 portfolio policies.
  • E.18 (E.TGA) when selector instances are used as transduction graph nodes; planned pins live in P2W, effective pins surface via Audit.

• Coordinates with

  • CPM and other lawful comparison stages as producers of ComparisonResultSlot.
  • ULSAM and other lawful aggregation stages that must remain explicit rather than hidden inside selection.
  • E.20 single-owner discipline and F.18 alias docking for Phase‑3 canonicalization and ID continuity.

#A.19.SelectorMechanism:End