#Multi‑Method Dispatcher & MethodFamily Registry

G.5 · Stable · General (G) · Normative · Part G - Discipline SoTA Patterns Kit

#About this pattern

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

#How to use this pattern

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

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

Plain-name. Multi-method dispatcher and method-family registry.

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.

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.

#Keywords

• method-family registry
• generator-family registry
• dispatcher
• SelectorOutcomeKind
• selected-set publication
• set-result outcome
• Shortlist
• RankedShortlist
• ShortlistId
• SpecialistHandoff
• abstain/escalation result
• basis pins
• no hidden scalar winner.

#Relations

#Content

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

Before opening G.5 for Method dispatch, resolve every selectable MethodRef to an exact U.Method already admitted under A.3.1. A MethodFamilyId names the continuing selector-row lineage for one declared grouping; it does not by itself select an exact edition. MethodFamilyRowRef := <MethodFamilyId, rowEdition> designates one immutable row edition, which cites the exact Methods it groups and the independently established classification claim, membership relation, or local grouping criterion used for this selector. Neither the row, its label, a family card, a U.MethodDescription, an eligibility or maturity record, a policy, an evidence pin, a shortlist, nor a publication makes a candidate a Method or makes family membership obtain. Where no exact ontic-family or membership predicate is defined, keep the row as a project-local selector grouping under its declared criterion. If only labels, descriptions, cards, or unresolved references are available, state the blocker and use A.3.1, C.2.1, or the exact family-relation subject pattern only as a locator before selection.

Also say whether the current claim is only a reusable registry, selector, policy, template, or result-content declaration, or whether an actual selection and publication occurred. An actual selection first requires every precise performer's A.13 core and an independently A.15.1-admitted dated Work, plus the actual A.6.1 Select application with effective argument bindings and the SelectionSlot binding for any returned selected set under A.19.SelectorMechanism. Add F.6 only when the current selection claim also needs exact assignment-bound attribution through the same obtaining A.13 assignment. Any persisted result episteme, A.10 evidence-provenance path, B.3 assurance claim, authorization, and E.24.PUB publication occurrence remain separate. A row, declaration, record, telemetry pin, or selected-set label supplies none of them by appearance.

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

#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

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

#First-minute questions

• What selector outcome kind is this result actually emitting: one set-result outcome such as Shortlist, RankedShortlist, or JointUseSet, one SpecialistHandoff or other narrowed handoff, or one abstain outcome?
• Which members are being retained or excluded now?
• Are these alternatives retained for later choice, or is every named member included for one bounded use?
• For JointUseSet, what named use, unique member refs, inclusion conditions, and sufficient top-level basis pins make the result complete?
• Does the result order the retained alternatives?
• Which basis pins or policy pins must the declared result carry?
• Which exact A.3.1 MethodRef values does every method-family row resolve to?
• What independently governed classification, membership relation, or local grouping criterion justifies placing those Methods in that row for this selector use?
• Is the current organization only a composition template, one B.1.5-qualified composite Method, or an independently selected A.22 Structure with all four identity discriminators?
• Is this only selector declaration or result content, or is an actual selection claimed with each precise performer's A.13 core, independently admitted dated Work, actual Select application and bindings, conditional exact F.6 attribution when consumed, and separately governed result and publication objects?
• Does any consumed Method, claim, or selector criterion use expressions with distinct F.17 source-local meanings? If so, which cells are related, where does the F.9 Bridge obtain, what use, direction, correspondence, target, and polarity does the separate crossing claim state, and where is the matching A.10 or B.3 reliance result?
• Which stronger branch is actually current—a new reusable registry row, crossing, evidence/reliance, assurance, stable public identity, or actual publication—and which can remain unopened?

#First output

The first useful output from this dispatcher and registry question is one declared SelectorOutcome admitted by the closed SelectorOutcomeKind set in §4.4b. For SetResultOutcome, use the closed SetResultFamily rule to distinguish Shortlist, RankedShortlist, and JointUseSet; for another outcome kind, state its admitted handoff, abstain, or escalation content. In every case, state the applicable members or keyed member entries, ordering, named use and inclusion conditions when applicable, and basis pins in one place.

For an ordinary run over already grounded rows, that selector-facing result content is enough. The basis pins may be direct references to the declared grouping, eligibility, and comparison basis, and the same compact record may carry the DRR/SCR-addressable audit refs required by S3. Do not require a fresh registry build, CrossingAllowance, evidence graph, assurance claim, stable public id, separate audit package, or E.24.PUB occurrence unless the current use actually needs that stronger object or claim.

Here a selector outcome means complete selector-facing result content. A stable public designator is an additional field only when a named use needs it. Neither the result content nor its designator is evidence that selection Work or an actual Select application occurred, and neither is an E.24.PUB availability occurrence. Claim actual publication only through the exact selected C.2.1 episteme edition, audience declaration, bounded-use declaration, publication form, presentation carrier, and obtaining EpistemePublicationRelation; rendering or uploading Work remains another occurrence.

If that first output cannot yet be stated honestly, the G.5 result is incomplete.

G.5 keeps the dispatcher and registry object set here and leaves universal Part-G invariants to G.Core; method-specific and generator-specific semantics stay in their named source patterns and arrive here only through explicit pins.

When applying C.11 has already produced one local choice result, applying C.19 one pool-policy result, or applying C.24 one enactment-facing next action, G.5 applies when the question becomes declaring selector-facing result content for retained alternatives, all-member joint use, or a narrowed handoff rather than one more explanation of why the upstream result looked reasonable. The G.5 result states its outcome kind, applicable public label, membership form, and basis pins directly.

