G.5 - Method-Family Registry, Dispatch and Selected-Set Result Declaration

Type: General (G) Status: Stable Normativity: Normative

Intent. Help an engineer use a dispatcher and registry for rival method families and state selector-facing set outcomes. The outcome distinction covers retained alternatives and members jointly included for one named use without collapsing plurality into one hidden scalar winner.

Primary working reader and object. An engineer or framework author who already has a set of identified candidates or members and must state the selector-facing result—outcome kind, members, ordering, named use when required, and basis pins—for a named downstream use, without also claiming a choice, Work, or publication occurrence that has not happened.

G.5:0 - Use this when

When loop-engineering work retains several already identified candidates for downstream use—for example, loop candidates, harness variants, method families, workflow-store entries, or DPF framework candidates—or when several already identified values are all included for one named use, use G.5 only when the live claim is the selector-facing declaration of that set result. The declared result states the outcome kind, members or keyed member entries, ordering status, named use when applicable, and basis pins. It does not prove that any member improved, that work occurred, that a local choice has been made, or that the result is available to an audience.

Use Shortlist or RankedShortlist for alternatives retained for later choice. Use JointUseSet only when every named member is included for one bounded use. This joint-use branch consumes exact member identities under their own rules; it does not require MethodRef, a method-family registry row, or Method classification for framework editions or other non-Method values.

When an earlier choice or other current inclusion basis has already fixed the exact members, use G.5-6 DeclareSetResult with those member refs, the named use, inclusion conditions, ordering, and sufficient basis pins. This branch declares selector-facing result content without running method-family registration or G.5-3 Select; non-Method members never enter those method-family operations.

For ordinary method-family dispatch, open G.5 when two or more already admitted Methods are live under grounded selector rows for the same declared task and the current question is the selector-facing set result: which candidates remain admissible, whether the emitted result may truthfully order them, or whether it must be a shortlist, narrowed handoff, abstain, or escalation. If the live question is still one local choice among available options, first constitute the exact C.11 choice assertion under its predicate. Reuse already grounded method-family rows when they exist; do not rebuild a registry on every run. Create a new reusable row only when the grouping itself must recur, carry family-level policy, be versioned, or be published. Crossing, evidence/reliance, assurance, stable public identity, and actual publication are conditional branches, not an entry fee.

For Method dispatch, resolve each exact A.3.1 Method and the row’s independent grouping basis under S1 (§4.2). An unresolved member or grouping basis blocks that row. If the claim concerns actual selection, use S3’s application and Work-admission conditions; a result declaration alone supplies no such occurrence. S5 governs any separately needed result episteme, public identity and publication claim.

Typical selector situations include:

• Methods or generators from several families are admissible for the same declared task family or work target
• you need one selector to return a Shortlist, RankedShortlist, JointUseSet, one SpecialistHandoff, one other narrowed handoff plan, or one abstain outcome without pretending that there is always one scalar winner or that all set results are alternatives
• the declared result must carry enough basis pins for its named downstream use—for example, later comparison, handoff, or escalation—without changing its declared outcome kind or any applicable public selected-set label

G.5:0.1 - What goes wrong if missed

• rival families are compared under silent comparator drift, hidden baseline changes, or unspoken crossing costs
• the selector hides one dogmatic winner even when only a partial order is admissible
• selector-facing result content stays hidden inside C.11, C.19, or C.24, so the G.5 result no longer states which upstream choice, pool treatment, or enactment result it consumes and what set result it declares
• exploration, open-ended, or specialization pressure leaks in as one architecture convenience rather than one explicit policy-bound choice

G.5:0.2 - What this buys

• one registry that keeps rival method families disjoint but dispatchable
• one selector result form that uses the closed SelectorOutcomeKind rules in §4.4b and the closed SetResultFamily set when the result is set-shaped
• one trace addressable by DRR and SCR records with explicit basis pins instead of one hidden selector rationale
• one explicit selected-set result that states the outcome kind, applicable public label, retained members or keyed joint-use entries, ordering, named use where required, handoff content, and basis pins instead of leaving them implicit upstream

Registry and dispatch remain the primary selector question here; the explicit selected-set result closes that question without replacing registry or dispatch.

G.5:0.3 - First-minute questions

• Which exact members and grouping or inclusion basis are already established?
• Are they alternatives for later choice or members all included for one named use?
• Does the declared comparison justify ordering them?
• Which eligibility, evidence or other receiving-use conditions actually apply?
• What result can be handed over, and what prevents a complete result?
• Does the current question additionally claim actual selection, composition, a relation between meanings, public identity or publication? Open only the applicable branch in §4.2.

G.5:0.4 - First output

State one SelectorOutcome under §4.4b: its kind, applicable members or keyed entries, ordering, named use and inclusion conditions where required, handoff or blocking content, and sufficient basis pins. Use the quick card in §4.4c. For an ordinary result over grounded rows, direct refs to the grouping, eligibility and comparison basis plus the S3 audit refs suffice; the same compact record can carry them.

A prior C.11 choice, C.19 pool-policy result, C.24 next action or another governed inclusion basis can supply the inputs. G.5 states the resulting membership or handoff. Exact framework editions retain their own identities and use G.5-6 DeclareSetResult; E.4.PFR governs their dependency or compatibility claims. Add a stable public identity only when needed. For audience availability, use E.17’s source-backed face and E.24.PUB’s publication conditions through S5.

G.5:0.5 - Minimum ordinary slice and bounded non-use

