#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-memory 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. Govern the dispatcher/registry object set for rival method families and publish selector-facing retained-set outcomes without collapsing plurality into one hidden scalar winner.

• several method families or generator families can lawfully act on the same declared task family or work target
• you need one selector to return a Shortlist, RankedShortlist, one SpecialistHandoff, one other narrowed handoff plan, or one abstain outcome without pretending that there is always one scalar winner
• the published result must carry enough basis pins to support later comparison, handoff, or escalation without changing its declared outcome kind or any applicable public selected-set label

#Keywords

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

#Relations

#Content

#Use this when

• several method families or generator families can lawfully act on the same declared task family or work target
• you need one selector to return a Shortlist, RankedShortlist, one SpecialistHandoff, one other narrowed handoff plan, or one abstain outcome without pretending that there is always one scalar winner
• the published result must carry enough basis pins to support 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 lawful
• selected-set publication gets hidden inside C.11, C.19, or C.24, so the published result no longer makes clear whether it carries local choice, pool policy, enactment, or publication
• 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 can publish candidate sets, Shortlist, RankedShortlist, one SpecialistHandoff, narrowed handoff plans, or abstain outcomes honestly
• one DRR/SCR-addressable trace with explicit basis pins instead of one hidden selector rationale
• one explicit publication closure so the declared outcome kind, any applicable public selected-set label, retained members or handoff content, ordering status, and basis pins are stated directly in the emitted result

Registry and dispatch remain the primary governed question here; selected-set publication is the explicit closure record for that selector question, not a replacement for it.

#First-minute questions

• What selector outcome kind is this result actually emitting: one set-surface outcome such as Shortlist or RankedShortlist, one SpecialistHandoff or other narrowed handoff, or one abstain outcome?
• Which members are being retained or excluded now?
• Does order materially belong to the published result?
• Which basis pins or policy pins must the published result carry?

#First output

The first useful output from this dispatcher/registry question is one published selector outcome: one set-surface outcome such as Shortlist or RankedShortlist, one SpecialistHandoff or other narrowed handoff plan, or one abstain/escalation result, with the outcome kind, any public selected-set label, retained members or handoff content, ordering status when relevant, and basis pins stated in one place.

If that first output still cannot be written honestly, the current publication result is not finished G.5 publication yet.

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

When C.11 has already emitted one local choice result, C.19 one pool-policy posture, or C.24 one enactment-facing next move, G.5 begins where the question becomes selector-facing publication of the retained set or narrowed handoff result rather than one more explanation of why the result looked reasonable. A conformant G.5 pass should therefore publish the retained set, narrowed handoff, or abstain result directly, with its declared outcome kind, any applicable public selected-set label, and basis pins explicit in the result itself.

A publication result remains unfinished if the declared outcome kind, any applicable public selected-set label, retained members or handoff content, ordering status, abstain or escalation condition, or basis pins are still only implicit in upstream notes.

#Problem frame

A CG‑FrameContext (from G.1) and a SoTA Synthesis Pack@CG‑Frame (from G.2) expose multiple rival, internally coherent method families (and sometimes generator families) that can plausibly act on the same describedEntity / ReferencePlane.

At the same time, the typed slot/scale/coordinate definitions from G.3/G.4 yield admissible calculi and acceptance clauses—enough to formulate eligibility, assurance, and legality constraints, but not enough to pick “the method” without collapsing plurality.

You need a notation‑independent way to:

1. register method/generator families as auditable, versioned entries,
2. select/compose/fallback among them at run time for a concrete task instance,
3. publish stable selected-set results and stable identities to UTS, and
4. emit RSCR‑relevant triggers and pins without inventing new “shadow specs”.

#Problem

How to design a general, auditable dispatcher that:

• supports 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;

• respects Context boundaries and crossing discipline (Bridge‑only; explicit pins);

• produces set‑valued outcomes when only partial orders are lawful;