The G.5 result is incomplete if its outcome kind, applicable public label, retained members or keyed joint-use member entries, ordering, named use where required, handoff content, abstain or escalation condition, or basis pins are still only implicit in upstream notes.

When a framework needs a selector-facing result for a selected pattern set, use G.5 only to declare that result: scope, selection or inclusion conditions, included pattern refs, excluded candidate refs when relevant, and basis pins. Use JointUseSet only when every exact ref is included for the named use; otherwise retain shortlist semantics. Add a stable public identity and its UTS obligation only when a named use needs them. If audience availability is current, use E.17 for a source-backed face and return to source and E.24.PUB for the publication occurrence and availability. This selected-set result does not define pattern-use relations, architecture decisions, or framework edition dependencies.

When exact framework editions are the members, preserve their existing edition identities and use E.4.PFR for any direct dependency or compatibility claim. G.5 creates no MethodRef, method-family row, publication occurrence, access claim, or actual selection Work for those editions.

#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

)

This is a positive [G.5](/generated/patterns/G.5) slice because the exact Methods, immutable row-edition refs, grouping bases, task, eligibility basis, survivors, order status, compact audit refs and next use are explicit. It needs no fresh registry row or public ShortlistId; the same local senses make F.9 crossing apparatus irrelevant; no reliance or assurance claim is being made; and no E.24.PUB availability occurrence is asserted. The record also stops before claiming dated selection Work or an actual Select application. Open those branches only if a later claim actually needs them.

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](/generated/patterns/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](/generated/patterns/C.11); if it is the policy for retaining or retiring live candidate lines, use [C.19](/generated/patterns/C.19); if it is enactment planning after choice, use [C.24](/generated/patterns/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](/generated/patterns/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.

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

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

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

#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”.

#Solution

#Causal method dispatch declarations

When method dispatch compares causal uses, each compared Method declares its causal question/rung and whether it is being used as an observational predictor, intervention optimizer, counterfactual strategy, causal fairness estimator, causal-RL policy, or simulation-only Method.

MethodFamily.causalUseDispatchSpec?:
  causalUseQuestionRef?: CausalUseQuestionRef
  targetCausalityLadderRung: CausalityLadderRung
  causalUseClaimKind: CausalUseClaimKind
  causalActionPolicyClass?: CausalActionPolicyClass
  causalSupportComponentRefs?: CausalSupportComponentRefs
  causalUseSupportResultRef?: CausalUseSupportResultRef
  causalMethodUseClassification:
    observationalPredictor |
    interventionOptimizer |
    counterfactualStrategy |
    causalFairnessEstimator |
    causalRLPolicy |
    simulationOnlyMethod
  supportedUse
  unsupportedUse

CausalUseQuestionRef identifies the question content used by C.28; it is not a durable root U-kind. causalMethodUseClassification describes the Method's proposed selector-facing use and supplies no system-role assignment, responsibility, authority, or causal certification.

A simulation-only Method cites simulationResultRef inside its support components and states bounded model use plus unsupported realized/interventional use. G.5 declares the dispatch result; C.28 supplies the causal-support result. A selector may still abstain even when a C.28 result is supported.

#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). Effective obligations, pins, and triggers are computed by union expansion of the referenced ids (per G.Core:4.2.1). Profile and set expansion is combined with explicit deltas; Nil‑elision applies.

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
  • GCoreConformanceProfileId.PartG.TriStateGuard
  • GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted
  • GCoreConformanceProfileId.PartG.ShippingBoundary

• CorePinSetIds :=

  • GCorePinSetId.PartG.AuthoringMinimal

• 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; 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 in scope)

  • MethodRef[] (exact A.3.1 Methods resolved from every method-bearing registry row in scope)

  • 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[] (audit citations for “why” and for evidence)

  • PathSliceId[] (audit citations for “why” and for evidence)

  • UTSRowId[] (published identities for selected families, registered families, and selector policy records)

  • 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 pins: TaskSignatureRef, TaskMapRef?, CGSpecRef.edition, CNSpecRef.edition, MethodFamilyRowRef[], GeneratorFamilyRowRef[]?, AcceptanceClauseId[]?, SoSLogBranchId?, FailureBehaviorPolicyId?, DescriptorMapRef.edition?, DistanceDefRef.edition?, TransferRulesRef.edition?, InsertionPolicyRef?, PathId, PathSliceId, SCRId, DRRId, RSCRTestId[])

#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; per CG‑Frame). A registry row represents a family, not a single implementation. Minimal fields (conceptual, notationally independent):

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

• EligibilityStandardRef: a typed predicate record (tri‑state per G.Core), expressed in CHR and CAL terms and pinned to the relevant editions.
• AssuranceProfileRef: evidence‑lane expectations and assurance-lane pins (SCR‑addressable).
• AdmissibilityBindings: explicit references to the single governance card and admissibility gate (CNSpecRef, CGSpecRef) and to any required admissibility constraints, for example scale and unit admissibility via CSLC.
• EvidencePins: citations to G.6 (PathId, PathSliceId) for claims or guarantees where such claims are asserted.
• 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 assurance claim or B.3 material-reliance threshold is current, use B.3's separate assurance branch instead. 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 registry row for families that generate tasks and environments, and may co-evolve solver families. G.5 carries the registry-entry shape, not the generator semantics:

• Identity and continuity: GeneratorFamilyId names the continuing row lineage; rowEdition names one immutable edition; GeneratorFamilyRowRef := <GeneratorFamilyId, rowEdition> designates that edition. UTSRowId remains its publication value.
• 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.

Changing generator members, grouping basis, or another selection-changing pin creates a new generator rowEdition; old GeneratorFamilyRowRef values continue to resolve their old editions.

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.

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.