Situation. A pump-maintenance team has two already admitted A.3.1 Methods, ThresholdTrendReviewMethod-E2 and SpectralResidualReviewMethod-E1, behind the exact project-local selector rows <ThresholdTrendReview-local, R3> and <SpectralResidualReview-local, R2>. These are MethodFamilyRowRef values: each fixes its row edition, exact MethodRef[], and declared grouping basis PumpTriageCandidateGrouping-E1. The same TaskSignatureRef=PumpVibrationTriage-T1 and effective reference scheme apply to both. The task signature requires a 24-hour series input and a 30-minute review budget, and both declared Method interfaces meet those constraints. No G.4 CAL gate is current in this ordinary case, so TaskMapRef is absent. No admitted comparator justifies ordering one above the other. The live G.5 question is now how to surface that admissible set, not which pump action a decision-maker should choose.

The minimum truthful result is:

GroundedCandidateRows = [
  { methodFamilyRowRef = <ThresholdTrendReview-local, R3>,
    MethodRef = [ThresholdTrendReviewMethod-E2],
    groupingBasis = PumpTriageCandidateGrouping-E1 },
  { methodFamilyRowRef = <SpectralResidualReview-local, R2>,
    MethodRef = [SpectralResidualReviewMethod-E1],
    groupingBasis = PumpTriageCandidateGrouping-E1 }
]

SelectorOutcome(

  selectorOutcomeKind = SetResultOutcome,
  setResultFamily = Shortlist,
  members = [<ThresholdTrendReview-local, R3>, <SpectralResidualReview-local, R2>],
  ordering = unordered,
  basisPins = [<ThresholdTrendReview-local, R3>,
               <SpectralResidualReview-local, R2>,
               PumpTriageEligibility-E1],
  auditRefs = [DRR-PumpTriage-01, SCR-PumpTriage-01],

  nextUse = maintenance_method_handoff

)

What changes in practice. The team stops leaving the retained pair implicit in a comparison note and stops saying “the spectral method is best.” It emits one unordered Shortlist that another receiver can cite, with the exact survivors and basis visible, while making no local-choice, actual-use, or winning-method claim. A later receiver can request one missing comparator, use the bounded handoff, or open its separately governed decision question without rewriting either Method or inventing a winner.

Near misses and non-use. Do not use G.5 merely because several names appear in one list.

• If the Method-dispatch candidates are only labels, descriptions, cards, or unresolved references, require A.3.1 and C.2.1 before dispatch.
• If the current question is one local choice among already available options, use C.11; if it is the policy for retaining or retiring live candidate lines, use C.19; if it is enactment planning after choice, use C.24 for the plan and the applicable A.15/A.6 patterns for actual Work and operation applications.
• If the current object is only a composition sketch, keep the S4 template; use B.1.5 only for a qualified composite Method and A.22 only for an independently selected Structure.
• If no rival candidate set, selector result, narrowed handoff, abstain, or escalation is current, do not open G.5.
• Open F.9, A.10, B.3, stable registry or UTS identity, and E.24.PUB only for an actual crossing, relied-on evidence, assurance claim, reusable identity, or audience-availability claim respectively; their absence does not invalidate the smaller same-scheme selector result.

G.5:0.6 - Reuse a local grouping, then register it publicly when needed

The pump team in §0.5 already dispatches through R3 and R2. That unordered shortlist requires no new row. If the grouping of both Methods must recur across triage runs, the team can define:

MethodFamilyRowRef = <PumpReviewCandidates-local, R1>
MethodRef[] = [ThresholdTrendReviewMethod-E2, SpectralResidualReviewMethod-E1]
GroupingBasis = PumpTriageCandidateGrouping-E1
EligibilityBasis = PumpTriageEligibility-E1
TaskSignatureRef = PumpVibrationTriage-T1
ComparisonBasis = no admitted ordering; retain admissible alternatives unordered

The grouping criterion is “these admitted review Methods are candidates for pump vibration triage using the stated 24-hour input and 30-minute budget.” This project-local row fixes those exact members and basis; changed membership or an action-changing policy makes R2. It requires neither a UTS row nor an AssuranceProfile when this ordinary use has no assurance gate. A later real gate still consumes its required evidence and follows its unknown/fail behavior.

If the team instead intends a stable public registry entry, its proposed public continuation can be <PumpReviewCandidates, P1>, linked by an explicit naming/continuity mapping to the local R1 grouping. P1 retains the same exact Method refs and grouping criterion, adds the typed EligibilityStandardRef for the pump task and an AssuranceProfileRef stating expectations for its declared uses, and satisfies UTS naming/publication requirements under S1 and CC-G5.6. Registration is complete only when those public-contract obligations are met. For this P1 example, PumpTriageEligibilityStandard-E1 states the two Methods’ required 24-hour series and 30-minute budget, with unknown when a required input cannot be determined. PumpTriageAssuranceProfile-E1 names the evidence expectations and failure behavior for the declared triage uses; UTS-PumpReviewCandidates-P1 supplies the public name and continuity mapping to R1. P1 registration consumes these completed declarations and that UTS entry alongside the unchanged exact member/grouping basis. A missing one leaves public registration incomplete. The assurance profile supplies no B.3 result.

R1 itself completes through RegisterFamily with the six values shown above: neither AuthoringBase nor AuthoringMinimal is activated because this local grouping has no CG-Frame use. P1 adds the three public references just described and activates UTSWhenPublicIdsMinted. Now suppose a later G.5-3 Select use is governed by PumpTriage-CG-E1, whose MinimalEvidence clause requires a valid sensor calibration for the cited vibration series. Its CN/CG editions and frame pins are required. If the calibration input is missing, the evidence predicate is unknown and this example’s gate rule returns abstain; neither successful local R1 registration nor completed public P1 registration makes that selection pass.

Making local R1 available to the project audience may itself be an E.24.PUB publication occurrence when that pattern’s conditions obtain. Conversely, the intention or declaration of P1 establishes no availability. Neither branch creates a Method or an ontic family relation. Non-Method joint-use members continue through DeclareSetResult with their existing identities and inclusion basis.