• cleanly separates:

  • selector object set/components (registry + selector facade + publication records),
  • universal Part‑G invariants (carried by G.Core),
  • method/generator specifics (wired only via Extensions blocks).

#Forces

• Pluralism vs. forced totalisation. Many selection regimes are inherently partial‑order; forcing a scalar winner often creates illegal semantics.
• Evidence realism vs. hard gates. Eligibility/acceptance frequently depends on incomplete evidence; selection must remain auditable under tri‑state unknowns.
• Reuse vs. leakage. Cross‑Context reuse is valuable but must be explicit (Bridge + loss notes) and must not silently re‑ground semantics.
• Exploration vs. exploitation. Dispatch sometimes must probe alternatives under explicit policy/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

Method selection involving causal methods must declare whether a compared method is an observational predictor, an intervention optimizer, a counterfactual strategy, a causal fairness estimator, a causal-RL policy, or a simulation-only method.

Optional MethodFamily.causalUseDispatchSpec?:

MethodFamily.causalUseDispatchSpec? {
  causalUseQuestionRef?: U.CausalUseQuestion
  targetCausalityLadderRung: CausalityLadderRung
  causalUseClaimKind: CausalUseClaimKind
  causalActionPolicyClass?: CausalActionPolicyClass
  causalEvidenceSupportBasis?: CausalEvidenceSupportBasis
  causalUseSupportRecordRef?: CausalUseSupportRecordRef
  causalUseSupportVerdict?: CausalUseSupportVerdict
  causalMethodComparisonPosture:
    observationalPredictor |
    interventionOptimizer |
    counterfactualStrategy |
    causalFairnessEstimator |
    causalRLPolicy |
    simulationOnlyMethod
  supportedUse: CausalUseSupportStatement
  unsupportedUse: CausalUseUnsupportedStatement
}

causalMethodComparisonPosture is a selector-facing method-comparison classification, not a U.Role, role assignment, responsibility, or actor position. simulationOnlyMethod maps to CausalEvidenceSupportBasis = simulationOnlyCounterfactualOutputBasis, bounded simulation-supported use, and unsupported intervention-effect or realized-counterfactual-sample use unless another C.28 support basis is cited.

What changes in practice: a selector must not compare "methods that improve outcome" unless each causal method declares the causality-ladder rung, causal method comparison posture, and C.28 support record/verdict when causal-use support is being consumed.

What this does not authorize: G.5 does not identify causal effects, decide fairness, certify off-policy causal evaluation, or compare cross-rung causal methods as one undifferentiated improvement set; it keeps method dispatch and selected-set publication while C.28 governs causal-use support.

#G.Core linkage (normative)

Builds on: G.Core (Part‑G core invariants; single-source default routing)

GCoreLinkageManifest (normative; size‑controlled via profiles/sets). Effective obligations/pins/triggers are computed by union expansion of the referenced ids (per G.Core:4.2.1). Profiles/sets + explicit deltas; Nil‑elision applies.

• CoreConformanceProfileIds :=

  • GCoreConformanceProfileId.PartG.AuthoringBase
  • GCoreConformanceProfileId.PartG.TriStateGuard
  • GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted
  • GCoreConformanceProfileId.PartG.ShippingBoundary

• CorePinSetIds :=

  • GCorePinSetId.PartG.AuthoringMinimal
  • GCorePinSetId.PartG.CrossingVisibilityPins (crossing‑aware use; pins from this set may be intentionally strengthened (optional→required) via CorePinsRequired)

• CorePinsRequired := (delta over PinSets; pins/refs are id‑only; prefer strengthening optional→required over restating pins already covered by PinSets)

  • TaskSignatureRef (see G.5:4.2 / S2)
  • MethodFamilyId[] (registry keys in scope)
  • GeneratorFamilyId[]? (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/registered families and selector policy records)
  • FailureBehaviorPolicyId? (only when degrade/abstain behavior is explicitly policy‑bound)
  • SoSLogBranchId? (only when degrade/abstain behavior is explicitly policy‑bound)