When the current question is selector-facing set-result declaration rather than one generic registry trace, Shortlist names retained alternatives, RankedShortlist names those alternatives when the result orders them, JointUseSet names all members included for one named use, and ChoiceSet stays one mathematical gloss rather than a public result kind. ShortlistId is specific to a shortlist result; use a generic publicId for another result only when one stable public identity is needed.

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

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

#Selector Relation Fields

RegisterFamily produces only the registry row described in 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.

#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. A.10 evidence-use claims connect that trace and the boundary/runtime records to the criterion. 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.

#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 = Core@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](/generated/patterns/G.5) result.

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

SelectedSetResultLabelLine@Context:
  selectorOutcomeKind:
  setResultFamily?:
  sourceSetFamily:
  publicSelectedSetLabel?:
  namedUse?:
  memberEntries?:
  membersOrHandoff?:
  derivedViewKind?:
  basePaletteOrArchiveRef?:
  ordering:
  basisPins:
  nextUse:

Earlier records may keep membersOrHandoff. Read it as members for Shortlist or RankedShortlist and as handoffContent for a HandoffOutcome. It cannot replace keyed memberEntries in a JointUseSet; if it also lists joint-use members for compatibility, that list is only the unique set projection of the entry keys.

sourceSetFamily may name a declared Front, Q-front, ExplorationArchive, Archive, current pool subset, or derived tradition view. For retained alternatives, publicSelectedSetLabel normally names Shortlist or RankedShortlist and may use a domain label such as StyleShortlist or TraditionShortlist only when the term bridge is already clear. JointUseSet is not a shortlist label: it names an all-member result and therefore uses namedUse plus keyed memberEntries. G.5 does not create the archive, compute the comparison, govern the pool policy, decide the cultural-evolution case, establish member identity or relations, or repair the term bridge. Use [C.18](/generated/patterns/C.18) for archive formation, [A.19.CPM](/generated/patterns/A.19.CPM) for comparison, [C.19](/generated/patterns/C.19) for pool policy, [C.36](/generated/patterns/C.36) for cultural-evolution claims, each member's own identity and relation patterns for those facts, and [F.17](/generated/patterns/F.17)/[F.18](/generated/patterns/F.18)/[F.9](/generated/patterns/F.9) for local meanings, naming settlement, and any obtaining term Bridge.

#Result-declaration quick card

The smallest useful G.5 result card usually states:

• selectorOutcomeKind = SetResultOutcome | HandoffOutcome | AbstainOutcome | EscalationOutcome
• setResultFamily = Shortlist | RankedShortlist | JointUseSet when selectorOutcomeKind = SetResultOutcome
• members = ... for Shortlist or RankedShortlist
• namedUse = ... and keyed memberEntries = ... for JointUseSet
• handoffKind = SpecialistHandoff | NarrowedHandoff and handoffContent = ... when selectorOutcomeKind = HandoffOutcome
• ordering = ranked | unordered | not applicable
• publicId = ... when one public identity is emitted
• the applicable inclusion conditions and basisPins = ...
• nextUse = downstream comparison | specialist handoff | escalation | none

A short retained-alternative card may read:

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

A short all-member card may read:

selectorOutcomeKind = SetResultOutcome
setResultFamily = JointUseSet
namedUse = cohort_review
memberEntries = [
  { memberRef = Core@C },
  { memberRef = Domain@D },
  { memberRef = Local@L }
]
ordering = unordered
inclusionConditions = [all_named_editions_required]
basisPins = [choice_result_12, edition_basis_7]
nextUse = cohort_material_preparation

If the card does not state the result kind, applicable members or keyed member entries, whether order belongs to the result, the named use for joint inclusion, and the basis pins, it does not yet state a complete [G.5](/generated/patterns/G.5) result.

#Derived tradition-view result stays derived over one declared palette

• If selector work consumes one declared source set such as Front, Archive, or one source-set composition through one derived tradition view such as TraditionFront or TraditionArchive, treat that derived view as one interpretation view over one declared SoTAPaletteDescription, not as the default meaning of Tradition or of the palette itself.
• When SelectorOutcomeKind = SetResultOutcome, close with Shortlist or RankedShortlist for retained alternatives and with JointUseSet for all-member use; when SelectorOutcomeKind = HandoffOutcome, close with one SpecialistHandoff or another narrowed handoff. The derived tradition view disciplines the source, not the emitted outcome family.
• When such a derived tradition view is active, state SourceSetFamily, use DerivedViewKind when the distinction matters to interpretation or later shipping, use SourceSetComposition only when several source-set families were genuinely composed, and keep BasePaletteRef=SoTAPaletteDescriptionId recoverable alongside the emitted result.
• If the derivation depends on one declared Q or one reachability or coverage rule, cite that declared basis directly in DRR and SCR records or equivalent basis pins rather than leaving the derivation implicit.
• If no derived tradition view is active, stay with the declared palette, front, archive, or shortlist families already named by the selector record.

#Worked result-declaration closure slice

Four short contrasts keep the result-declaration closure rule practical.

Several alternatives survive, and the result does not order them. When the selector retains more than one admissible family for later choice and the declared result does not order them, G.5 should close as one Shortlist over the registered surviving rows:

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

The result orders the retained alternatives. When one ordered public handoff is required, [G.5](/generated/patterns/G.5) should say so directly instead of leaving order implicit:

RankedShortlist(
  members = [family_B, family_A],
  shortlistId = shortlist_23,
  ordering = ranked,
  basisPins = [pathSlice_77, scr_44],
  nextUse = specialist_handoff
)

Every named member is included for one use. A cohort needs three already identified framework editions together. The result is not a shortlist of alternatives:

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