G.5:1 - Problem frame

The exact CG‑Frame card from G.1 and SoTA Synthesis Pack@CG‑Frame from G.2 name the frame, EntityOfConcernRef, ReferencePlane, source rows, and rival internally coherent method families (and sometimes generator families) that may address the same declared task. If their breadth is used as a premise, cite G.2’s pack CoverageJudgementRef and its HarvestPolicy basis. Registration does not recount cards as families; a combined method/generator coverage result does not establish method-only coverage for dispatch.

At the same time, the scale and coordinate definitions from G.3 and the typed operator-argument and result declarations from G.4 make admissible calculi and acceptance clauses explicit - enough to formulate eligibility, assurance, and admissibility constraints, but not enough to pick “the method” without collapsing plurality.

You need a notation‑independent way to:

1. register method families and generator families as auditable, versioned entries,
2. select, compose, or fall back among them at run time for a concrete task instance,
3. declare stable selected-set results, including retained-alternative and all-member results, and publish stable identities to UTS when required, and
4. emit RSCR‑relevant triggers and pins without inventing new “shadow specs”.

G.5:2 - Problem

How to design a general, auditable dispatcher that:

• preserves pluralism (families from competing Traditions stay disjoint) while remaining dispatchable (selection is possible and explainable);

• does not embed algorithmic dogma in the core selector kernel;

• when expressions carry distinct F.17 source-local meanings, requires the complete crossing path—exact local senses, an obtaining F.9 Bridge, a separate bounded-use proposition, and the appropriate reliance or assurance branch—while treating pins as audit references rather than as the crossing facts;

• produces set-valued outcomes when only partial orders are admissible or when every named member is included for one bounded use, without confusing those meanings; when exact non-Method members already have a current inclusion basis, it declares that result without routing them through method-family selection;

• cleanly separates:

  • selector object set and components (registry, selector boundary, and result-declaration records),
  • universal Part‑G invariants (carried by G.Core),
  • method-specific and generator-specific semantics (carried only through Extensions blocks).

G.5:3 - Forces

• Pluralism vs. forced totalisation. Many selection regimes are inherently partial-order; forcing a scalar winner often creates inadmissible semantics.

• Evidence realism vs. hard gates. Eligibility and acceptance frequently depend on incomplete evidence; selection must remain auditable under tri-state unknowns.

• Reuse vs. leakage. Reuse across distinct source-local meanings remains valuable, but it starts from exact F.17 cells and an obtaining F.9 Bridge, then keeps the proposed use, direction, rule, tolerated loss, reliance or assurance, and actual selector use separate. Bridge, CL, loss, registry, bundle, or policy pins cannot silently re-ground semantics.

• Exploration vs. exploitation. Dispatch sometimes must probe alternatives under explicit policy envelopes and risk envelopes, but probing must not become an implicit fourth status.

• Evolvability vs. churn. Registries evolve (new families, deprecations, edition bumps); continuity must not be broken by “rename by meaning”.

G.5:4 - Solution

G.5:4.1 - G.Core linkage (normative)

Builds on: G.Core (Part‑G core invariants; Default Governing Definition Index citation)

GCoreLinkageManifest (normative; size-controlled via profiles and sets). For the operation in use, expand the applicable profile and set ids by union with its explicit deltas (per G.Core:4.2.1). The activation conditions below select those ids before expansion; Nil‑elision does not waive an activated obligation. Select retains its exact task, row editions and DRR/SCR-addressable audit result. DeclareSetResult instead consumes its exact result family, identified members, inclusion basis, ordering and named use where required; it acquires no TaskSignature, Method or registry row merely by declaring that set.

Select profile activation before expanding the G.Core sets. RegisterFamily always retains S1’s immutable row edition, exact admitted members, grouping criterion and applicable eligibility/comparison basis. A project-local row without a CG-Frame activates neither AuthoringBase nor AuthoringMinimal; it still satisfies those S1 obligations. Intentional public registration adds EligibilityStandardRef, AssuranceProfileRef and UTS obligations even when no CG gate is in use. When a real CG-Frame registry or Select use is current, both authoring sets apply in full; omitting their required CN/CG pins is a failure, not nil-elision.

For crossing-aware selection, CorePinsRequired below lists the crossing pins individually. Each conditional pin is mandatory when its stated condition holds. When consuming G.7 calibration records or a named B.3 assurance account, retain all pins, editions, and evidence required by that account, including CC‑G7‑SCRLinkage‑1 for cited calibration evidence.

• CoreConformanceProfileIds :=

  • GCoreConformanceProfileId.PartG.AuthoringBase (when the current operation authors a registry in an actually selected CG-Frame or performs G.5-3 Select within that frame)
  • GCoreConformanceProfileId.PartG.TriStateGuard (when evaluating eligibility or acceptance predicates)
  • GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted (when public identities are minted or evolved, including intentional public registration under S1/S1′ and CC-G5.6; a reusable project-local row alone does not activate this profile)
  • GCoreConformanceProfileId.PartG.ShippingBoundary (when an output is shipped)

• CorePinSetIds :=

  • GCorePinSetId.PartG.AuthoringMinimal (for the same actual CG-Frame registry-authoring or G.5-3 Select use; local registration or a set declaration alone does not activate it)

