A.19.SelectorMechanism - Unified Selection Kernel, SelectorMechanism

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 declaration 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, operation-local argument/result declarations, 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.

A.19.SelectorMechanism:0 - At a glance — didactic, informative

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

A.19.SelectorMechanism:1 - 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.

A.19.SelectorMechanism:2 - 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.

A.19.SelectorMechanism:3 - 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 use and gate/guard separation. A.15.2 carries the intended baseline; A.15.3 typed filling is conditional on independently declared positions. 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.

A.19.SelectorMechanism:4 - 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 explicitly declared specializations subject to the local restrictions in CC‑A19SelectorMechanism‑10. A claimed refinement, conservative extension or equivalence uses its own comparison test in A.6.1 §4.8; the labels ⊑ and ⊑⁺ do not supply that test.

A.19.SelectorMechanism:4.1 - Operation declaration — normative core

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

• Declaration identity: SelectorMechanism.IntensionRef cites this exact A.6.1 U.Mechanism episteme. The CHR select stage resolves to its local Select operation. A changed argument, selection law or guard requires explicit selection of the changed declaration; another realizer of the same declaration changes no suite member.

• 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.8 (exact declaration comparisons), A.6.1 (operation-local declarations and bindings), 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>.
  • Results are operation-local: the selected candidate set and the separate guard judgment.
  • Input qualification: 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. Operation-local argument and result declarations

Each argument below is declared separately for Select and SelectEligibility, except the realized eligibility argument of Select itself. ByValue carries the stated value; a named Ref or ByRef resolves one exact value and edition. Cardinality is per application. The guard can assess an incomplete proposal with 0..1 of each required argument; missing inputs have no binding and prevent pass.

For each argument row, its bindingPredicate holds when that application actually uses the resolved value for its stated purpose: candidates supply the selection universe, criteria/policy supply the choice rule, specifications/evidence requirements govern admission, and the basis, coverage and provenance supply the comparisons on which the choice relies. Scope, slices, predicate, scheme, plane and time bind only when they qualify that application. A nearby policy or copied comparison record does not supply those bindings.

The SelectionSlot bindingPredicate holds when that Select application returns the candidate subset determined by its bound criteria/policy from the justified comparison basis, under its declared pass/degrade conditions. The GuardDecision bindingPredicate holds when that SelectEligibility application returns its assessed judgment. An equal selected set or guard value stored elsewhere is insufficient. A.6.1 governs each binding’s identity and continuous extent within the application; result binding begins at its actual return.

SlotIndex (derived projection). Project the designators, ValueKinds, designation and cardinalities above. Historical Slot names support CHR lookup. The other local names declare operation arguments, not new U-kinds or CHR SlotKinds; A.6.5 relation SlotSpecs supply none of their semantics.

OperationAlgebra. The select stage resolves to Select with the declared candidate/token, criteria/specification and selection-use arguments, returning SelectionSlot. SelectEligibility evaluates that proposal under the guard below. ComparisonResultSlot contains only the exact token union; application references, coverage, scope and provenance remain separate arguments. A CPM abstain with no output contributes no token. Every required comparison must be discharged by an exact basis member; degraded selection names excluded candidates under the bound failure behavior and retains complete coverage for its reduced use.

ApplicationPredicate. Select obtains when a selection act actually applies the bound criteria and effective policy to the candidate universe using the bound justified CPM outputs and use restrictions, with pass or an explicitly permitted degrade outcome under SelectEligibility. It returns the resulting set; on abstain no Select act proceeds. SelectEligibility obtains when an evaluation actually checks that proposal’s coverage, provenance, admission and evidence conditions and returns the corresponding judgment. A valid proposal or an equal saved selected set does not establish that selection act.

ApplicationIdentityRule. One application is one selection invocation or guard-evaluation invocation at its calculation locus, from taking up its declared arguments until return or termination. References to that same episode reidentify it. Two independently begun invocations remain distinct even when the complete CPM basis, criteria, policies, qualification window and results are equal. Law 6 additionally makes a changed binding a new selection application; a completed prior application cannot acquire the replacement basis or result.