The edition refs keep their existing identities; G.5 creates no Method, registry row, dependency, compatibility, publication, access, content, claim, or contribution relation. Any content or claim that supports inclusion remains in its own governed record and may be cited among the top-level basisPins.

No admissible candidate survives. When no family clears the pinned admissibility or evidence gates, [G.5](/generated/patterns/G.5) should close as one abstain or escalation result rather than as one empty shortlist pretending to be progress:

Abstain(
  blockingPins = [cg_min_evidence, crossing_bundle_missing],
  basisPins = [pathSlice_91, scr_61],
  nextUse = escalation
)

The practical distinction is simple: an internal retained subset can exist upstream without yet being a public selector result. When the current question is to state that result for downstream use, [G.5](/generated/patterns/G.5) requires the result family, applicable members or keyed member entries, ordering, named use where required, and basis pins directly in the result.

Most selector-side use can stop after G.5:4.4d. The blocks below are extension declarations used only when the corresponding mode is actually active.

All blocks below are extension declarations: they declare Uses and required pins, but do not redefine semantics already defined in the referenced patterns.

GPatternExtension block: G.5:Ext.EELog

• PatternScopeId: G.5:Ext.EELog

• GPatternExtensionId: EELog

• GPatternExtensionKind: MethodSpecific

• GoverningPatternId: [C.19](/generated/patterns/C.19)

• Uses: {[C.19](/generated/patterns/C.19)}

• ⊑ and ⊑⁺: ∅

• Required pins, edition pins, and policy pins (minimum):

  • EELensPolicyRef (or equivalent lens or policy id carried by [C.19](/generated/patterns/C.19))
  • RiskBudgetRef?
  • ProbeAccountingRef?
  • FailureBehaviorPolicyId? (if degrade behavior is governed by policy)

• RSCRTriggerKindIds: {RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.TelemetryDelta, RSCRTriggerKindId.FreshnessOrDecayEvent}

• Notes (extension discipline; semantics cited):

  • This block activates exploration and exploitation-governed dispatch.
  • Post‑2015 examples that typically land here: modern bandit‑style or Bayesian selection under explicit risk budgets; adaptive evaluation and probing regimes; safe‑exploration variants where “abstain” or “degrade” is policy-bound.

GPatternExtension block: G.5:Ext.SoSLOG

• PatternScopeId: G.5:Ext.SoSLOG

• GPatternExtensionId: SoSLOG

• GPatternExtensionKind: MethodSpecific

• GoverningPatternId: [C.23](/generated/patterns/C.23)

• Uses: {[C.23](/generated/patterns/C.23)}

• ⊑ and ⊑⁺: ∅

• Required pins, edition pins, and policy pins (minimum):

  • SoSLogRuleId[]
  • SoSLogBranchId[] (including escalation branches, if used)
  • FailureBehaviorPolicyId (if degrade behavior is made explicit)
  • MaturityRungId[]? (when maturity ladders are used as gates; semantics come from [C.23](/generated/patterns/C.23))
  • AdmissibilityLedgerRef? (when selector consumes admissibility rows rather than recomputing thresholds)

• RSCRTriggerKindIds: {RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.MaturityRungChange, RSCRTriggerKindId.EvidenceSurfaceEdit}

• Notes (extension discipline; semantics cited):

  • This block pins dispatch decisions to explicit rule and branch ids, enabling auditable “why” without inventing a fourth acceptance status.

GPatternExtension block: G.5:Ext.NQD

• PatternScopeId: G.5:Ext.NQD

• GPatternExtensionId: NQD

• GPatternExtensionKind: MethodSpecific

• GoverningPatternId: [C.18](/generated/patterns/C.18)

• Uses: {[C.18](/generated/patterns/C.18), [C.19](/generated/patterns/C.19)}

• ⊑ and ⊑⁺: ∅

• Required pins, edition pins, and policy pins (minimum):

  • DescriptorMapRef.edition
  • DistanceDefRef.edition
  • InsertionPolicyRef
  • TaskSignatureRef (when QD is enabled via TaskSignature flags or traits)
  • active fields from C.21's DHC replay basis (only when this telemetry consumes a C.21 DHC coordinate; carry exactly the fields that coordinate used)

• RSCRTriggerKindIds: {RSCRTriggerKindId.EditionPinChange, RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.TelemetryDelta, RSCRTriggerKindId.FreshnessOrDecayEvent}

• Notes (extension discipline; semantics cited):

  • G.5 core remains QD‑agnostic; QD semantics are governed by [C.18](/generated/patterns/C.18).
  • Post-2015 families that typically use this extension declaration: MAP-Elites-class QD including later archive-centric refinements, CMA-ME-class hybrids, modern illumination and coverage telemetry regimes where admissibility and edition pinning matter.

GPatternExtension block: G.5:Ext.OpenEndedFamilyWiring

• PatternScopeId: G.5:Ext.OpenEndedFamilyWiring

• GPatternExtensionId: OpenEndedFamilyWiring

• GPatternExtensionKind: GeneratorSpecific

• GoverningPatternId: [G.2](/generated/patterns/G.2)

• Uses: {[G.2](/generated/patterns/G.2), [C.19](/generated/patterns/C.19), [C.23](/generated/patterns/C.23)}

• ⊑ and ⊑⁺: ∅

• Required pins, edition pins, and policy pins (minimum):

  • GeneratorFamilyRowRef[]
  • TransferRulesRef.edition (mandatory when Open‑Ended is enabled)
  • EnvironmentValidityRegionRef?
  • CoEvoCouplerRef[]?
  • SoSLogBranchId[]? (when validity of generated tasks is gated by explicit branches)

• RSCRTriggerKindIds: {RSCRTriggerKindId.EditionPinChange, RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.TelemetryDelta, RSCRTriggerKindId.FreshnessOrDecayEvent}