• CorePinsRequired := (delta over PinSets; pins and refs are id-only; prefer strengthening optional-to-required over restating pins already covered by PinSets)

  • TaskSignatureRef (the C.22 TaskSignature edition for Select; see G.5:4.2, S2)

  • TaskMapRef? (exact G.4 map edition, only when this selection uses G.4 CAL gates)

  • MethodFamilyRowRef[] (exact <MethodFamilyId, rowEdition> values when method-family rows are consumed or registered)

  • MethodRef[] (exact A.3.1 Methods resolved from every method-bearing registry row consumed or registered)

  • SelectedStructureRef[]? (exact independently selected A.22 Structures consumed only when their organization changes this selector use)

  • GeneratorFamilyRowRef[]? (exact <GeneratorFamilyId, rowEdition> values when generator families are in scope)

  • PathId[]?, PathSliceId[]? (when audit or evidence citations use a G.6 graph, or an independently applicable gate or shipping contract requires those citations)

  • UTSRowId[]? (when the operation mints, evolves or consumes a public identity; intentional public registration activates S1/S1′ and CC-G5.6 obligations)

  • FailureBehaviorPolicyId? (only when degrade or abstain behavior is explicitly policy‑bound)

  • SoSLogBranchId? (only when degrade or abstain behavior is explicitly policy‑bound)

  • BridgeId/BridgeCardId? (the obtaining Bridge actually used by this selection; a Bridge Card is cited only when that Card is relied on)

  • BridgeMatrixId? (when this selection uses a BridgeMatrix)

  • CL/CL^k/CL^plane? (the applicable values when cited or required by the consumed calibration or named assurance account)

  • Φ/Ψ/Φ_plane policy-ids? (the applicable policy ids and editions when required by the consumed calibration or named assurance account, or when crossing or plane penalties are applied)

  • CrossingBundleId? (when the selector cites a CrossingBundle or its named downstream use requires one under E.18 or CC‑G5.27)

• DefaultsConsumed :=

  • DefaultId.GammaFoldForR_eff
  • DefaultId.PortfolioMode
  • DefaultId.DominanceRegime

• RSCRTriggerSetIds :=

  • GCoreTriggerSetId.RefreshOrchestration (payload: exact changed source and affected-use scope; SCRId, DRRId; TaskSignatureRef, MethodFamilyRowRef[], CGSpecRef.edition and CNSpecRef.edition for a Select result; and the actually applicable TaskMapRef?, GeneratorFamilyRowRef[]?, AcceptanceClauseId[]?, SoSLogBranchId?, FailureBehaviorPolicyId?, DescriptorMapRef.edition?, DistanceDefRef.edition?, TransferRulesRef.edition?, InsertionPolicyRef?, PathId[]?, PathSliceId[]?, RSCRTestId[]?. Nongraph scope uses the existing G.Core PatternScopeId branch.)

G.5:4.2 - Dispatcher and Registry object set (notation‑independent)

G.5 defines the object-set components below. Their purpose is to make dispatch possible and auditable without embedding any method-family semantics in the selector kernel.

S1 — MethodFamily Registry (design-time; project-local or within a selected CG-Frame). A reusable row represents one declared grouping. Choose its registry-identity contract: project-local reuse, or intentional registration under a stable public registry identity. This distinction concerns the identity contract, not who can see the row. Both branches fix these replayable values:

• Identity and continuity: MethodFamilyId names the continuing row lineage; rowEdition names one immutable edition; MethodFamilyRowRef := <MethodFamilyId, rowEdition> designates that edition. Lineage and Tradition notes and UTSRowId remain descriptive or publication values.
• Exact method members: non-empty MethodRef[], each resolving to one U.Method already admitted under A.3.1.
• Grouping basis: exact claim, criterion, or direct relation reference that justifies this row’s grouping for the current selector use; if no ontic family or membership relation is directly governed, the basis is explicitly project-local and creates none.

One exact row edition fixes its method members, grouping basis, and every selection-changing pin. Changing any of those values creates a new rowEdition; retain the MethodFamilyId only while the declared grouping remains the same continuing row lineage. Old MethodFamilyRowRef values continue to resolve their old editions. Add task, eligibility, policy, scheme, source, ClaimScope, validity, or intended-use pins only when they change selection or a named receiver needs them; none replaces the members or grouping basis.

• Eligibility and comparison basis: the actual rule and applicable editions used for this selection, including whether any comparison justifies ordering. A local row may cite its existing project rule; it need not manufacture a public eligibility artifact.
• Assurance expectations, only when the local use requires them, with the applicable evidence, unknown and failure rules. A real assurance or minimal-evidence gate keeps every input required by its governing clause.

Public-registry continuation. Intentional registration under a stable public identity additionally requires EligibilityStandardRef as a typed predicate record (tri-state per G.Core, using CHR/CAL terms and applicable edition pins), AssuranceProfileRef for declared evidence-lane expectations and assurance-lane pins, and the UTS naming/continuity obligations of CC-G5.6. The AssuranceProfile states expectations; it is not a B.3 assurance result. The public contract retains the same immutable members and grouping basis. The remaining fields below apply when their subject conditions hold in either branch.

• AdmissibilityBindings: when the row is authored for an actual CG-Frame or consumed by its gate, cite its single governance card and gate (CNSpecRef, CGSpecRef) and every required admissibility constraint, such as scale/unit conditions for a measurement use. An ordinary local grouping with no such use adds no CN/CG reference.
• EvidencePins: the source and evidence citations supporting asserted claims or guarantees. Cite G.6 PathId or PathSliceId values when that support is represented in a graph or an independently applicable receiving contract requires those citations.
• CrossingAllowance: references to the exact F.17 endpoint senses, one obtaining F.9 Bridge, the separate C.2.1 bounded-use proposition, and the current A.10 or B.3 reliance basis, plus CL or observed-loss evidence when material, only when expressions with distinct recovered source-local meanings are actually related for this selector use. These are audit references; the field makes none of the referenced facts obtain.