• DefaultsConsumed :=

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

• RSCRTriggerSetIds :=

  • GCoreTriggerSetId.RefreshOrchestration (payload pins: TaskSignatureRef, CGSpecRef.edition, CNSpecRef.edition, MethodFamilyId[], GeneratorFamilyId[]?, AcceptanceClauseId[]?, SoSLogBranchId?, FailureBehaviorPolicyId?, DescriptorMapRef.edition?, DistanceDefRef.edition?, TransferRulesRef.edition?, InsertionPolicyRef?, PathId, PathSliceId, SCRId, DRRId, RSCRTestId[])

#Dispatcher & 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: MethodFamilyId, ContextId, lineage/Tradition notes, UTSRowId (twin labels where applicable).
• EligibilityStandardRef: a typed predicate record (tri‑state per G.Core), expressed in CHR/CAL terms and pinned to the relevant editions.
• AssuranceProfileRef: evidence‑lane expectations and assurance-lane pins (SCR‑addressable).
• LegalityBindings: explicit references to the single governance card and legality gate (CNSpecRef, CGSpecRef) and to any required legality constraints (e.g., scale/unit legality via CSLC).
• EvidencePins: citations to G.6 (PathId/PathSliceId) for claims/guarantees where such claims are asserted.
• CrossingAllowance: explicit Bridge/CL allowance pins only if cross‑Context operation is claimed.
• PolicyHooksRef?: optional pointers to policy records (not defined here; wired via Extensions).

S1′ — GeneratorFamily Registry (design‑time; optional; per CG‑Frame). A registry row for families that generate tasks/environments and/or co‑evolve solver families. G.5 carries the registry-entry shape, not the generator semantics:

• Identity: GeneratorFamilyId, ContextId, UTSRowId.
• GeneratorSignatureRef: conceptual I/O and budget semantics.
• EnvironmentValidityRegionRef?: pinned constraints for generated environments/tasks.
• TransferRulesRef.edition?: required when the Open-Ended mode is enabled (semantics come from the cited extension refs).
• CouplerRefs?: which MethodFamilyId[] can be coupled with this generator family.

S2 — TaskSignature façade (design‑time + run‑time). A minimal typed record the dispatcher consumes. Its role is pinning and auditability, not over‑specification. It must be CHR/CAL‑typed and provenance‑aware. G.5 treats TaskSignatureRef as an input record; it does not define CHR/CAL semantics.

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

• consumes TaskSignatureRef + registry entries + pinned spec refs,
• applies eligibility/assurance gating (tri‑state),
• computes a lawful (possibly partial) order,
• returns one declared selector outcome: most often one set-surface outcome such as Shortlist or RankedShortlist, but sometimes one SpecialistHandoff, one other narrowed handoff, one abstain outcome, or one escalation outcome (per DefaultId.PortfolioMode and explicit overrides),
• emits audit records (DRR/SCR‑addressable pins).

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 publish 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 kernel type and not a generic narrative profile. G.5 carries this selector-time specialization question here; it does not re-own 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 published result is one heterogeneous handoff bundle whose members occupy different specialization roles that still need to travel together. Do not use it when one ordinary Shortlist, RankedShortlist, ExplorationArchive, or another narrower named result 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 small admissible set 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 & fallbacks templates (design‑time). A library of composition shapes (preconditioner → solver → verifier; cascades; meta‑selectors) as templates, legality‑checked and pinned. Concrete strategy semantics stay in the referenced method families; G.5 only carries the composition template.

S5 — Publication & telemetry interface (run‑time). A standard publication interface to publish:

• DRR (decision rationale) + SCR (support/confidence routing) with explicit pins,
• declared selector / selected-set records,
• telemetry pins to refresh orchestration (G.11), without owning orchestration.