• Notes (extension discipline; semantics cited):

  • This block enables declared sets of {Environment, MethodFamily} pairs without redefining generator semantics in G.5.
  • Post‑2015 examples typically referenced via [G.2](/generated/patterns/G.2) family cards: POET‑class and later open‑ended and co‑evolutionary regimes, including enhanced variants where transfer policies and validity gates must be edition‑pinned.

#Selector-facing outcome kinds

• An obtaining SelectionSlot binding carries only the by-value selected candidate set. G.5 states the separate SelectorOutcome without forcing one single winner.
• The emitted result should declare its SelectorOutcomeKind.
• SetResultFamily is required only when SelectorOutcomeKind = SetResultOutcome.
• HandoffKind is required only when SelectorOutcomeKind = HandoffOutcome; SpecialistHandoff is one handoff kind, not one set-result family head.
• Front names the non-dominated source set under the declared DominanceSet.
• Archive names the retained exploration archive under the declared retention policy.
• Shortlist names alternatives retained for later choice and does not order them.
• RankedShortlist names an ordered result over such retained alternatives.
• JointUseSet names a result whose every keyed member is included for one named use; it is not a shortlist and has no semantic entry order.
• ShortlistId is the emitted public token when a stable shortlist identity must be carried or cited; another set result may use its own generic publicId when a stable public identity is actually needed.
• ChoiceSet may be used only as a mathematical set gloss when the set object itself is under analysis; it does not replace Shortlist, RankedShortlist, or JointUseSet as the public result kind.
• PortfolioMode states how the selector operated; it does not rename the emitted set result.
• The default PortfolioMode=Archive means that an unspecified selector or generator operating mode must preserve retained exploration evidence rather than pretending one current front or selected set has already been emitted. It does not make every returned object an Archive, override SetResultFamily, or change the declared DominanceSet.
• If one selector consumes both a front and an archive, say so explicitly rather than blurring them into one generic portfolio.
• If one selector consumes one derived tradition view, keep that derived view explicit rather than silently treating it as the default meaning of Tradition.
• SetResultFamily, SourceSetFamily, SourceSetComposition, SubjectKind, DerivedViewKind, BasePaletteRef, PromotionPolicy, and RetentionIntent=steppingStone are declaration fields, refs, or policy pins around the returned outcome; they are not additional emitted set results.
• SourceSetFamily names the immediate declared source-set family.
• SourceSetComposition is used only when the selector genuinely consumed more than one source-set family such as Front and Archive.
• If that source set is one derived tradition view, keep the base palette recoverable alongside it.
• DerivedViewKind may name which derived tradition view is active when that distinction matters to interpretation or later publication.
• DerivedViewKind does not replace SourceSetFamily, SetResultFamily, or the emitted result kind.
• BasePaletteRef is one cited ref or id, not one kind.
• If one selected result comes from one declared source set, state that SourceSetFamily rather than asking the reader to infer it from one mode flag.
• PromotionPolicy is required when tie-break or telemetry signals are promoted into dominance.
• The selector may consume one declared source set and one declared choice lens without trying to explain the whole reason why another probe was worth its cost.
• When CostToProbe, ValueOfInformation, ValueOfComputation, explore_share, a direct graduation condition, or sequencing pressure matters, keep it explicit in the surrounding choice doctrine instead of smuggling them into set-result declaration fields.
• A JointUseSet uses keyed memberEntries; every exact memberRef is unique, no per-member contribution or basis field is added, and any top-level members is only the derived unique set projection of those keys.
• Well-formedness constraint: every exact framework-edition or other non-Method memberRef resolves under its existing identity; joint-use membership adds no MethodRef value or registry row for that member.
• Candidate-pool and excluded-candidate records remain separate from the emitted JointUseSet; actual choice and selection Work remain with C.11 and the applicable A.6/A.15 occurrence patterns.
• Selector-facing results should name the set-result kind, source-set kind when applicable, derived-view declaration when needed, membership form, and promotion or default declaration.
• Those selector-facing field values should use controlled tokens, cited ids, or already-declared head labels rather than selector-local prose values.

#Archetypal Grounding

Tell (archetype). The selector-bearing System must choose among rival families without lying about measurement admissibility, crossings, or evidence. The result Episteme keeps the comparison basis, audit pins, and refresh conditions recoverable. When the current result instead includes several already identified members together, the same result-content boundary must not disguise that all-member meaning as retained alternatives.

Show 1 (multi-Tradition dispatch; unordered shortlist). A CG-Frame includes multiple decision-theoretic families with different admissibility assumptions. Evidence for some CHR traits is incomplete. System registers families (S1), then runs Select (S3) on a pinned TaskSignatureRef. Eligibility is tri-state; some families receive abstain due to missing minimal-evidence pins. Among remaining candidates, only a partial order is admissible, so the selector emits one Shortlist with explicit basisPins instead of inventing one scalar winner. No shadow acceptance logic appears in the selector; it consumes pinned acceptance and admissibility records.

Show 2 (specialist handoff; ranked result). A bounded-specialization comparison keeps two method families live, but downstream handoff now requires one ordered public result rather than one merely unordered retained set. The admissible G.5 result is therefore one RankedShortlist with explicit ordering, ShortlistId, and handoff-facing nextUse, so the result makes its ordering explicit.

Show 3 (no admissible survivor; abstain or escalation). In this frame, one admissibility gate and one minimal-evidence gate fail at the same time. The truthful G.5 result is one abstain or escalation result that names the blocking pins and the next downstream use boundary, not one empty shortlist that leaves downstream users unsure whether selection silently failed or admissibly stopped.