For an actual crossing, first resolve both exact F.17 SchemeSenseCell endpoints and establish the two-participant F.9 Bridge under its own predicate profile. Then identify a separate C.2.1 episteme whose exact EntityOfConcern is that Bridge and whose ClaimGraph states the proposed use u, direction d, use-specific rule r, tolerated loss t, and polarity. For ordinary reliance require the matching current A.10 evidence-provenance path and local RelianceDisposition; when an actual named assurance claim is current, use B.3’s separate assurance branch. A consequential use without one retains its direct governing rule. Observed loss and CL are evidence, defeater or assurance-policy material, not Bridge participants or permission. Authorization and the actual Select application remain with their subject patterns. A Bridge id, CrossingAllowance, registry row, policy pin, CrossingBundle, DRR or SCR entry cannot substitute for any step.

• PolicyHooksRef?: optional pointers to policy records (not defined here; wired via Extensions).

Here “a registry row represents a family” means that the row is the auditable selector-facing record for one declared grouping. The family id preserves that row lineage; the row ref selects one immutable edition for replay. Neither value identifies the grouped Methods, makes a membership relation obtain, or turns a common label, shared description, lineage note, eligibility rule, maturity card, evidence record, or policy into a method-family fact. Changing a row edition changes the registry artifact; it changes a Method or a separate family relation only when that object’s direct identity rule or the relation’s predicate independently says so.

S1′ — GeneratorFamily Registry (design‑time; optional; per CG‑Frame). A reusable row groups generators of tasks and environments, which may co-evolve solver families. It uses the same local/public identity-contract distinction as S1 while retaining its own generator member and signature rules:

• Identity and continuity: GeneratorFamilyId names the continuing row lineage; rowEdition names one immutable edition; GeneratorFamilyRowRef := <GeneratorFamilyId, rowEdition> designates that edition. UTSRowId is required by intentional public registration; project-local reuse does not require it.
• Exact generator members: non-empty references, each resolving to a generator already identified under its subject pattern.
• Grouping basis: the independently established classification, membership relation, or explicit project-local criterion that groups those generators for this selector.
• GeneratorSignatureRef: conceptual input and output semantics plus budget semantics.
• EnvironmentValidityRegionRef?: pinned constraints for generated environments or tasks.
• TransferRulesRef.edition?: required when the Open-Ended mode is enabled (semantics come from the cited extension refs).
• CouplerRefs?: exact MethodFamilyRowRef[] values that may be coupled with this generator-row edition.

Both branches also fix the applicable eligibility/comparison basis and every selection-changing source or policy pin; assurance expectations are conditional on the use. Changing generator members, grouping basis, or another selection-changing pin creates a new generator rowEdition; old GeneratorFamilyRowRef values continue to resolve their old editions. Intentional public registration activates CC-G5.6 naming, continuity and UTS obligations, with the applicable generator signature and use contracts. It does not import A.3.1 Method membership into generator rows.

S2 — C.22 TaskSignature input and conditional G.4 map. C.22 constitutes the TaskSignature episteme and defines its edition rule. G.5 consumes its TaskSignatureRef and does not reconstruct it from a task, CAL pack, or map. Its function here is pinning and auditability, not over-specification.

When this selector actually uses G.4 CAL gates, it also consumes one exact TaskMapRef. Resolve that immutable map edition, require its taskSignatureRef to equal the C.22 TaskSignatureRef supplied to this selector, and follow its exact CALCharterRef and edition-bearing clause, operator, flow, and evidence-profile refs. The map supplies no TaskSignature field and no threshold value. If no G.4 gate is current, omit TaskMapRef; an ordinary selector does not need a CAL pack merely to return a truthful bounded result.

For the G.4 safety example, G.5 receives TaskSignatureRef=SafetyPortfolioTaskSignature-E4 and TaskMapRef=<SafetySelectionMap, E3>. The map resolves CALCharterRef=<SafetyCALCharter, E2> and the cited gate declarations. A different signature ref or an unresolved charter or component blocks only that gated selector use.

S3 — Selection kernel boundary (run‑time; policy‑governed). A notation‑independent selector that:

• consumes TaskSignatureRef, exact method- or generator-family row refs, pinned spec refs, and an exact matching TaskMapRef only when G.4 CAL gates are current,
• applies the declared eligibility conditions and any assurance gates actually required for this use (tri-state),
• computes an admissible (possibly partial) order,
• returns one declared selector outcome over the exact Method candidates admitted through this kernel: most often Shortlist or RankedShortlist, and JointUseSet only when every returned Method candidate is included for one named use; otherwise it returns one SpecialistHandoff, one other narrowed handoff, one abstain outcome, or one escalation outcome (per DefaultId.PortfolioMode and explicit overrides),
• emits audit records with pins addressable by DRR and SCR records.

When TaskMapRef is present, resolve its exact immutable G.4 map edition before applying any cited gate. Its taskSignatureRef must match this selector’s C.22 TaskSignatureRef; its CALCharterRef must recover the CG frame, EntityOfConcern, ReferencePlane, specification editions, and assumption envelope; and each cited clause, operator, flow, and evidence profile must resolve at its exact edition. Carry the exact map ref among the result basis and refresh pins. Do not copy thresholds or acceptance semantics into G.5.

If a cited gate consumes R, resolve the quantity and support model under CC‑G5.4 before evaluating its threshold. Keep formal and empirical inputs, required premises, complementary support, dependence, scope, and counterevidence distinguishable. No common model means no invented aggregate: retain a qualified synthesis, and apply the clause’s unknown behavior only where that missing quantity is actually required. The ordinary selector result in §0.4 is not an assurance claim and needs no new R calculation.

