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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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