ApplicationExtentRule. Select extends from actual use of its candidates, CPM basis and choice rules through selected-set return or termination; SelectEligibility extends from proposal assessment through judgment or termination. An unfinished invocation has an open extent and no unreturned result binding. The selection-evaluation window qualifies the use and does not determine these actual calculation intervals. A trace designates an established episode; ordinary set-selection mathematics asserts no dated U.Work.

For example, use the admitted incomparable supplier pair from A.19.CPM §4.1 and the declared criterion “retain every nondominated candidate.” With complete required coverage and the exact CPM token binding, two separately performed selections can each return {A,B}. Their Select occurrences and result bindings differ even when they reuse the same CPM producer application. A copied {A,B} without a corresponding selection return establishes no fresh binding. A copied comparison token whose producing CPM return is unestablished fails tokenProvenance and causes abstain; it cannot enter the basis merely because its text matches.

• 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 bound by the actual selection application; 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.
  • A selection across reference schemes or planes follows the relations the case actually needs. When it relates two exact F.17 SchemeSenseCell values from different semantic contexts, test the F.9 BridgePredicateProfile and cite the Bridge only when its direct predicate obtains; state suitability for the named selection use in a separate C.2.1 claim. If that predicate is false or unresolved and the semantic crossing is required by the selection conditions, SelectEligibility cannot be pass; follow the already declared explicit degrade policy when applicable, otherwise abstain. When the selection crosses exact ReferencePlanes, cite the applicable plane relation and policy. If both facts are current, state both under their own predicates. A cell or plane difference alone establishes neither relation, and one branch never fabricates the other. Neither relation supplies candidate universe, comparison-application basis or coverage, relation tokens, selection conditions, scope, predicate, or time.

• Neighboring semantic-Bridge, bounded-use, and reference-plane relations:

  When candidates or comparison tokens require interpretation across different semantic contexts, resolve the two exact F.17 SchemeSenseCell endpoints and test one F.9 BridgePredicateProfile. For an obtaining Bridge, state its exact endpoints and profile separately. State suitability for the named selection use in a C.2.1 assertion whose EntityOfConcern is that Bridge and whose ClaimGraph designates <u,d,r,t> and polarity. Include CL or an observed-loss note only when the receiving use consumes it; permitted loss remains t in the bounded-use claim. For a ReferencePlane crossing, cite the applicable plane relation and policy separately. Open A.10 only when bounded reliance is current and B.3 only when an actual named assurance claim is current. If that assurance argument consumes a locally declared R_eff calculation, cite its applicable domain model and calculation; neither the Bridge nor CL creates a penalty. Adding or changing any of these neighboring objects does not by itself change the selector declaration.

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

  The identified Select application binds the candidate set, finite comparison basis, required coverage, token union, selection-use arguments, policies and returned SelectionSlot. If the account also asserts dated selection U.Work, A.15.1 independently admits that performance; neither its identity nor extent is automatically that of one Select application. When the account asserts them or the receiving use consumes them, A.2.4 governs evidence use with its own claim scope and relevance window, A.10 governs reliance and provenance, and 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; any current obtaining F.9 Bridge and its separate C.2.1 bounded-use claim; any optional CL or observed-loss note actually consumed; and any applicable ReferencePlane relation and policy. Recover A.10 reliance or B.3 assurance only when the selection use actually consumes it.

  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.

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

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

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

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

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

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

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

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

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

A.19.SelectorMechanism:5 - Archetypal Grounding — informative

A.19.SelectorMechanism:5.1 - 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.

A.19.SelectorMechanism:5.2 - 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: OptionB is strictly better than OptionA on latency, while OptionA is strictly better than OptionB on cost under the declared comparator. Its ComparisonResultSlot records those strict opposite wins, so neither dominates the other;
  • 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.

A.19.SelectorMechanism:5.3 - 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.

A.19.SelectorMechanism:6 - 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.

A.19.SelectorMechanism:7 - Conformance Checklist

A.19.SelectorMechanism:8 - Common Anti-Patterns and How to Avoid Them — informative

A.19.SelectorMechanism:9 - 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.

A.19.SelectorMechanism:10 - 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.

A.19.SelectorMechanism:11 - 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.

A.19.SelectorMechanism:11.1 - 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”.

A.19.SelectorMechanism:11.2 - Currentness and smallest reopen rule

Qualification basis and window. The stable kernel claim is qualified by the current editions of A.6.1 operation declarations and actual binding rules, 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.