For every MethodFamilyRowRef consumed here, resolve the exact immutable row edition and then its A.3.1 MethodRef[], grouping basis, and selection-changing pins before admitting the candidate. Apply the same rule to GeneratorFamilyRowRef. The selector may compare or return exact row refs as auditable selector-facing addresses, but row selection neither creates its members nor proves that every listed member belongs, is admissible, is selected, or will be enacted. An unresolved Method reference or missing grouping basis blocks that row’s method-bearing use; it is not repaired by a label, description, UTS identity, policy, or evidence pin.

When a selector consumes an organization among Methods, cite an exact SelectedStructureRef only after A.22 has independently identified the U.Structure from exact constituents, exact already-obtaining relation occurrences, applied constraints, and one named use frame. G.5 neither supplies those discriminators nor selects the Structure by listing it. If the organization instead constitutes one composite Method, consume the exact A.3.1 Method only after B.1.5 has qualified that candidate from its independent parts and whole-forming basis.

S3 states reusable selector behavior. It does not itself perform selection. For an actual selector use, first recover every precise performer’s A.13 core for the exact selection action, scope, working situation, and window, including the same obtaining assignment later used by any exact attribution. A.15.1 then independently admits the dated selector Work from its exact performance history, enacted Method, temporal extent, and containing-System relation. State the actual A.6.1 Select application, its effective argument bindings, and the A.19 SelectionSlot binding for any selected set returned by value. Add F.6 afterward only when the receiving claim needs exact assignment-bound attribution through the same obtaining A.13 assignment. The declaration, planned pins, registry rows, policy, assignment, F.6 relation, and CandidateSet type create none of the A.13, Work-admission, application, or result facts.

A compact selector account may omit only an assignment identifier unused by its receiving claim; it omits no criterion, classification, assignment, Work-admission, or attribution fact that the claim consumes. A root-family reference, the same holder, overlapping times, or silence in the receiving text establishes or removes neither the assignment nor F.6 attribution. Ordinary selector discussion not admitted as U.Work does not enter this branch.

In this actual-selector branch, the independently admitted dated selector Work and its actual Select application are required. Replay the upstream CPM applications through their own declaration-local bindings; separately admitted comparison Work is required only if the account asserts it. Evidence use, A.10 reliance/provenance, G.11 currentness and a C.2.1 result episteme retain their complete independent grounds when asserted or consumed by the receiving use. A bounded selection that consumes none of these additional claims requires no such additional object.

S3.A — TaskFamilySpecializationProfile@Context (run‑time; conditional). When the real selector question is acquisition of usable specialization on a declared task family, the selector may emit one TaskFamilySpecializationProfile@Context for each candidate, one SpecialistHandoff, or one narrowed handoff plan. Here profile means one selector-time comparison record for bounded specialization, not a new U-kind and not a generic narrative profile. G.5 carries this selector-time specialization question here; it does not redefine the adaptation-signature field vocabulary from C.22.1.

The profile should therefore cite one AdaptationSignatureRef or equivalent pinned field set carrying the declared TaskFamilyRef or TaskSignature, the work-measure threshold target, prior exposure declaration, time-to-threshold, budget-to-threshold, post-threshold efficiency when relevant, any declared transfer or retention claim, any downside cost or downside on adjacent tasks, and any specialization-entry baseline, specialization-entry evidence, or stepping-stone evidence item that materially affects comparison.

Admission rule for SpecialistHandoff: use that handoff kind only when the truthful declared result is one heterogeneous handoff bundle whose members occupy different specialization positions that still need to travel together. Do not use it when a SetResultOutcome with Shortlist, RankedShortlist, or JointUseSet, or a HandoffOutcome with another admitted handoff kind, already states the result more precisely.

When the declared task family is heterogeneous, the selector may return one SpecialistHandoff, one other narrowed handoff plan, or one SetResultOutcome with an admitted SetResultFamily that preserves rival specialists rather than collapsing them into a fake single winner. Low-human-overlap candidates remain admissible only when the profile, evidence basis, and policy constraints are explicit.

S4 — Composition and fallbacks templates (design‑time). A library of composition shapes—preconditioner -> solver -> verifier, cascades, and meta-selectors—remains available as design-time templates, admissibility-checked and pinned. A template is a description or policy-bound arrangement for possible composition; its existence, diagram order, registry placement, or selection does not create a Method, methodPartOf occurrence, obtaining relation, or selected Structure.

If exact A.3.1 Methods, exact B.1.5 methodPartOf occurrences, all other required whole-forming claims and constraints, whole semantics, interface boundary, and reidentification rule qualify one already identified candidate as a composite U.Method, consume that exact Method through the B.1.5 branch. If independently identified Methods and already-obtaining relations are instead organized for one use without constituting one Method, consume an independently selected A.22 U.Structure only after its exact constituents, selected obtaining relation occurrences, applied constraints, and named selection-use frame are present. MethodRelationStructure may remain a local readable designator for that actually selected Structure; it is not a U-kind, relation kind, Method holon, registry-row identity, or generic @BoundedContext object.

A C.2.1 episteme may describe either governed object. A.3.2 applies only when the episteme’s exact EntityOfConcern is one already admitted Method and its claims substantively describe that Method; an episteme whose exact concern is the selected Structure is not thereby a U.MethodDescription. Concrete strategy semantics stay in the referenced method families; G.5 only carries the composition template, selector relation, registry row, exact consumed Method or Structure reference, or selected-set result. None of those G.5 artifacts supplies the B.1.5 or A.22 construction facts.

Algebraic, graph, matrix, embedding, or neural selector notation remains a mathematical or representation lens when that representation is current; use C.29 for its correspondence and preserved-or-lost structure rather than reading notation as composition or selection.

S5 — Result, public identity, and telemetry record boundary (run-time). Declare the following S5 outputs:

• DRR (decision rationale) and SCR (evidence and confidence citation) with explicit pins,
• declared selector and selected-set records produced either by method-family G.5-3 Select or by the already-grounded-member G.5-6 DeclareSetResult branch,
• telemetry pins to refresh orchestration (G.11), without governing orchestration.

S5 governs the selector-facing record boundary, not truth or actuality by record existence. A DRR, SCR, selected-set record, shortlist id, telemetry event, refresh cue, policy pin, or result label does not create dated Work, an actual operation application, the selected-set binding, a domain result, an evidence-provenance relation, assurance, authorization, or publication availability. Persist a selector-result claim as its own C.2.1 episteme when another use must rely on it; connect evidence through A.10, assurance through B.3, authorization through its direct governor, and actual availability through E.24.PUB only when each claim has its independently established basis.

Use §4.4b for outcome kinds and §4.4c for conditional public-identity fields.

S6 — Governance and evolution declaration boundary (design-time). Versioning, deprecation, and registry evolution discipline (UTS publication; continuity), without minting new Part‑G‑wide types.

G.5:4.3 - Selector head and narrower selector families

Selection and dispatch stay one generic selector head. Narrower selector families may refine it, but they do not redefine the universal invariants pinned through G.Core, do not add new mandatory inputs to inherited Select, and do not mutate inherited SlotKinds. Required policy and edition refs use the declared input meanings.

Method- and generator-specific pressures such as QD archives, open-ended declared sets, explore and exploit lenses, or preference comparators do not become part of the selector head. They arrive only through explicit extension declarations and the pins those extensions require.

G.5:4.4 - Selector Relation Fields

RegisterFamily produces only the local or public registry row selected under S1. It does not produce any A.3.1 Method or independently governed membership fact. Select may address candidates through those rows only after their exact Methods and grouping bases resolve; its returned candidate or selected-set value does not retroactively ground a row member.

Compose produces only the pinned template named in its output column. It neither qualifies one composite Method under B.1.5 nor selects one A.22 Structure. When a later selector use consumes either governed object, the exact Method or Structure reference is an independently grounded input rather than a result inferred from this template.

DeclareSetResult begins only after its exact members and inclusion or selection basis are current. An upstream C.11 ChoiceResult, C.19 pool treatment, accepted decision, or another governed basis may appear among basisPins; the G.5 branch does not repeat or perform that decision. It declares the selector-facing set-result content and stops. It creates no member identity or relation, method-family row, Select application, dated selection Work, persisted C.2.1 result episteme, assurance or authority claim, or E.24.PUB availability occurrence.

G.5:4.4a - Worked selector slice

• A catalyst-search team is choosing among three method families for the same declared TaskSignature and C.22.1 adaptation signature.

• The shared profile pins one work-measure threshold target, one freshness window, one prior-exposure declaration, and one adaptation budget. One family reaches threshold quickly but carries high downside on adjacent tasks. One family is slower but transfers cleanly. One family never clears MinimalEvidence and must receive an abstain verdict.

• The G.5 result in this slice therefore declares one unordered Shortlist retaining the first two families, with DRR and SCR records citing why the third family was excluded and why the first two remain non-dominated. The selector does not invent one scalar winner and does not hide the specialization profile in auxiliary side notes.

• If the project also claims that this selection actually occurred, A.13 first recovers CatalystSelectorSystem-17 : U.System for exact action CatalystFamilySelectionAction-17. CatalystSelectorBoundary-17 contains the deployed selector runtime, its effective policy state, and its registry/evidence interfaces; it excludes the method-family rows, TaskMap, result records, assignment, and containing team System. The action applies the effective selector to the three candidate families and returns the retained set. Its scope is CatalystFamilySelectionClaimScope-17, its working situation is CatalystSearchSelectionSituation-17, and its window is 2026-07-30T10:00:00Z through 2026-07-30T10:08:00Z. CatalystSelectionAdmissibilityNorm-17 directs the selector to exclude candidates that fail MinimalEvidence, preserve admissible non-dominated alternatives, and abstain rather than manufacture a scalar winner. Relevant conditions include the exact CatalystTaskSignature-17, current row and map editions, eligibility evidence, comparison policy, and adaptation-signature values.

• A.2 declares local agential kind CatalystMethodSelectorSystemRole. Its membership criterion requires the stable work-facing contribution of method-family selection and goal-directed, condition-sensitive regulation under CatalystSelectionAdmissibilityNorm-17: the holder must apply the current gates, preserve the admissible set-return semantics, and abstain or escalate when no candidate qualifies. CatalystSelectorDecisionTrace-17 shows CatalystSelectorSystem-17 excluding the third family for failed MinimalEvidence, retaining the first two as non-dominated, and emitting no scalar winner. The trace and boundary/runtime records support the criterion facts under A.2’s membership rule; A.10 makes that source-to-use account recoverable. The case independently classifies CatalystSelectorSystem-17 under CatalystMethodSelectorSystemRole; neither the assignment nor the candidate Work supplies the classification. No Grade, autonomy result, characteristic profile, or stronger assurance claim is consumed.

• The same A.13 core uses CatalystSelectorAssignment, a directly declared species under U.SystemRoleAssignment. The species declares holder, assigned-kind, and task-signature participant meanings and the assignment predicate. CatalystSelectorAssignment-17 obtains with CatalystSelectorSystem-17, CatalystMethodSelectorSystemRole, and CatalystTaskSignature-17 as its exact participant values; its maximal uninterrupted predicate-true interval covers the stated scope, situation, and window.

• Only after that core is established does A.15.1 independently admit CatalystSelectionWork-17 : U.Work from the exact selection-action history, enacted CatalystFamilySelectionMethod, temporal extent, and obtaining containing-System relation to independently admitted CatalystSearchTeamSystem. Actual application CatalystSelectApplication-17 separately carries its effective candidate, criteria, and A.19 SelectionSlot bindings. Neither the assignment nor F.6 is an A.15.1 admission premise.