When the current publication question is selected-set publication rather than one generic registry trace, Shortlist is the public selected-set label, RankedShortlist is the ordered specialization when order materially belongs to the published result, ShortlistId is the emitted public identity, and ChoiceSet stays one mathematical gloss rather than the public selected-set label.

S6 — Governance & evolution interface (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/dispatch stays one generic selector head. Narrower selector families may refine it, but they do not redefine the universal invariants routed via G.Core, do not add hidden mandatory inputs beyond pinned policy or edition refs, and do not mutate SlotKinds.

Method- and generator-specific pressures such as QD archives, open-ended declared sets, explore/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.

#Interfaces (minimal I/O record)

#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 abstain.
• A lawful G.5 result therefore publishes a set-return shortlist or a narrowed handoff plan, with DRR/SCR 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.
• When one upstream C.19 pass has already narrowed the live pool to one internal retained subset over registered families, G.5 may publish that result as one Shortlist with one ShortlistId and explicit basis pins only when selector-facing publication is now the question. Until that emission occurs, the internal retained subset is not yet one public shortlist result.
• When one upstream C.11 pass has already fixed one local choice over one declared source surface, or one C.24 pass has already produced one enactment-facing narrowed handoff, G.5 may publish the selected-set or narrowed-handoff result only when selector-facing publication is now the question. Until this G.5 emission occurs, the ChoiceResult, CallPlan, or CheckpointReturn is not itself one public Shortlist, RankedShortlist, or ShortlistId-bearing result.

#Published selected-set result and closure rule

A finished G.5 pass should publish one explicit selected-set result from the dispatcher/registry question rather than one selector trace that leaves the public result implicit.

Publication here is the closure record for selector work over registered families. It does not replace registry maintenance, dispatcher comparison law, or the upstream pool-policy and local-choice pattern authorities that supplied the retained members.

The lawful selector outcome families here are:

• SelectorOutcomeKind = SetSurfaceOutcome, with SetSurfaceKind = Shortlist when one retained set is published without one material internal order and SetSurfaceKind = RankedShortlist when ordering materially belongs to the result;
• 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;
• SelectorOutcomeKind = EscalationOutcome when no admissible candidate exists and the truthful result is one escalation.

SetSurfaceKind belongs only inside SetSurfaceOutcome. Shortlist and RankedShortlist are public selector results over registered rows. They are not merely one upstream internal retained subset copied forward under one prettier label. G.5 is the governing pattern that turns selector state into one public result with one explicit outcome kind, one explicit selected-set label when applicable, one explicit member set or handoff content, and one explicit basis-pin set.

A publication result should state at least these fields:

• the selector outcome kind being emitted;
• the public selected-set label when the outcome is one set-surface outcome;
• retained members, or the narrowed handoff content, or the abstain/escalation condition;
• ordering status when ordering matters;
• basis pins and policy pins sufficient to justify the result;
• one explicit next downstream use posture when the result is a handoff rather than one terminal publication.

A compact result may therefore look like:

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

or:

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

Close as SelectorOutcomeKind = SetSurfaceOutcome with SetSurfaceKind = Shortlist when several retained members survive lawfully but no public internal order belongs to the result. Close as SelectorOutcomeKind = SetSurfaceOutcome with SetSurfaceKind = RankedShortlist when order materially belongs to the published result. Close as SelectorOutcomeKind = HandoffOutcome with HandoffKind = SpecialistHandoff or one other narrowed handoff when heterogeneity itself is the truthful downstream surface. Close as SelectorOutcomeKind = AbstainOutcome or EscalationOutcome when no admissible candidate exists under the pinned constraints.

If the publication still does not state what public result was emitted, who remained in it, whether order belongs to it, and which pins justify it, then the selector has not yet published one finished G.5 result.

#Publication quick card

The smallest useful G.5 publication card usually states:

• selectorOutcomeKind = SetSurfaceOutcome | HandoffOutcome | AbstainOutcome | EscalationOutcome
• setSurfaceKind = Shortlist | RankedShortlist when selectorOutcomeKind = SetSurfaceOutcome
• handoffKind = SpecialistHandoff | NarrowedHandoff when selectorOutcomeKind = HandoffOutcome
• membersOrHandoff = ...
• ordering = ranked | unordered | n/a
• publicId = ... when one public identity is emitted
• basisPins = ...
• nextUse = downstream comparison | specialist handoff | escalation | none

A short lawful card may therefore read:

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

If the card does not already state what was published, who survived, whether order belongs to the result, and which pins justify it, the publication is still unfinished G.5 work.

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

• If selector work consumes one declared source surface such as Front, Archive, or one source-surface composition through one derived tradition view such as TraditionFront or TraditionArchive, treat that derived view as one interpretation layer over one declared SoTAPaletteDescription, not as the default meaning of Tradition or of the palette itself.
• When SelectorOutcomeKind = SetSurfaceOutcome, the public selected-set label still closes as Shortlist or RankedShortlist; when SelectorOutcomeKind = HandoffOutcome, the result closes as one SpecialistHandoff or one other narrowed handoff. The derived tradition view disciplines the source, not the emitted outcome family.
• When such a derived tradition view is active, publish SourceSurfaceKind, use DerivedViewKind when the distinction matters to interpretation or later shipping, use SourceSurfaceComposition only when several source-surface families were genuinely composed, and keep BasePaletteRef=SoTAPaletteDescriptionId recoverable alongside the emitted result.
• If the derivation depends on one declared Q or one reachability/coverage rule, cite that declared basis directly in DRR/SCR 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 publication closure slice

Three short contrasts keep the publication law practical.

Several survivors, no public order belongs to the result. When the selector has retained more than one lawful family but no downstream public order belongs to the published result, 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
)