Show 4 (complementary framework editions; unordered joint use). A training cohort needs Core@C, Domain@D, and Local@L together. The editions are already identified under their own edition rules; they are not Method candidates or registry rows. An accepted cohort decision supplies the exact members and basis. G.5-6 DeclareSetResult emits one unordered JointUseSet with one keyed entry per edition, the named cohort-review use, inclusion conditions, and sufficient top-level basis pins. Direct dependencies and pairwise compatibility claims remain with E.4.PFR; publication and access remain with E.17/E.24.PUB and the applicable access-carrier pattern. The G.5 result declares membership but does not perform the choice, make those neighboring claims obtain, or create a contribution relation.

Show 5 (support-sensitive Method eligibility).

Keep the exact admitted Methods, row editions, and grouping basis from §0.5. In a gated variant, the matching G.4 task map makes AC_InputConditionGate-E1 from G.4 §5 applicable to ThresholdTrendReviewMethod-E2. Consume that clause's value and threshold rather than define either in G.5. For the two-condition case there, the returned fail excludes that row from the assurance-gated set. Replacing its joint probability with minimum would wrongly retain it. An otherwise admissible row stays in the set under its own declared eligibility basis; if none survives, return the existing abstain or escalation outcome.

If the dependence model is missing, use the clause's unknown branch rather than pass by a high F. In the ordinary, non-assurance question of §0.5, both grounded rows still form the unordered Shortlist. A formal proof, a limited complementary study, and an overlapping contrary result can remain separate support with their limitations; neither weak additional evidence nor the absence of an unjustified common score automatically removes a Method. A defeated necessary premise still changes the eligibility that actually relies on it.

#Bias-Annotation

Potential biases and failure modes this pattern explicitly guards against:

• Monoculture bias (single Tradition dominance by default). Mitigation: registry requires explicit eligibility and assurance records; selection is set‑returning under partial orders; method‑specific policies stay explicit pins rather than hard-coded defaults.

• Hidden scalarisation bias. Mitigation: set-return semantics is pinned through G.Core; dominance regimes are explicit and each default cites one declared governing definition.

• “Tool equals method” bias. Mitigation: notation independence and prohibition of tool keywords in core registry and eligibility fields; tool choices are outside the core.

• Cross-sense leakage bias. Mitigation: when expressions have distinct source-local meanings, require exact F.17 endpoint senses, an obtaining F.9 Bridge, a separate C.2.1 bounded-use proposition, and the matching A.10 or B.3 reliance branch; keep loss and CL visible where material. Crossing pins and bundles remain audit or publication references and cannot make an implicit crossing admissible.

• Survivorship bias in refresh. Mitigation: RSCR triggers are typed and id-based; freshness, decay, and telemetry deltas are first‑class causes with canonical ids.

#Conformance Checklist (normative)

#Common Anti-Patterns and How to Avoid Them

• Anti‑pattern: “Selector as a shadow spec.” Symptom: local acceptance or admissibility rules appear in selector prose or code, diverging from CN, CG, and CAL. Avoid: govern constraint semantics through CNSpecRef and CGSpecRef plus pinned CAL records; keep G.5 core as a boundary.

• Anti‑pattern: “Implicit crossings.” Symptom: reuse across distinct source-local meanings is claimed from a shared label, Bridge or CL pin, registry row, policy, DRR or SCR line, GateCrossing, or CrossingBundle without the required relation, use, and reliance facts. Avoid: resolve the exact F.17 endpoint senses; establish the F.9 Bridge; state the separate C.2.1 <u,d,r,t,polarity> claim; require the matching A.10 disposition or B.3 assurance branch; and keep authorization and actual selector use separate. Materialize or cite a bundle only when its named downstream use requires that durable package.

• Anti‑pattern: “Hidden scalarisation.” Symptom: partial orders are flattened into single winners “for convenience”. Avoid: return declared sets; make dominance regimes explicit; keep telemetry report‑only unless promoted by explicit policy.

• Anti‑pattern: “Method specifics in the selector head.” Symptom: QD, OEE, or preference models become mandatory for basic dispatch. Avoid: keep them in G.5:Ext.* blocks with explicit pins and Uses.

• Anti‑pattern: “Churn by meaning.” Symptom: a continuing family id silently resolves different members, grouping basis, or selection pins after a row changes. Avoid: keep the lineage id only for the continuing declared grouping, publish a new immutable row edition, and carry its exact row ref through selection, result basis, refresh, and deprecation notices.

• Anti‑pattern: “Result declaration hidden in upstream reasoning.” Symptom: the retained alternatives or all-member result exist only as one implication inside C.11, C.19, or C.24, while G.5 never names the declared result kind. Avoid: declare the selected-set result directly, with its result kind, applicable members or keyed entries, ordering, named use where required, and basis pins instead of leaving it implicit upstream.

• Anti-pattern: “Shortlist used for complementary members.” Symptom: every named member is needed for one use, but the result calls them alternatives in a Shortlist. Avoid: use JointUseSet, name the joint use, and key one entry per exact member; keep direct member relations and actual selection separate.

• Anti‑pattern: “Declared result missing required content.” Symptom: a Shortlist, JointUseSet, narrowed handoff, or abstain result is named, but the emitted result still omits its members or keyed member entries, ordering, named use where required, or basis pins. Avoid: state the result kind, retained members or keyed joint-use entries, ordering, named use where required, abstain or escalation condition, and basis pins directly in G.5.

#Consequences

• Auditable plurality. Multiple Traditions can co-exist without forced semantic flattening; dispatch remains explainable and evidence-pinned.
• Core stability. Universal invariants are pinned through G.Core; method innovation and generator innovation do not churn the selector head.
• Evolvability. Registries allow growth, retirement, and refresh with typed RSCR causes and explicit payload pins.
• Composability. Strategy templates and fallbacks remain admissibility-checked and portable across implementations.
• Recoverable result content. Selected-set results can travel downstream as explicit shortlist-family, joint-use, handoff, abstain, or escalation results rather than one hidden implication inside upstream reasoning.