• Because this account explicitly attributes the Work under CatalystSelectorAssignment-17, F.6 afterward establishes performedUnderAssignment(CatalystSelectionWork-17, CatalystSelectorAssignment-17) through that same obtaining A.13 assignment. The direct case fact links the exact pair, holder equality holds, and the assignment interval covers the Work. A different overlapping assignment held by the same System would not establish this attribution. A short result may omit the assignment identifier only after every fact consumed by the attribution remains recoverable.

• A persisted shortlist assertion is a separate C.2.1 episteme; its DRR or SCR references do not by themselves prove the exclusion facts, warrant the result, authorize downstream action, or make that episteme available to an audience.

• When one upstream C.19 pass has already narrowed the live pool to one internal retained subset over registered families, G.5-6 DeclareSetResult may declare that result as one Shortlist with one ShortlistId and explicit basis pins only when selector-facing result declaration is now the question. Until that declaration occurs, the internal retained subset is not yet one G.5 shortlist result.

• When one upstream C.11 pass has already fixed one local choice over one declared source set, C.19 has fixed one retained pool treatment, an accepted decision has fixed all-member inclusion, or C.24 has produced one enactment-facing narrowed handoff, use G.5-6 DeclareSetResult when selector-facing set-result content is now the question. Until that declaration occurs, the ChoiceResult, PoolPolicyResult, accepted inclusion basis, CallPlan, or CheckpointReturn is not itself that G.5 result. Non-Method members do not pass through RegisterFamily or G.5-3 Select.

G.5:4.4b - Declared selected-set result and closure rule

When the current question is selector-facing result declaration, state one explicit selected-set result rather than leave it implicit in a selector trace, comparison note, or local choice.

For method dispatch, that result closes selector work over grounded rows. For a JointUseSet, it records already identified members that are all included for one named use. It does not replace registry maintenance, comparison rules, the upstream choice or inclusion basis, or the patterns that identify the members and their relations.

The admissible selector outcome families here are:

• SelectorOutcomeKind = SetResultOutcome, whose closed SetResultFamily value set is Shortlist when alternatives are retained for later choice and the result does not order them, RankedShortlist when the result orders those retained alternatives, and JointUseSet when every named member is included for one named use;
• SelectorOutcomeKind = HandoffOutcome, with HandoffKind = SpecialistHandoff or one other narrowed handoff plan when heterogeneity is the truthful downstream result;
• SelectorOutcomeKind = AbstainOutcome when no admissible candidate exists and the truthful result is one abstain; and
• SelectorOutcomeKind = EscalationOutcome when no admissible candidate exists and the truthful result is one escalation.

G.5-3 Select may emit one of these outcome kinds only over the exact Method candidates admitted through its kernel; G.5-6 DeclareSetResult emits SetResultOutcome from exact already identified members and a current inclusion basis. Neither branch performs an upstream choice, makes a member relation obtain, or proves actual selection Work.

A JointUseSet uses this bounded representation:

• namedUse states the one joint use;
• memberEntries contains one keyed entry per included member;
• every entry has one exact memberRef; the membership result adds no per-member contribution or basis field;
• each exact memberRef occurs at most once, and entry order has no semantic effect;
• if a serialization also emits top-level members, it is only the unique set projection of memberRef values from memberEntries, never a second maintained list;
• ordering, inclusion conditions, and sufficient top-level basisPins remain explicit; and
• candidate-pool membership and excluded candidates stay separate from emitted joint-use membership.

Exact content, claims about a member’s use or contribution, and direct relations keep their own governed records. When one supports the membership result, cite that existing record among basisPins; memberEntries creates neither the cited content nor a new contribution relation.

For framework use, memberRef may name an exact already identified edition under its existing identity rules. Do not populate MethodRef, create a registry row, or classify that edition as a Method merely to emit the result.

Every outcome still states its SelectorOutcomeKind, public result kind when applicable, members, keyed entries, handoff content, or blocking condition, ordering, and sufficient basis pins. A handoff also states its next downstream use boundary.

A compact retained-alternative result may look like:

SelectorOutcome(
  selectorOutcomeKind = SetResultOutcome,
  setResultFamily = Shortlist,
  members = [family_A, family_C],
  shortlistId = shortlist_17,
  ordering = unordered,
  basisPins = [pathSlice_41, scr_22],
  nextUse = downstream_comparison
)

A compact joint-use result may look like:

SelectorOutcome(
  selectorOutcomeKind = SetResultOutcome,
  setResultFamily = JointUseSet,
  namedUse = cohort_review,
  memberEntries = [
    { memberRef = FPF@C },
    { memberRef = Domain@D },
    { memberRef = Local@L }
  ],
  ordering = unordered,
  inclusionConditions = [all_three_editions_required_for_cohort_review],
  basisPins = [choice_result_12, edition_basis_7]
)

Close with Shortlist or RankedShortlist when the result retains alternatives. Close with JointUseSet only when every member is included for the named use and its keyed membership can be stated truthfully. Close with a handoff, abstain, or escalation outcome when that is the actual result. If the result omits its result family, members or member entries, ordering, named use where required, or basis pins, it is not a complete G.5 result.

G.5:4.4bb - Public labels over archive, front, and style source sets

When a selector consumes a declared ExplorationArchive, Archive, Front, or Q-front, keep that object as a source-set family or source-set reference; it is not the emitted G.5 outcome. The emitted result states one admitted SelectorOutcomeKind and, for a set result, one admitted SetResultFamily. StyleShortlist and TraditionShortlist may be public domain labels over an admitted set-result family after their term bridges and cultural meaning are clear; they do not extend either closed set.