Order now materially belongs to the published result. When one ordered public handoff is required, 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
)

No admissible candidate survives. When no family clears the pinned legality or evidence gates, 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 remain real upstream without yet being one public selector result. G.5 begins only when that selector-facing publication question starts, and it closes only after the declared outcome kind, any applicable public selected-set label, surviving members or handoff content, and basis pins are emitted directly.

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

• SemanticOwnerPatternId: C.19

• Uses: {C.19}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • EELensPolicyRef (or equivalent lens/policy id carried by C.19)
  • RiskBudgetRef?
  • ProbeAccountingRef?
  • FailureBehaviorPolicyId? (if degrade behavior is routed through policy)

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

• Notes (extension discipline; semantics cited):

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

GPatternExtension block: G.5:Ext.SoSLOG

• PatternScopeId: G.5:Ext.SoSLOG

• GPatternExtensionId: SoSLOG

• GPatternExtensionKind: MethodSpecific

• SemanticOwnerPatternId: C.23

• Uses: {C.23}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (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)
  • 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/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

• SemanticOwnerPatternId: C.18

• Uses: {C.18, C.19}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • DescriptorMapRef.edition
  • DistanceDefRef.edition
  • InsertionPolicyRef
  • TaskSignatureRef (when QD is enabled via TaskSignature flags/traits)
  • DHCMethodRef.edition? (when diversity/coverage telemetry is pinned to a DHC method)

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

• Notes (extension discipline; semantics cited):

  • G.5 core remains QD‑agnostic; QD semantics are routed to C.18.
  • Post‑2015 families that typically dock here: MAP‑Elites‑class QD (incl. later archive‑centric refinements), CMA‑ME‑class hybrids, modern illumination/coverage telemetry regimes where legality and edition pinning matter.

GPatternExtension block: G.5:Ext.OpenEndedFamilyWiring

• PatternScopeId: G.5:Ext.OpenEndedFamilyWiring

• GPatternExtensionId: OpenEndedFamilyWiring

• GPatternExtensionKind: GeneratorSpecific

• SemanticOwnerPatternId: G.2

• Uses: {G.2, C.19, C.23}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • GeneratorFamilyId[]
  • 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 family cards: POET‑class and later open‑ended/co‑evolutionary regimes, including enhanced variants where transfer policies and validity gates must be edition‑pinned.