#Rationale

• Why registries? Reusable method-family dispatch requires stable, auditable row editions with explicit eligibility and assurance records, so later uses can recover the grouping and its dispatch basis.
• Why separation via Extensions? QD, OEE, preference-learning, and similar families are fast-moving and method-specific; making them part of the selector head would force a universal semantics and violate strict distinction.
• Why set-return? Partial orders are common and often the only admissible representation under heterogeneous scales; set-return preserves semantics and makes tie criteria explicit.
• Why explicit defaults with one declared source? Defaults are unavoidable; single-source indexing prevents competing defaults from silently diverging across patterns.
• Why selected-set result declaration here? Once the current question is to state retained alternatives or an all-member result for downstream use, the selector should declare that result directly instead of leaving it implicit in local choice, pool-policy, or enactment notes written for other purposes.
• Why JointUseSet? A shortlist preserves alternatives for later choice; an all-member result says that removing one member changes the result for the named use. G.5 mints JointUseSet only as a local SetResultFamily value and reuses the existing outcome schema and member identities. G.5-3 Select may emit it only over exact Method candidates admitted through that kernel; G.5-6 DeclareSetResult covers exact already grounded members without retyping them as Methods. Neither branch mints a new U-kind, Method kind, relation kind, or registry kind. CoUseSet is less plain, ComplementarySet would imply a relation among the members, and Bundle would misname a package form.

#SoTA-Echoing

This pattern is designed to carry extension declarations for, not redefine, post-2015 SoTA families through Uses plus edition and policy pins:

• Quality-Diversity survey currentness (2026 DOI 10.1016/j.swevo.2025.102240, ScienceDirect S2210650225003979). Survey support keeps, for example, approaches, applications, archives, diversity use, and challenges visible, but it does not replace FPF rules. If the current result is the archive or front relation itself, stop at C.18. If a later selector consumes that archive or front and uses G.5 to declare its result, keep the archive or front as the source set and emit only an admitted SelectorOutcomeKind, with an admitted SetResultFamily for a set result; state the ordering and basis pins directly instead of letting survey taxonomy rename the result.

• QD-as-MOO and archive-centric QD lines. Current QD work can produce fronts and archives under declared descriptor, distance, dominance, and comparator editions. C.18 and A.19.CPM carry those meanings. Use G.5 only when a later selector-facing declaration is current. The G.5 record cites the front or archive as its source and states one admitted selector outcome.

• Complementary portfolio and ensemble construction (Kostovska et al., 2023, PMLR 224:11/1–17; Chen et al., 2024, PMLR 235:7568–7585). Current algorithm-portfolio work selects a diverse, representative, non-redundant portfolio for a named downstream selection task, while submodels in a complementary ensemble have different contributions in combined use. G.5 adopts only the result distinction: a JointUseSet states the named use, keyed members, inclusion conditions, and sufficient top-level basis pins. It does not import portfolio or ensemble semantics, imply that members are Methods, or establish compatibility, contribution, co-enactment, or actual selection Work.

• Cultural and style selected-set labels. Music, dance, and cultural-market source rows motivate labels such as StyleShortlist or TraditionShortlist only after term bridges and cultural-evolution case meaning are clear. Such a label remains a recoverable public label over an admitted SetResultFamily; it is not another outcome family. Keep DerivedViewKind, BasePaletteRef, and SourceSetFamily visible. G.5 does not define style, tradition, canon, or platform semantics.

• Quality-Diversity and illumination (post-2015 refinements). Archive-centric QD families fit naturally as G.5:Ext.NQD extension declarations with explicit descriptor, distance, and insertion pins. The practical implication is to emit one admitted selector outcome and, for a set result, to say whether its family is Shortlist, RankedShortlist, or JointUseSet.

• Open-Endedness (post-2015 line; POET arXiv:1901.01753, AlphaEvolve arXiv:2506.13131). POET-class and later open-ended or co-evolutionary families use generator registries plus TransferRulesRef.edition pins. The practical implication is to keep pair-valued or retained members explicit inside the applicable admitted set-result family rather than silently squeezing them into one false single-family winner.

• Algorithm selection and meta-selection (Thompson sampling tutorial arXiv:1707.02038; Bayesian optimization tutorial arXiv:1807.02811). Modern selection under uncertainty, robust evaluation, and policy-driven probing use explicit policy records and typed telemetry pins, rather than hard-coded scoring rules. The practical safeguard is that the result label and basis pins must still remain explicit after those policies have acted.

• Budgeted specialist acquisition (current agentic-search source-pack pressure via G.2). Current agentic search lines compete on time or budget to threshold plus truthful selected-set return when heterogeneous specialists remain non-dominated. Treat those rows as source-pack pressure until cited by G.2; G.5 keeps specialization profiles and set-return semantics explicit instead of forcing one static breadth winner.

• Preference-learning comparators. Interactive and learned-preference regimes are treated as comparator or policy records with explicit editions when they are actually declared.

SoTA here is treated as best-known practice for a declared goal and constraint regime, not whatever is currently popular. Evidence-source clarification: peer-reviewed source references carry the most direct citation strength for typed comparison, budget-to-threshold, and truthful selected-set return. Faster-moving workshop, poster, or frontier-exploration lines remain explicit source references for specialization-entry or open-ended pressure, not silently equal evidence for every selector claim.

#Relations

Builds on (normative): G.Core (core invariants + linkage discipline).