#Selector-facing outcome kinds

• SelectionSlot returns one selector outcome, not one forced single winner.
• The emitted result should declare its SelectorOutcomeKind.
• SetSurfaceKind is required only when SelectorOutcomeKind = SetSurfaceOutcome.
• HandoffKind is required only when SelectorOutcomeKind = HandoffOutcome; SpecialistHandoff is one handoff kind, not one set-surface head.
• Front names the non-dominated source surface under the declared DominanceSet.
• Archive names the retained exploration surface under the declared retention policy.
• Shortlist names the lens-declared selected surface emitted from SelectionSlot.
• RankedShortlist names one ordered specialization of that shortlisted surface.
• ShortlistId is the emitted public token when the shortlist must be carried or cited as one named object.
• ChoiceSet may be used only as the mathematical set gloss for that shortlist when the set object itself is under analysis; it does not replace the public shortlist head.
• PortfolioMode states how the selector operated; it does not rename the emitted set surface.
• The default PortfolioMode=Archive means that an unspecified selector/generator posture must preserve retained exploration evidence rather than pretending one current front or selected shortlist has already been emitted. It does not make every returned object an Archive, does not override SetSurfaceKind, and does not 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.
• SetSurfaceKind, SourceSurfaceKind, SourceSurfaceComposition, SubjectKind, DerivedViewKind, BasePaletteRef, PromotionPolicy, and RetentionIntent=steppingStone are declaration fields, refs, or policy pins around the returned outcome; they are not additional emitted set surfaces.
• SourceSurfaceKind names the immediate declared source-surface family.
• SourceSurfaceComposition is used only when the selector genuinely consumed more than one source-surface family such as Front+Archive.
• If that source surface 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 SourceSurfaceKind, SetSurfaceKind, or Shortlist.
• BasePaletteRef is one cited ref/id, not one kind.
• If one selected result comes from one declared source surface, publish that SourceSurfaceKind 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 surface 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, backstop_confidence, or sequencing pressures matter, keep them explicit in the surrounding choice doctrine instead of smuggling them into set-surface labels.
• Selector-facing results should name the set-surface kind, source-surface kind, derived-view declaration when needed, the emitted shortlist family, and promotion/default routing.
• 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). System must choose among rival families without lying about measurement legality, crossings, or evidence. Episteme insists that what is chosen must remain comparable, auditable, and stable under refresh.

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 abstain due to missing minimal-evidence pins. Among remaining candidates, only a partial order is lawful, so the selector publishes one Shortlist with explicit basisPins instead of inventing one scalar winner. No shadow acceptance logic appears in the selector; it consumes pinned acceptance and legality records.

Show 2 (specialist handoff; ranked publication). 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 lawful G.5 result is therefore one RankedShortlist with explicit ordering, ShortlistId, and handoff-facing nextUse, so the publication itself states whether the order is public.

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

#Bias-Annotation

Potential biases and failure modes this pattern explicitly guards against:

• Monoculture bias (single Tradition dominance by default). Mitigation: registry requires explicit eligibility/assurance surfaces; 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 core‑routed; dominance regimes are explicit and default routing is singular and declared.
• “Tool equals method” bias. Mitigation: notation independence + prohibition of tool keywords in core registry/eligibility fields; tool choices are outside the core.
• Cross‑Context leakage bias. Mitigation: explicit crossing pins only; Bridges + CL are required when crossings occur; no implicit crossings.
• Survivorship bias in refresh. Mitigation: RSCR triggers are typed/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/legality rules appear in selector prose/code, diverging from CN/CG/CAL. Avoid: route all contract semantics via CNSpecRef/CGSpecRef and pinned CAL records; keep G.5 core as a facade.

• Anti‑pattern: “Implicit crossings.” Symptom: cross‑Context reuse is claimed without Bridge/CL pins, or without cited CrossingBundle. Avoid: require explicit crossing pins; block consumption without publication.

• 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/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: registry entries are “renamed” to reflect updated interpretation, breaking continuity. Avoid: version/deprecate; keep stable ids; use explicit edition pins and deprecation notices.

• Anti‑pattern: “Publication hidden in upstream reasoning.” Symptom: the retained set exists only as one implication inside C.11, C.19, or C.24, while G.5 never names the published selected-set label. Avoid: publish the selected-set result directly, with explicit label, members, and basis pins, instead of leaving the shortlist implicit in neighboring doctrine.

• Anti‑pattern: “Published result without closure record.” Symptom: a Shortlist, narrowed handoff, or abstain result is named, but the emitted result still does not state its members, ordering status, or basis pins. Avoid: publish the head, retained members, ordering status, 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 routed via G.Core; method/generator innovation does not churn the selector head.
• Evolvability. Registries support growth, retirement, and refresh with typed RSCR causes and explicit payload pins.
• Composability. Strategy templates and fallbacks remain legality-checked and portable across implementations.
• Recoverable publication. Selected-set results can now travel downstream as explicit shortlist-family, ranked-shortlist, or abstain/escalation results rather than one hidden implication inside upstream reasoning.

#Rationale

• Why registries? Dispatch requires stable, auditable family objects with explicit eligibility and assurance records; otherwise selection collapses into ad-hoc tooling.
• 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 lawful 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 publication here? Once the current question is to publish one retained set for downstream use, the selector should publish that result directly instead of leaving it implicit in local choice, pool-policy, or enactment notes written for other purposes.

#SoTA-Echoing

This pattern is designed to host (not redefine) post-2015 SoTA families via Uses plus edition and policy pins:

• Quality-Diversity / 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 keep publication honest about whether the selector is returning one lawful set, one ranked result, or no admissible survivor at all.

• Open-Endedness (post-2015 line). POET-class and later open-ended or co-evolutionary families dock via generator registries plus TransferRulesRef.edition pins. The practical implication is to publish pair- or retained-set-shaped results explicitly rather than silently squeezing them into one false single-family winner.

• Algorithm selection and meta-selection. Modern selection under uncertainty, robust evaluation, and policy-driven probing dock via explicit policy records and typed telemetry pins, rather than hard-coded scoring rules. The practical safeguard is that the publication label and basis pins must still remain explicit after those policies have acted.

• Budgeted specialist acquisition. Current agentic search lines compete on time or budget to threshold plus truthful selected-set return when heterogeneous specialists remain non-dominated, so 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-tier clarification: peer-reviewed anchors carry the strongest support for typed comparison, budget-to-threshold, and truthful selected-set return. Faster-moving workshop, poster, or frontier-exploration lines remain explicit support 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/ids):

• Contract-bearing spec refs: A.19 (CN‑Spec), G.0 (CG‑Spec).
• Upstream object sets: G.1 (CG‑Frame Card), G.2 (SoTA Pack), G.3 (CHR Pack), G.4 (CAL Pack).
• Evidence & crossings: G.6 (EvidenceGraph; PathId/PathSliceId), G.7 (Bridge/CL calibration), E.18/A.21 (CrossingBundle/GateChecks).
• Planning/enactment boundary: A.15.3 (SlotFillingsPlanItem) as the planned baseline anchor (cited, not redefined).
• 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/generator extensions via G.5:Ext.*: C.18, C.19, C.23, plus any future extension-bearing patterns that add extra selector pins.

Publishes to: UTS (family ids, selector policy records, and selected-set identities such as ShortlistId when one public result is emitted), G.6 (audit citations), RSCR emission records (typed triggers + payload pins), and downstream packs via G.10 shipping surfaces.

Coordinates with: C.11 for local choice results, C.19 for pool-policy records, C.24 for enactment-facing next-move records, and the accepted Q-Front shortlist-family continuity line when the published selected-set label is one shortlist-family result.

#G.5:End