Uses (conceptual dependencies; cited via pins and ids):

• Specification refs required by this result: A.19 (CN‑Spec), G.0 (CG‑Spec). Use A.2.6 only when a U.ClaimScope or selected U.ContextSlice changes selection, applicability, or a receiver's justified reliance; validity and evaluation windows and intended-use restrictions follow the same conditional boundary.

• Method identity and family grouping: A.3.1 for every exact selectable U.Method; A.3.2 only for the same C.2.1 episteme that substantively describes one already admitted Method; and C.2.1 or the defining declaration or pattern for the family relation cited by a registry row. G.5 creates none of those source facts.

• Method composition and selected organization: B.1.5 for the complete composite-Method qualification, A.22 for an independently selected organization that does not constitute one Method, and C.29 for algebraic, graph, matrix, embedding, neural, or other representation-lens use. G.5 consumes exact resulting references and does not construct them.

• Upstream object sets: G.1 (CG‑Frame Card), G.2 (SoTA Pack), G.3 (CHR Pack), and G.4 (CAL Pack). C.22 alone constitutes the TaskSignature. When G.4 CAL gates are current, G.5 additionally consumes the exact TaskMapRef that relates that same TaskSignatureRef to one exact charter and the cited CAL declarations; otherwise the map is absent.

• Evidence and crossings: G.6 for EvidenceGraph citations; F.17 for exact local senses; F.9 for the direct Bridge; C.2.1 for the separate bounded-use proposition; and A.10 or B.3 for reliance or assurance. Add a CrossingBundle under E.18 or a GateCheck under A.21 only when that named downstream use requires one. A G.7 calibration artifact remains a cited policy or evidence input; it does not define the Bridge, bounded use, reliance, or selector actuality.

• Planning and enactment boundary: A.15.2 identifies the U.WorkPlan used as plannedBaselineRef; A.15.3 defines any planned-filling rows kept inside that WorkPlan. G.5 does not redefine them.

• Actual selector use and result availability: A.19.SelectorMechanism and A.6.1 for the actual Select application and bindings; A.13 for every precise performer's local-kind criterion, classification, same obtaining assignment, scope, situation, window, and evidence; A.15.1 for independent Work admission; A.2.1 for the assignment species and occurrence; and F.6 only for a current exact assignment-bound attribution. C.2.1 governs any persisted result episteme; A.10 and B.3 govern evidence reliance and assurance; the direct authority pattern governs authorization; and E.24.PUB governs an actual publication occurrence. A root-family assignment reference, temporal overlap, or omission from short wording supplies no attribution and removes no world-side fact. G.5 declarations and records create none of those neighboring facts.

• Joint-use members outside Method dispatch: the direct identity pattern identifies every memberRef; C.11 supplies a local choice result when one is current; another accepted decision or governed inclusion basis may establish all-member inclusion; E.4.PFR states framework-edition dependency or pairwise compatibility separately; G.11 supplies currentness; and E.17/E.24.PUB plus the applicable access-carrier pattern supply exposure and source return. G.5-6 DeclareSetResult consumes the exact members and sufficient basis pins and emits only the selector-facing membership result.

• Causal-use method dispatch: C.28 when method selection involves causal effect, counterfactual comparison, causal fairness, causal policy, causal RL, or simulation-only causal-use claims.

• Optional Method or generator extensions through G.5:Ext.*: C.18, C.19, C.23, plus extension-bearing patterns whose exact Part G admission relation is established when they add extra selector pins.

• Mathematical-lens use: apply C.29 when a selector input depends on a mathematical object or mapping whose use is not yet recoverable—for example, a comparator, distance, descriptor geometry, embedding, normalization, surrogate model, learned representation, QD archive descriptor, model-family label, or model-selection basis. For claim-bearing lens use, recover that object's mapping mode, preserved or lost structure, and stop condition. A LensCandidateNote may instead retain the recognition and next-action account while CandidateMathObject? remains unresolved. The recorded result is a C.29 lens-use result; non-exhaustive examples include no lens use, a lens-candidate note, a one-line note, a mini-card, a full card, or a note naming the applicable pattern for the stated selector use. That result does not declare a selector result or its supporting records, such as the selected set, selector policy, registry row, shortlist, ranked shortlist, or selector evidence pins; use G.5 for those objects and cite the exact references used.

Provides to: downstream uses such as G.6 audit citations, RSCR emission records with typed triggers and payload pins, and packs shipped through G.10. When a named use needs stable public identity, publish the required family ids, selector policy records, or selected-set identities—such as ShortlistId—to UTS under the applicable identity rule.

Coordinates with: C.11 for local choice results; E.4.PFR for direct framework-edition dependency and pairwise compatibility claims; G.11 for edition currentness; E.17 for a source-backed publication face and return to source; E.24.PUB for a publication occurrence and audience availability; C.19 for pool-policy records; C.32.P2S when a selected-set result declaration feeds architecture problem-to-structure carry-through; C.35 when a generated or discovered structure-bearing output is not yet a selector-facing result; C.24 for enactment-facing next-action records; and C.18 when a Front or Q-front is the source set for a G.5 use.

A Q-front stays a C.18 source set; it is not the emitted G.5 outcome or a SetResultFamily. The G.5 result states one admitted SelectorOutcomeKind; a set result also states Shortlist, RankedShortlist, or JointUseSet, and any public selected-set label resolves to that family.

Architecture discovery boundary: when a generated or discovered structure-bearing output is only a representation or carrier—for example, a description, query result, graph, cluster, or search trace—use C.35 before G.5. Use G.5 only when the live claim is declaration of selected-set result content with selector-policy and selected-set identity; stable public identity and actual publication remain conditional neighboring branches.

#G.5:End

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)