#Part G - Discipline SoTA Patterns Kit

Preface node heading:part-g-discipline-sota-patterns-kit:100737

#What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

#Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

#Content

#G.Core - Part G Core Invariants

Tag. Architectural pattern (Part‑G core invariants hub; refactoring/deduplication) Stage. design‑time (authoring discipline + ID‑stable citation discipline; no run‑time mechanism) Primary hooks. E.8 (pattern template), E.10 (lexical/ontological rules), E.19 (conformance discipline), A.6.7 (SuiteObligations + suite protocol pins), A.15.3 (planned baseline), A.19 (CN‑Spec), G.0 (CG‑Spec), A.19.CHR (CHR suite boundary), C.23 (SoS‑LOG), F.17 (UTS), F.15 (RSCR).

Status. Stable Placement. Part G core section before G.0 (without renumbering G.0…G.13). Normativity. Normative unless explicitly marked informative

Purpose. Provide one governing definition for Part‑G‑wide invariants (delegation-first citation and change-control discipline), plus a typed RSCR trigger kind catalogue and a Default Governing Definition Index, so Part G can be refactored without semantic drift or public‑ID breakage.

Phase‑2 constraint. G.Core is the only new Part‑G pattern introduced in Phase‑2; discipline/method/generator specifics remain in G.x as Extensions, citations to existing governing patterns, or Phase‑3 seeds (appendix) without new Phase‑2 norms.

Post‑Phase‑2 evolvability policy. The Phase‑2 restriction above is historical. From Phase‑3 onward, new Part‑G PatternIds are permitted when (i) they introduce a genuinely new kit/pack class (typically levels G.2–G.5), or (ii) they are required to preserve one governing pattern per wiring extension and wiring-only separation. Method/discipline/generator specifics SHOULD still default to GPatternExtension modules under G.x:Extensions (scoped by PatternScopeId = G.x:Ext.* and GoverningPatternId), rather than adding new Part‑G patterns.

#G.Core:1 - Problem frame

Part G contains patterns for CG‑frame characterization and its downstream artefacts (cards, evidence graphs, bridge surfaces, refresh/shipping orchestration, parity harnesses, dashboards, interop surfaces). In the current spec, several invariants are already present as suite obligations/protocol norms and are reused across Part G.

Part‑G‑wide invariants are governed by G.Core so every G.x can:

• cite the core invariants rather than restating them, and
• isolate pattern-scoped specifics as Extensions without turning each G.x into a mixed bag of universal rules, kit surfaces, and method/generator descriptions.

This pattern (G.Core) therefore acts as the deduplication hub for FPF Part G.

#G.Core:2 - Problem

Without one governing definition for Part‑G‑wide invariants, Part G drifts in at least six recurring ways:

1. Shadow governing spec refs emerge: downstream patterns restate CN‑Spec / CG‑Spec constraints, accidentally creating “local specs” that can diverge from the canonical governing spec refs.
2. Crossing discipline becomes inconsistent: “crossing events” and “crossing visibility” are described differently across G.x, causing ambiguity about what must be pinned (UTS/Path/policy‑ids/editions) and what triggers refresh/regression.
3. Guard semantics drift: tri‑state eligibility and “unknown handling” can be reinterpreted in local prose, producing hidden fourth statuses or implicit coercions.
4. Hidden scalarization appears: partial orders are silently collapsed into scalars, or totalization is introduced implicitly through “helpful” numeric summaries.
5. Suite/kit/pack mixing blurs governing-definition assignment: downstream patterns drift into “governing” what should remain governed by the suite boundary (A.6.7 and A.19.CHR), kit surfaces (each G.x), or shipping (G.10).
6. Refactoring breaks public IDs: CC items and trigger labels become hard to evolve because removing duplicates risks breaking external references.

Part G requires a single place where these invariants and refactoring disciplines live, while keeping Part G patterns modular and method/discipline specifics explicitly separated.

#G.Core:3 - Forces

• One governing definition vs. usability: We must centralize universal invariants, but G.x must remain readable and pattern-scoped for authors.
• Delegation-first vs. completeness: Many norms already have canonical governing definitions such as A.6.7, A.15.3, A.19, G.0, A.19.CHR, and the relevant Part E patterns. G.Core must cite those governing definitions rather than duplicating semantics.
• Public-id and alias continuity: Public CC IDs and deprecated trigger labels must remain stable as labels; deduplication must not break citations.
• Typed change control: RSCR/refresh must become id‑based (catalogued trigger kinds) rather than prose-based “meaning”.
• Strict distinction: Keep governing spec refs (CN‑Spec, CG‑Spec), suites, kits/surfaces, policies, planned baselines, audits, and refresh orchestration distinct.
• Minimal specificity naming: New IDs must be kind‑suffixed and minimally specific, to reduce semantic lock‑in while remaining precise.
• Phase‑2 scope discipline: G.Core must not become a container for discipline/method/generator taxonomies; those remain pattern-scoped (Extensions), delegated to existing governing patterns, or marked Phase‑3 seeds (appendix) without new Phase‑2 norms.

#G.Core:4 - Solution

G.Core establishes Part‑G‑wide invariants as delegation rules + typed catalogs + authoring discipline.

#G.Core:4.1 - Delegation-first citation for Part‑G‑wide invariants

G.Core is a citation hub, not a “second spec”. For any Part‑G‑wide invariant that already has a governing definition, G.Core:

1. standardises naming via SuiteObligations.* (A.6.7:4.2), and
2. records where the invariant is governed, so downstream patterns cite rather than restate.

Delegation table (normative index; no semantic duplication).

This pattern also governs four pieces of Part‑G‑wide infrastructure that are not already governed elsewhere:

• the typed RSCRTriggerKindId catalogue (single writer),
• the Default Governing Definition Index (one governing definition per DefaultId; index only), and
• the Δ‑discipline for ID‑stable deduplication (delegation without public‑ID breakage), and
• the linkage compression catalogues (GCoreConformanceProfileId, GCoreTriggerSetId, GCorePinSetId) used to keep G.x linkage sections small.

#G.Core:4.2 - Mandatory G.Core linkage manifest requirement for every G.x

Every pattern G.x in Part G SHALL include a short, explicit Core linkage section that is notation‑independent and id‑based.

• Relations: Builds on: G.Core.

• Solution: include a section named G.x:<n> - G.Core linkage (normative) that contains a GCoreLinkageManifest listing, at minimum:

  • CoreConformanceProfileIds := { GCoreConformanceProfileId… } (preferred) and/or CoreConformanceIds := { CC‑GCORE‑… }
  • RSCRTriggerSetIds := { GCoreTriggerSetId… } (preferred) and/or RSCRTriggerKindIds := { RSCRTriggerKindId… }
  • CorePinSetIds := { GCorePinSetId… } (preferred) and/or CorePinsRequired := { … } (pins/refs surfaced by the kit; include policy‑id pins and edition pins when applicable; list only additions/overrides if pin sets are used)
  • DefaultsConsumed := { DefaultId… } (ids only; governing definition is resolved via G.Core.DefaultGoverningDefinitionIndex; cite governing definition, don’t restate)
  • TriggerAliasMapRef? (present or cited) if the pattern uses local trigger tokens

Nil‑elision (normative size rule). Any field whose value is ∅ MAY be omitted; omission means ∅ and does not relax any obligation.

Expansion rule (normative). If profile/set ids are used, the effective CoreConformanceIds / RSCRTriggerKindIds / CorePinsRequired are the unions of their expansions plus any explicitly listed ids (see G.Core:4.2.2, G.Core:4.2.3, and G.Core:4.3.4.2).

#G.Core:4.2.1 - GCoreLinkageManifest (canonical shape)

GCoreLinkageManifest is the minimal, pattern‑local wiring manifest for citing G.Core without duplicating universal prose.

A G.x MAY render the manifest as prose, a table, or structured notation, but the ids SHALL be recoverable by authoring review:

GCoreLinkageManifest := ⟨ CoreConformanceProfileIds?: {GCoreConformanceProfileId…}, CoreConformanceIds?: {CC‑GCORE‑…}, RSCRTriggerSetIds?: {GCoreTriggerSetId…}, RSCRTriggerKindIds?: {RSCRTriggerKindId…}, CorePinSetIds?: {GCorePinSetId…}, CorePinsRequired?: {…pin ids…}, DefaultsConsumed?: {DefaultId…}, TriggerAliasMapRef?: TriggerAliasMapRef ⟩

#G.Core:4.2.2 - GCoreConformanceProfileId catalogue (compression primitive)

A GCoreConformanceProfileId is a stable identifier for a named set of CC‑GCORE‑* items. It exists solely to reduce repetition in G.x linkage sections (no new semantics).

#G.Core:4.2.3 - GCorePinSetId catalogue (compression primitive)

A GCorePinSetId is a stable identifier for a named set of commonly recurring pin obligations used in Part‑G kits. It exists solely to reduce repetition in G.x linkage sections (no new semantics).

Conditional pins (normative). In pin‑set expansions below, a pin marked with ? is conditional: it MUST be present iff the pattern actually uses the corresponding surface/artefact class; otherwise it MAY be omitted (nil‑elision permitted) and is treated as ∅. A G.x MAY strengthen a conditional pin to unconditional by listing it explicitly in CorePinsRequired.

#G.Core:4.3 - RSCR Trigger Catalogue and docking discipline

G.Core is the single writer for Part‑G‑wide trigger kinds.

#G.Core:4.3.1 - Definitions

• RSCRTriggerKindId Canonical, stable identifier for a trigger kind (a class of “why RSCR/refresh must fire”). Cross-pattern reason code.

• RSCRTriggerAliasId Pattern-scoped human label/token kept for ergonomics and alias continuity (e.g., G.11:T4, G.6:H3:lane-tag correction).

• TriggerAliasMap Mapping table: RSCRTriggerAliasId → {RSCRTriggerKindId…} (1..n).

• RSCRTrigger Minimal conceptual form (notation-independent):

  RSCRTrigger := ⟨
    triggerKindId: RSCRTriggerKindId,
    scope: PathSliceId[] | PathId[] | PatternScopeId,
    payloadPins: { …id pins… }
  ⟩

  Where payloadPins contains any edition pins, policy-ids, Bridge ids, evidence pins, regression-set ids, etc., required to make the trigger actionable.

#G.Core:4.3.2 - Governing-definition model

• TriggerGoverningDefinition := G.Core.
• Any new trigger kind SHALL be added to G.Core first.
• Other patterns MAY define aliases only (or cite shared alias maps), and MUST map aliases to canonical kinds.

#G.Core:4.3.3 - Authoring rules

• No implicit triggers: Any RSCR/SCR/refresh artefact that records reasons MUST record canonical RSCRTriggerKindId. Aliases may be recorded as labels, but must not be the only reason code.

• No implicit overloading: A local token string (e.g., T4) SHALL NOT silently change meaning across patterns; namespace is part of the alias (G.11:T4 ≠ A.20:T4).

• Granularity discipline: If a local cause is narrower than an existing canonical kind, map it to that kind and keep the nuance as a local scope note. If the difference matters for planning/selection, add a new canonical kind.

• Multi-cause discipline: When an event spans multiple canonical kinds, record multiple triggers (preferred) or map the alias to a set {…} and require emitting the full set.

#G.Core:4.3.4 - Seed canonical catalogue (Phase‑2 minimum)

The Phase‑2 stabilized canonical catalogue (based on the Phase‑2 inventory; sufficient to dock deprecated G.6:H3 and G.11:T0…T7 trigger labels and to populate RSCRTriggerKindIds in G.0…G.13):

• RSCRTriggerKindId.LegalitySurfaceEdit
• RSCRTriggerKindId.PenaltyPolicyEdit
• RSCRTriggerKindId.CrossingBundleEdit
• RSCRTriggerKindId.ReferencePlaneEdit
• RSCRTriggerKindId.EditionPinChange
• RSCRTriggerKindId.TokenizationOrNameChange
• RSCRTriggerKindId.PolicyPinChange
• RSCRTriggerKindId.TelemetryDelta
• RSCRTriggerKindId.FreshnessOrDecayEvent
• RSCRTriggerKindId.EvidenceSurfaceEdit
• RSCRTriggerKindId.MaturityRungChange
• RSCRTriggerKindId.BaselineBindingEdit
• RSCRTriggerKindId.DefaultGoverningDefinitionChange

#G.Core:4.3.4.1 - Canonical kind definitions (normative, minimal)

Each RSCRTriggerKindId SHALL have a short, stable definition in G.Core (single-writer) to prevent semantic drift.

#G.Core:4.3.4.2 - Canonical trigger sets (compression primitive)

GCoreTriggerSetId identifies a named set of RSCRTriggerKindId values. A G.x MAY cite trigger sets in RSCRTriggerSetIds instead of repeating long RSCRTriggerKindIds lists.

#G.Core:4.3.5 - Initial alias maps

These alias maps are normative docking artefacts and preserve deprecated alias labels while moving semantics to canonical ids.

TriggerAliasMap.G11 Based on the existing trigger catalogue in G.11 (T0…T7).

• G.11:T0 → { RSCRTriggerKindId.PolicyPinChange }
• G.11:T1 → { RSCRTriggerKindId.TelemetryDelta }
• G.11:T2 → { RSCRTriggerKindId.EditionPinChange }
• G.11:T3 → { RSCRTriggerKindId.EditionPinChange }
• G.11:T4 → { RSCRTriggerKindId.CrossingBundleEdit, RSCRTriggerKindId.PenaltyPolicyEdit }
• G.11:T5 → { RSCRTriggerKindId.FreshnessOrDecayEvent }
• G.11:T6 → { RSCRTriggerKindId.MaturityRungChange }
• G.11:T7 → { RSCRTriggerKindId.PolicyPinChange }

TriggerAliasMap.G0 (reserved; empty in Phase‑2). Map any stable deprecated registry-hook labels emitted/recorded by G.0 to the canonical kinds above (typically LegalitySurfaceEdit, PenaltyPolicyEdit, CrossingBundleEdit, ReferencePlaneEdit, TokenizationOrNameChange), preserving the original label text as RSCRTriggerAliasId. If none exist, G.0 SHOULD emit canonical RSCRTriggerKindId values directly.

TriggerAliasMap.G6 EvidenceGraph H3 example causes → canonical kinds:

• G.6:H3:freshness/decay change → { RSCRTriggerKindId.FreshnessOrDecayEvent }
• G.6:H3:Bridge CL/CL^k or loss update → { RSCRTriggerKindId.CrossingBundleEdit }
• G.6:H3:Φ/Ψ policy change → { RSCRTriggerKindId.PenaltyPolicyEdit }
• G.6:H3:lane tag correction → { RSCRTriggerKindId.EvidenceSurfaceEdit }
• G.6:H3:ReferencePlane correction → { RSCRTriggerKindId.ReferencePlaneEdit }
• G.6:H3:QD/OEE artefact updates (U.DescriptorMapRef.edition/DistanceDef, EmitterPolicyRef, InsertionPolicyRef, archive K-capacity) → { RSCRTriggerKindId.EditionPinChange, RSCRTriggerKindId.PolicyPinChange }

#G.Core:4.4 - Default Governing Definition Index

G.Core provides an index of Part‑G defaults with one governing definition per DefaultId. The index is not a “second spec”; it is a cross-reference table that points to the governing definition reference (a CC item, policy‑id, or TaskSignature rule) and states applicability conditions.

#G.Core:4.4.1 - Definitions

• DefaultId Stable identifier of a default (a default constant or default rule).

• DefaultGoverningDefinitionRef A reference to the governing definition of the default (e.g., a CC item id like CC‑G5.23, or a policy id, or a TaskSignature rule definition).

#G.Core:4.4.2 - Rules

• Exactly one governing definition per DefaultId.
• Any other mention in G.x MUST be a citation/delegation to the governing definition, not a competing statement.
• A default may be conditional (default-rule) with explicit applicability conditions.
• The Default Governing Definition Index SHALL NOT be used to “smuggle” mandatory invariants as defaults. Invariants remain invariants (typically cited through CC‑GCORE‑… and their canonical governing definitions).

#G.Core:4.4.3 - Seed Default Governing-definition assignment entries (Phase‑2 minimum)

This table may grow over time; the rule is that the governing definition must already be named (or be intentionally set to G.Core when the default is truly Part‑G‑wide and not governed elsewhere). Any change in a row (add/remove/change governing definition) SHALL be treated as a refresh‑sensitive edit and recorded as RSCRTriggerKindId.DefaultGoverningDefinitionChange (payload: affected DefaultId.*, old governing definition ref, new governing definition ref).

#G.Core:4.5 - ID continuity protocol (Δ‑discipline)

When moving universal norms out of G.x into G.Core:

• existing public CC ids in G.x that may be referenced externally SHALL NOT be deleted or renamed;
• such CC items SHALL become delegation items that point to the relevant CC‑GCORE‑… item(s);
• each G.x SHALL add exactly one bridge CC item CC‑Gx‑CoreRef (first in its CC list) that makes linked CC‑GCORE‑… items mandatory for G.x conformance.

Deprecated trigger labels (e.g., G.11:T*, G.6:H3:*) are preserved as aliases and MUST map to canonical trigger kinds.

Non-CC public identifiers (e.g., UTSRowId, RSCRTriggerAliasId, deprecation notices, edition bumps) MUST obey the same Δ-discipline: preserve old ids; represent drift via alias/deprecation/edition evolution (see F.17 (UTS)); and emit canonical trigger kinds (RSCRTriggerKindId.TokenizationOrNameChange, RSCRTriggerKindId.EditionPinChange) when downstream impact is possible.

#G.Core:4.6 - Explicit non-goals

G.Core does not:

• introduce CG‑frame kit entities (e.g., BridgeMatrix/ReferencePlane/Φ registries); those remain in their governing G.x;
• introduce method-family taxonomies, discipline packs, or generator orchestration mechanisms; those remain as Extensions in their governing definitions (e.g., synthesis/shipping/refresh patterns);
• define refresh algorithms; it defines trigger kinds and docking only.

#G.Core:5 - Archetypal grounding

Tell. In Phase‑2 refactoring, G.Core is the hub that allows each G.x to become structurally predictable: (a) a short, normative “Core linkage” slice, and (b) pattern‑scoped Extensions. Universal obligations cite canonical governing definitions such as A.6.7, A.15.3, A.19, G.0, and A.19.CHR, while RSCR trigger kinds and DefaultGoverningDefinitionRef references become typed and cite named definitions.

Show 1: Refresh triggers without semantic drift. G.11 already uses trigger tokens T0…T7. G.Core keeps them as aliases and maps them to canonical trigger kinds (e.g., TelemetryDelta, EditionPinChange, CrossingBundleEdit). This makes RSCR reason codes consistent across patterns and avoids re-explaining trigger semantics in every pattern.

Show 2: Resolving competing defaults. If multiple patterns imply a default for PortfolioMode, the Default Governing Definition Index points to one governing definition (currently CC‑G5.23). Other patterns (e.g., bundles/log patterns) must cite that governing definition or delegate to it, rather than restating the default with slightly different wording. This preserves intent while preventing drift and ambiguity.

#G.Core:6 - Bias-annotation (informative)

• Centralization bias: One governing hub can become too thick. Mitigation: delegation-first citation; keep only true Part‑G invariants and typed indices here.
• Over-typing bias: A trigger catalogue can become overly granular. Mitigation: granularity discipline + scope notes; only add new kinds when planning/selection needs it.
• Refactor rigidity bias: Preserving IDs can feel cumbersome. Mitigation: delegation items preserve IDs while enabling deduplication.
• Default absolutism bias: Defaults may require conditional rules. Mitigation: Default Governing Definition Index allows conditional default rules with explicit applicability conditions.
• Single-writer bias: prefers single‑writer authoring for catalogs and explicit governing-definition tables. Mitigation: delegation-first citation; keep catalogs minimal; avoid “second specs”.
• Architectural bias: centralizes invariants to prevent accidental coupling across G.x. Mitigation: keep core thin; force Extensions to remain pattern‑scoped.
• Ontological/epistemic bias: enforces strict distinction between governing spec refs, kits, mechanisms, and orchestration. Mitigation: allow didactic scope notes while keeping normative surface id‑based.
• Pragmatic bias: adds authoring overhead (linkage sections, alias maps). Mitigation: one small mandatory bridge CC item per pattern (CC‑Gx‑CoreRef) and short linkage slices only.
• Didactic bias: risks “glossy hub prose” that hides missing CC coverage. Mitigation: enforce CC/Solution coherence (E.19) and keep invariants checkable via CC‑GCORE‑….

#G.Core:7 - Conformance checklist (normative) — CC‑GCORE

Conformance items are authoring obligations and are enforced transitively by CC‑Gx‑CoreRef in every G.x.

#G.Core:8 - Common anti-patterns and how to avoid them

• Anti-pattern: Restating CN‑Spec/CG‑Spec rules inside a G.x “for convenience”. Avoid: cite A.19 and G.0 through CC‑GCORE‑CN‑CG‑1.

• Anti-pattern: Adding a fourth guard status (“unknown”, “maybe”, “probe-only”) as a separate decision value. Avoid: keep guard domain tri‑state; express “probe-only” as policy/branching and record via pins/audit.

• Anti-pattern: Treating mandatory invariants as “defaults” to centralize them. Avoid: keep invariants as invariants (CC‑GCORE‑* cited through canonical governing definitions); restrict the Default Governing Definition Index to true defaults (constants or conditional default-rules).

• Anti-pattern: Turning partial orders into scalar ranks silently. Avoid: keep set‑valued semantics unless a total order is explicitly declared by a comparator/policy.

• Anti-pattern: Competing defaults scattered across multiple patterns. Avoid: Default Governing Definition Index; delegate duplicate statements to the one governing definition.

• Anti-pattern: Local trigger tokens without canonical mapping. Avoid: provide/cite a TriggerAliasMap with namespace‑qualified aliases.

• Anti-pattern: Breaking public CC ids during dedup. Avoid: convert to delegation items; preserve IDs.

#G.Core:9 - Consequences

• Positive: Part‑G‑wide invariants cite G.Core as their governing definition; refactors become safer and easier to audit.
• Positive: RSCR becomes reason-code driven (typed triggers), improving traceability and preventing semantic drift.
• Positive: Default conflicts become detectable and resolvable because each DefaultId names one governing definition.
• Negative: Adds an extra authoring step (linkage sections and CoreRef CC item) to each G.x.
• Negative: Requires careful governance of the trigger catalogue to avoid excessive fragmentation.

#G.Core:10 - Rationale

Universalization of Part G requires a stable "gravity center" for invariants, otherwise each pattern becomes a competing governing source. Delegation-first citation prevents duplication and makes governing-definition assignment explicit, while typed trigger kinds and the Default Governing Definition Index turn historically prose-driven drift into checkable, id-based structure.

#G.Core:11 - SoTA alignment (informative)

Although FPF is conceptual (not a data governance framework), G.Core aligns Part‑G authoring with modern best practice patterns seen across post‑2015 work:

• Selective prediction / abstention informs tri‑state guard discipline: abstaining or degrading is a first-class outcome, not an error coerced into a scalar.
• Set-valued / conformal methods motivate set-return semantics: when comparability is partial or uncertainty is structural, returning sets/regions is often the SoTA-friendly representation.
• Multiobjective optimization and quality-diversity reinforce declared set-result and Archive semantics instead of forced “best single scalar”.
• Monotone constrained modelling (where used) supports “legality-first” scoring/aggregation: constraints and admissibility precede optimization, mirroring CG‑Spec gate discipline.
• Schema evolution and contract testing motivate id-stable conformance points and typed trigger catalogues: stable identifiers + regression hooks are the practical mechanism for safe refactoring.

#G.Core:12 - Relations

• Builds on:

  • E.8 pattern template and section discipline
  • E.10 lexical/ontological rules (strict distinction; twin naming; kind‑suffix discipline)

• E.18 CrossingBundle (crossing visibility bundle)

  • E.19 conformance discipline
  • A.6.7 SuiteObligations + suite protocol pins (delegation support)
  • A.15.3 SlotFillingsPlanItem (planned baseline anchor)
  • A.19 CN‑Spec governance card
  • G.0 CG‑Spec legality gate
  • A.19.CHR CHR suite boundary and "governance cards and legality gates are cited as pins, not copied locally" discipline
  • C.23 SoS‑LOG (tri‑state branches; sandbox/probe‑only)
  • F.17 UTS (identifier registry; alias/deprecation discipline)
  • F.15 RSCR (regression/conformance loop)

• Used by:

  • G.0…G.13 patterns (each adds Builds on: G.Core, linkage section, CoreRef CC item)

• Constrains:

  • Part‑G authoring: no shadow specs, no silent scalarization, tri‑state guards, penalties routing, typed RSCR causes, defaults with one governing definition, and ID‑continuity refactors.

#G.Core:End

#Frame Standard and Comparability Governance — CG‑Spec

Tag. Architectural pattern (foundational Standard; constrains G.1–G.5) Stage. design-time legality gate (establishes comparison legality & evidence minima; constrains run-time gates) Primary output. CG‑Spec — a notation-independent legality gate for a CG‑Frame, published to UTS (with explicit edition pins for downstream reproducibility and RSCR). Primary hooks. USM.ScopeSlice(G), entityOfConcern, SCP, MinimalEvidence, CNSpecRef, Γ‑fold, Φ(CL) / Φ_plane policy pins, UTS publication (Name Cards + edition pins). Non-duplication note. Universal Part‑G invariants are governed by G.Core and are satisfied here only via delegation (CC‑G0‑CoreRef → CC‑GCORE‑*). Single‑governing definition CN/CG spec-ref discipline is enforced via CC‑GCORE‑CN‑CG‑1 (no shadow specs; no competing defaults).

#Problem frame

A team defines or evolves a CG‑Frame (e.g., a frame for creativity measurement, decision quality, architecture trade‑offs, or selected-set publication). Downstream mechanisms (G.1–G.5 and beyond) must compare, aggregate, and publish CHR‑typed observations in ways that are:

• lawful with respect to measurement admissibility (scale/unit/polarity constraints),
• auditable with explicit evidence minima and provenance,
• reproducible via pinned editions and explicit policy ids,
• portable only via explicit crossings (bridges and reference-plane moves), never via implicit semantic leakage.

CG‑Spec is the single design-time object that fixes what comparisons and aggregations are lawful in this frame, under which pinned assumptions and minimal evidence requirements, so that run-time selection and publication can be audited without inventing new “local legality gates”.

Didactic subtitle: Design-time rules for safe, auditable comparison.

#Problem

Without a single, frame-level legality standard:

• comparisons and aggregations drift into implicit assumptions (hidden scalarisation; silent totalisation of partial orders),
• numeric gates run on “whatever is available” rather than declared evidence minima and lane/carrier requirements,
• cross-context reuse happens without explicit crossing visibility and stated losses,
• selection outcomes become hard to audit because legality, evidence minima, and penalty routing are not pinned and traceable.

#Forces

• Pluralism vs. comparability. Multiple traditions must co-exist while allowing admissible comparison where justified.
• Expressiveness vs. safety. Rich comparator sets and aggregators vs. measurement admissibility constraints.
• Locality vs. portability. Context-local semantics first; portability only via explicit bridges and explicit losses.
• Assurance vs. agility. Evidence minima must meet the claim threshold while staying light enough to adopt.
• Design-time vs. run-time. Keep legality standards and templates design-time; run-time only cites and applies them.

#Solution — CG‑Spec as the design-time legality gate

CG‑Spec is a notation-independent UTS-published object that, for a given CG‑Frame, defines:

• the ComparatorSet (explicit, finite, typed) permitted in this frame,
• the ScaleComplianceProfile (SCP) that constrains lawful operations per characteristic,
• MinimalEvidence requirements per characteristic (lanes, carriers, freshness windows, crossing allowances, failure behavior),
• the frame’s penalty and trust folding wiring (by explicit policy ids and edition pins),
• AcceptanceStubs as design-time templates (thresholds remain governed by CAL, not by CG‑Spec),
• optional method-family hooks (e.g., illumination/QD or explore↔exploit guards) as wiring only, with semantics governed by the corresponding patterns.

CG‑Spec constrains downstream gate checks by being referenced and pinned; it is not itself an admissibility mechanism.

#G.Core linkage (normative)

Builds on: G.Core (Part-G core invariants; governing-pattern citation)

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). Profiles/sets + explicit deltas; Nil‑elision applies.

• CoreConformanceProfileIds :=
  • GCoreConformanceProfileId.PartG.AuthoringBase
  • GCoreConformanceProfileId.PartG.TriStateGuard
  • GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted
• CorePinSetIds :=
  • GCorePinSetId.PartG.AuthoringMinimal
  • GCorePinSetId.PartG.CrossingVisibilityPins
• CorePinsRequired := (delta over PinSets)
  • UTSRowId[]
  • ReferenceMap
  • ComparatorSetRef.edition
  • SCPRef.edition
  • ΓFoldRef.edition?
  • MinimalEvidenceRef.edition?
  • FailureBehaviorPolicyId?
• DefaultsConsumed := {DefaultId.GammaFoldForR_eff} (governing definition: CC‑G5.4 per G.Core.DefaultGoverningDefinitionIndex)
• RSCRTriggerSetIds := {GCoreTriggerSetId.CGSpecGate}
• RSCRTriggerKindIds := (delta over TriggerSets)
  • RSCRTriggerKindId.EvidenceSurfaceEdit
  • RSCRTriggerKindId.TokenizationOrNameChange
  • RSCRTriggerKindId.DefaultGoverningDefinitionChange
• TriggerAliasMapRef := ∅

#CG‑Spec object model (normative)

CG‑Spec is authored per CG‑Frame. It SHALL:

• be published to UTS as a notation-independent object,
• reference CHR characteristics by id (measurement semantics remain governed by CHR packs),
• constrain what comparisons and aggregations are lawful in this frame via explicit comparator specs and SCP bindings,
• declare minimal evidence gates per characteristic, including explicit failure behavior wiring,
• cite CN‑Spec for normalization/comparability policies (no duplication and no shadow specs),
• publish edition pins and policy ids so downstream selection, parity, shipping, and refresh can be reproducible and RSCR-aware.

#CG‑Spec conceptual model (normative)

CG‑Spec :=
⟨
  UTS.id, Edition,
  Context, Purpose, Audience,

  Scope := USM.ScopeSlice(G) ⊕ Boundary{TaskKinds, ObjectKinds},

  entityOfConcern := ⟨GroundingHolon, ReferencePlane ∈ {world|concept|episteme}⟩,
  WorldRegime? ∈ {prep|live},          // only refines ReferencePlane=world; introduces no new planes

  ReferenceMap := minimal map{term/id → UTS|CHR|SoTA-pack refs},

  CNSpecRef := ⟨A.19 ref, CNSpecRef.edition⟩,          // CN‑Spec is the governance card (one governing definition)

  Characteristics := [CHR.Characteristic.id…],          // pointers only; authored in G.3 CHR pack

  // Edition-addressable segments (pins MUST be exposed)
  ComparatorSet := ⟨ComparatorSetId, ComparatorSetRef.edition, [ComparatorSpec…]⟩,
  SCP := ⟨SCPId, SCPRef.edition, map Characteristic.id → SCPEntry⟩,
  MinimalEvidence := ⟨MinEvId, MinimalEvidenceRef.edition?, map Characteristic.id → MinEvidenceEntry⟩,  // min pin: CGSpecRef.edition

  Γ‑fold := ⟨GammaFoldId, ΓFoldRef.edition,
             defaultRef := DefaultId.GammaFoldForR_eff,
             override? := ⟨overrideRef, proof_refs, boundary_notes⟩
           ⟩,

  // Penalty routing and plane policies are by explicit policy ids.
  // Semantics (tri-state, penalties→R_eff-only, crossing visibility, set-return) are governed by G.Core.
  CL‑Routing := ⟨policy_id, map Bridge.CL → penalty_spec⟩,
  Φ := ⟨phi_policy_id, phi_table_ref?, psi_policy_id?, phi_plane_policy_id?⟩,

  AcceptanceStubs := [AcceptanceStubId…],     // templates only; thresholds remain governed by CAL (G.4)

  // Optional hooks are wiring-only; semantics are governed by governing definitions.
  E/E‑LOG Guard? := ⟨policy_id, pins…⟩,
  Illumination? := ⟨
    Q_refs ⊆ Characteristics, D_refs ⊆ Characteristics,
    DescriptorMapRef.edition?, DistanceDefRef.edition?, DHCMethodRef.edition?,
    InsertionPolicyRef?, PromotionPolicyId?
  ⟩,

  RSCR := ⟨
  RSCRTestId[]?,             // SHOULD cover: illegal_op_refusals; unit and scale legality checks; freshness windows; // partial-order scalarisation refusals; threshold semantics; CL→R_eff routing;
                            // and refusal of degrade.order on unit mismatches (MM‑CHR).
    RSCRTriggerKindId[]
  ⟩,

  Naming := UTS Name Cards (twin labels plus bridge notes),
  PublicIdContinuity := ⟨governing definition, DRR link, refresh cadence, decay and aging policy, deprecations⟩,
  Provenance := ⟨carrier types, SoTA-pack refs, DRR/SCR linkage⟩
⟩

Local typing notes (non-exhaustive; normative intent but no shadow specs).

• ComparatorSpec MUST be typed against SCP/CHR constraints. Examples of lawful comparators are frame-local choices and are authored here (e.g., dominance where lawful; lexicographic over typed traits; medoid/median for ordinal where lawful; explicit weighted sums only where legality is proven and units are aligned).
• MinimalEvidenceEntry MUST declare: lane requirements, evidence carriers, freshness window (if any), and explicit failure behavior wiring. The semantics of {pass|degrade|abstain} and degrade(mode=…) are delegated to G.Core.

#Interfaces (normative)

#CG‑Spec authoring chassis (informative)

1. Charter the frame. Declare Context, Scope, entityOfConcern, boundary examples/non-examples, and ReferenceMap.
2. Draft ComparatorSet and SCP. Enumerate permitted comparator forms and bind each to CHR characteristics and legality constraints (scale/unit/polarity discipline). Attach guard bindings as explicit references/pins.
3. Bind Characteristics. Ensure every compared quantity is a CHR characteristic id (reuse/mint via UTS discipline).
4. Declare MinimalEvidence. For each characteristic: required lanes/carriers, freshness window, crossing allowances (if any), and explicit failure behavior wiring (tri-state semantics delegated to G.Core).
5. Pin trust folding and penalties. Cite the one governing definition for DefaultId.GammaFoldForR_eff unless explicitly overridden with proof refs; publish Φ/CL policy ids explicitly.
6. Publish and register regression tests. Publish CG‑Spec@UTS with edition-pinned segments; register RSCR tests for the frame’s legality surfaces and evidence minima.
7. Public-id continuity and refresh readiness. Declare refresh cadence and deprecations with lexical continuity notes; ensure RSCR trigger kinds are emitted as canonical ids.

#Extensions (pattern-scoped; non-core)

All blocks below are GPatternExtension modules (PatternScopeId; not new PatternIds). They store wiring only and cite governing patterns.

GPatternExtension: SpecRefSurfaces

• PatternScopeId: G.0:Ext.SpecRefSurfaces

• GPatternExtensionId: SpecRefSurfaces

• GPatternExtensionKind: InteropSpecific

• GoverningPatternId: A.19

• Uses: {A.19}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • CNSpecRef.edition (and any CN-side policy ids referenced by CG‑Spec fields)

• RSCRTriggerKindIds: {RSCRTriggerKindId.EditionPinChange, RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.LegalitySurfaceEdit}

• Notes (wiring-only): CG‑Spec SHALL cite CN‑Spec; it SHALL NOT restate normalization/comparability semantics.

GPatternExtension: BridgeAndCLWiring

• PatternScopeId: G.0:Ext.BridgeAndCLWiring

• GPatternExtensionId: BridgeAndCLWiring

• GPatternExtensionKind: InteropSpecific

• GoverningPatternId: F.9

• Uses: {F.9, G.7}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • BridgeCardId/BridgeId (when crossings are permitted)
  • CL / CL^k and Φ/Φ_plane policy ids (when penalties are in play)

• RSCRTriggerKindIds: {RSCRTriggerKindId.CrossingBundleEdit, RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.ReferencePlaneEdit}

• Notes (wiring-only): Crossing semantics and penalty routing are delegated to G.Core; this module only lists the required pins used by CG‑Spec entries.

GPatternExtension: SoTAPaletteInputs

• PatternScopeId: G.0:Ext.SoTAPaletteInputs

• GPatternExtensionId: SoTAPaletteInputs

• GPatternExtensionKind: DisciplineSpecific

• GoverningPatternId: G.2

• Uses: {G.2}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • SoTA-Pack@CG‑Frame refs used to justify comparator admissibility, evidence minima, and crossing allowances (e.g., claim sheets, operator inventory, bridge matrix ids)

• RSCRTriggerKindIds: {RSCRTriggerKindId.EvidenceSurfaceEdit, RSCRTriggerKindId.CrossingBundleEdit, RSCRTriggerKindId.FreshnessOrDecayEvent}

• Notes (wiring-only): Any SoTA palette/tradition semantics are governed by G.2. G.0 only requires that CG‑Spec entries cite the needed SoTA artefacts for auditability.

GPatternExtension: QDAndExplorationHooks

• PatternScopeId: G.0:Ext.QDAndExplorationHooks

• GPatternExtensionId: QDAndExplorationHooks

• GPatternExtensionKind: MethodSpecific

• GoverningPatternId: C.18

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • DescriptorMapRef.edition?, DistanceDefRef.edition?, InsertionPolicyRef?
  • FailureBehaviorPolicyId / SoS‑LOG branch policy id when degrade(mode=…) is used

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

• Notes (wiring-only): CG‑Spec may declare optional QD/exploration hooks; semantics remain governed by the referenced method patterns.

#Archetypal Grounding — Tell–Show–Show; System / Episteme

#Archetype 1: System comparability under mixed evidence and unit constraints

Tell. Two labs compare energy efficiency results of a physical system where measurements use different rigs and units, and some evidence is missing.

Show (failure without CG‑Spec). The team averages an ordinal safety rating, mixes units (“kWh” vs “MJ”), and silently treats missing lanes as zeros. Cross-lab reuse happens without explicit bridge and loss notes, so selection becomes a black box.

Show (repair with CG‑Spec). A conformant CG‑Spec:

• pins the lawful comparator(s) (e.g., unit-aligned ratio comparisons only; ordinal comparisons are order-only),
• declares MinimalEvidence lanes/carriers and freshness windows per characteristic,
• declares explicit failure behavior wiring (tri-state semantics delegated to G.Core),
• exposes crossing pins (bridge ids + CL/policy ids) when reuse across rigs is attempted,
• publishes the pinned editions so parity/refresh can detect drift.

#Archetype 2: Epistemic comparability for selected-set publication across traditions

Tell. A team selects an R&D set using multiple evaluation traditions: safety assurance, cost models, and readiness heuristics.

Show (failure without CG‑Spec). The team collapses partial orders into a single score, hides the threshold policy in code, and cannot explain why cross-tradition penalties changed between runs.

Show (repair with CG‑Spec). A conformant CG‑Spec:

• defines a comparator bundle (e.g., Pareto dominance + explicit lexicographic tiebreaks where lawful),
• pins CNSpecRef.edition and the editioned segments (ComparatorSetRef.edition, SCPRef.edition, MinimalEvidenceRef.edition),
• makes AcceptanceStubs explicit as templates while locating thresholds in CAL (G.4),
• ensures RSCR triggers are emitted when comparator or policy pins change.

#Bias-Annotation

CG‑Spec can encode (and therefore amplify) biases if authored carelessly:

• Tradition favoritism. Comparator choices may privilege a tradition’s evidence style; mitigation: require explicit evidence minima and explicit crossing costs, and keep cross-tradition aggregation gated by explicit justifications.
• Metric gaming and Goodhart effects. Overemphasis on a single scalar can lead to gaming; mitigation: preserve set-return semantics and require explicit, auditable scalarisations when they are lawful and intended.
• Hidden thresholds and opaque safety policy. Embedding acceptance thresholds in prose or code hides value judgments; mitigation: keep thresholds in CAL acceptance clauses and pin policy ids.
• Scope creep. Comparisons leak across entityOfConcern or reference planes; mitigation: require explicit entityOfConcern and ReferencePlane pins and treat plane moves as explicit crossing events.

#Conformance Checklist (normative)

#Common Anti-Patterns and How to Avoid Them

• Anti-pattern: shadow legality gates in downstream code. Avoid by requiring downstream to cite CG‑Spec segments by id+edition.
• Anti-pattern: “one number to rule them all”. Avoid by preserving set-return outputs when only partial orders are lawful; any scalarisation must be explicit, typed, and justified.
• Anti-pattern: thresholds inside CG‑Spec or CHR. Avoid by keeping thresholds and acceptance logic in CAL and citing from CG‑Spec only via stubs/templates.
• Anti-pattern: implicit crossings. Avoid by requiring explicit bridge ids, CL/policy ids, and reference-plane pins.

#Consequences

• Lawful comparability. The frame declares exactly what can be compared/aggregated and under what constraints.
• Auditable selection. Downstream selectors can justify outcomes via pinned legality surfaces and explicit evidence minima.
• Explicit portability costs. Cross-context reuse becomes deliberate and costed via visible crossings and penalties.
• Lower drift under evolution. Edition pinning + typed RSCR triggers makes comparability drift detectable and refreshable.

#Rationale

CG‑Spec centralises frame-level comparability constraints so that:

• CHR authorship (G.3) remains about measurement meaning rather than implicit thresholds,
• CAL (G.4) governs context-local acceptance/threshold policies and proof ledgers,
• selectors and dispatchers (G.5) remain policy-governed and auditable rather than encoding hidden legality assumptions,
• refresh (G.11) can treat legality edits and pin changes as explicit causes with canonical trigger ids.

#SoTA‑Echoing

This pattern aligns with post‑2015 best practice in evaluation and governance by:

• treating “abstain / defer” as a first-class outcome rather than forcing a single brittle scalar (cf. selective prediction / abstention and set-valued reporting practices),
• preserving multiobjective / partial-order outputs as sets (Pareto / archive thinking) rather than silently collapsing to a scalar,
• emphasising reproducibility via explicit versioning/pinning of evaluation surfaces (editions) and explicit policy identifiers,
• making evidence minima explicit and auditable (a conceptual analogue of modern reproducibility/robustness checklists and evaluation protocols),
• keeping method-family specifics modular (e.g., QD/archives, open-ended exploration budgets) via explicit wiring to governing patterns rather than embedding method semantics into the universal legality gate.

#Relations

Builds on: G.Core, A.19 (CN‑Spec), A.10 (evidence carriers), A.17–A.19 / C.16 (MM‑CHR legality), A.18 (CSLC), B.3 (trust / Γ‑fold family), F.* (contexts, bridges, CL, UTS), E.10 (lexical rules), E.5.* (notation independence discipline). Used by: G.1 (generator guards), G.2 (harvesting constraints), G.3 (required CHR), G.4 (acceptance templates / proof hooks), G.5 (eligibility gates), G.6 (evidence/pin surfaces), and downstream parity/shipping/refresh where CG‑Spec is pinned. Publishes to: UTS (Name Cards + editioned CG‑Spec segments).

#G.0:End

#CG‑Frame‑Ready Generator

Tag. architectural pattern; generator chassis (design‑time kit / authoring scaffold) Status. stable (Phase‑2 universalisation) Normativity. normative, except sections explicitly marked informative Stage. design‑time authoring of a generator‑kit with a run‑time execution façade (policy‑governed; edition‑aware) Primary output. the six‑card chassis M1…M6 published as a complete, reusable CG‑Frame kit, plus a versioned kit manifest CGKitId that binds the six cards as a single reusable unit (view‑friendly inventory + wiring surface) Primary hooks. see §12 Relations (notably G.Core, G.0, G.2, G.5, G.10, G.11) Working‑model first (informative). prefer working models and didactic micro‑examples; escalate to formal harnesses only when risk warrants (per E.8). Non‑duplication note. Universal Part‑G invariants (tri‑state guard, set-return, penalties→R_eff‑only, crossing visibility, typed RSCR triggers, Default Governing Definition Index, P2W split, linkage discipline, shipping boundary) are governed in G.Core and are only cited here.

Start here when. You are authoring a reusable generator, selector, or set-result scaffold rather than a one-off plan, one-off comparison, or tool-specific method recipe.

First output. The six-card chassis M1…M6 published as a reusable CGKitId-bound kit with a scope anchor, local SoTA set, variant pool, shortlist surface, and refresh-ready wiring.

Neighboring FPF patterns. Use G.2 for the local SoTA set, G.5 for governed set-return selection, G.10 for shipping surfaces, G.11 for refresh wiring, and F.17 when the result must also land on a human-facing UTS surface.

Common wrong neighboring-pattern changes. If the real entry load is only a one-off governed comparison or shortlist, use A.19, G.0, or G.5; if the real entry load is project alignment rather than kit authoring, use A.15; if tooling choice is being treated as the first kit candidate, keep the case here only after the chassis and its bindings are explicit.

#Problem frame

You are authoring a CG‑Frame and want a repeatable scaffold that connects:

• a declared scope anchor (CG‑FrameContext, entityOfConcern, governing spec refs),
• a local SoTA set (scoped and provenance‑anchored),
• a variant pool (candidate ideas / decision options / method variants),
• a shortlist (a set-result outcome, not a forced singleton),
• publication‑ready bindings into Part‑F artefacts (UTS rows, Name Cards, RSCR tests, worked examples),
• and refresh readiness (telemetry hooks + RSCR wiring) without redefining refresh or shipping.

This pattern is intentionally a chassis, not a method specification:

• harvesting semantics are governed by G.2,
• selection/dispatch semantics are governed by G.5,
• CHR/CAL payload semantics are governed by G.3 / G.4,
• shipping semantics are governed by G.10,
• refresh orchestration governing definition is G.11.

#Problem

Without a chassis, CG‑Frame authoring tends to fail in repeatable ways:

• SoTA is not locally scoped: inputs are “in the air”, not a reconstructible set.
• Generation is ad‑hoc: variant candidates are emitted without a stable trace of why/when/how.
• Selection is opaque: eligibility/acceptance and assurance are not pinned to explicit surfaces.
• Outputs don’t land in reusable surfaces: no clean hand‑off into UTS / RoleDescription / Concept‑Sets / RSCR.
• No kit‑level snapshot: the scaffold lacks a versioned manifest, so downstream can’t reliably cite “which chassis edition” was used.
• Refresh is unplanned: there is no canonical wiring from edits/telemetry/decay to RSCR causes along the P2W path.

#Forces

• Breadth vs. precision: harvest wide enough to avoid local dogma, but keep the artefact actionable.
• Generativity vs. assurance: encourage novelty while keeping evidence, legality, and trust inspectable.
• Local meaning vs. portability: keep meaning local by default; crossing must be explicit and auditable.
• Expressiveness vs. parsimony: resist inventing new types/slots; prefer reuse and explicit wiring.
• Stability vs. evolution: keep stable IDs and pins while allowing SoTA, policies, and editions to evolve.
• Didactic clarity vs. normative minimalism: authors need a concrete scaffold, but universal invariants must not be duplicated outside G.Core.

#Solution

#G.Core linkage (normative)

// Canonical form: see G.Core (Nil‑elision + Expansion rule for profiles/sets/pin‑sets).
GCoreLinkageManifest := ⟨
  CoreConformanceProfileIds := {
    GCoreConformanceProfileId.PartG.AuthoringBase,
    GCoreConformanceProfileId.PartG.TriStateGuard,
    GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted,
    GCoreConformanceProfileId.PartG.ShippingBoundary
  },

  CorePinSetIds := {
    GCorePinSetId.PartG.AuthoringMinimal,
    GCorePinSetId.PartG.CrossingVisibilityPins
  },

  // Prefer sets; use deltas for pattern‑specific additions.
  RSCRTriggerSetIds := { GCoreTriggerSetId.SoTAHarvestSynthesis },
  RSCRTriggerKindIds := { RSCRTriggerKindId.BaselineBindingEdit },

  // Kit identifiers governed by this pattern (the “six cards”).
  CorePinsRequired := {
    SoTAPaletteDescriptionId,
    SoTA_SetId,
    VariantPoolId,
    ShortlistId,
    CGFrameLibraryId,
    RefreshReadinessCardId,
    CGKitId,

    // Local pointer-map surface for vocabulary + observables-to-CHR anchoring.
    // (May cite `G.0:CG‑Spec.ReferenceMap`; do not duplicate semantics.)
    ReferenceMap,

    // RSCR regression tests used by the chassis (if any).
    RSCRTestId[]?,

    // When the chassis is bound into WorkPlanning (P2W): planned baseline refs.
    SlotFillingsPlanItemRef[]?
  },

  // Consumed defaults (each default cites the governing definition listed in `G.Core.DefaultGoverningDefinitionIndex`).
  DefaultsConsumed := {
    DefaultId.GammaFoldForR_eff,   // governing definition: CC-G5.4
    DefaultId.PortfolioMode,       // governing definition: CC-G5.23
    DefaultId.DominanceRegime      // governing definition: CC-G5.28
  }
⟩

Citation rule (normative): CC‑GCORE‑*, RSCRTriggerKindId.*, and DefaultId.* semantics are governed by their canonical definitions: primarily G.Core, and for the defaults above the definitions listed in G.Core.DefaultGoverningDefinitionIndex. [G.1](/generated/patterns/G.1) MUST NOT restate or redefine those semantics.

#Six‑module generator chassis (normative)

Core artefact: CGFrameReadyGeneratorKit := ⟨M1, M2, M3, M4, M5, M6⟩, where each Mi is a card with an explicit I/O surface and stable identifiers. CGKitId identifies the versioned kit manifest (CG‑Kit@CG‑Frame) that lists the six card ids and the minimal wiring pins needed to treat the chassis as a reusable unit (this is not a shipping pack; shipping remains governed by G.10).

The chassis is view‑friendly: it is an inventory of “what exists and how it is wired”, not a second specification of CN/CG/CHR/CAL/selection semantics.

#M1 — CG‑FrameContext Card (scope anchor)

Governs (kit surface):

• CG‑FrameContext and its binding pins:

  • entityOfConcern := ⟨GroundingHolon, ReferencePlane⟩ (pin set: PartG.AuthoringMinimal)
  • CNSpecRef.edition, CGSpecRef.edition (pin set: PartG.AuthoringMinimal)
  • ReferenceMap (cite G.0:CG‑Spec.ReferenceMap; do not duplicate semantics)
  • any declared crossing/policy pins (pin set: PartG.CrossingVisibilityPins)

Purpose: provide the single scope anchor used by all downstream cards.

Notes: any spec-legality content is cited via A.19 (CN‑Spec) and G.0 (CG‑Spec) (delegation target: CC‑GCORE‑CN‑CG‑1 via CC‑G1‑CoreRef); this card does not introduce a local “mini‑spec”.

#M2 — SoTA_Set@CG‑Frame (harvester output card)

Governs (kit surface):

• SoTAPaletteDescriptionId and SoTA_SetId bound to CG‑FrameContext
• explicit provenance anchors for the set (via A.10), and any published UTS stubs/rows when applicable

Governing pattern: harvesting discipline and SoTA-pack payload are governed by G.2. In G.1, M2 is a slot in the chassis and a wiring surface; it does not redefine the harvesting method.

#M3 — VariantPool (candidate inventory + emitter trace)

Governs (kit surface):

• VariantPoolId bound to CG‑FrameContext
• per‑candidate minimal traceability fields (emitter identity, EmitterPolicyRef (policy‑id/ref; defined by the governing pattern), method/generator refs when declared, edition pins, provenance anchors)
• optional, per‑candidate assurance preview pointers (e.g., PathSliceId? and/or SCRId? when early assurance is recorded) and optional QD/Open‑Ended scaffolding stubs (only when introduced by explicit GPatternExtension blocks)

Guardrails (via G.Core):

• tri‑state eligibility handling, penalties routing, crossing visibility, and set‑return constraints are not defined here; they are enforced via G.Core conformance.

Governing pattern for method payload: method‑specific emitter semantics are governed by Extensions (e.g., C.17, C.18, C.19). M3 MUST remain method‑agnostic in its core definition: it is an inventory surface, not an algorithm spec.

#M4 — Shortlist (selector/assurer output)

Governs (kit surface):

• ShortlistId bound to CG‑FrameContext
• a selected set of candidates plus rationale and assurance records (SCRId required; DRRId optional; cite PathId/PathSliceId when applicable)
• optional front metadata or archive metadata needed for reproducibility when used: ε‑front parameters and/or archive snapshot hooks, with governing-definition assignment through G.5 / C.18 / C.19 (no local semantics in G.1)

Governing pattern: selection/dispatch semantics are governed by G.5. M4 MUST preserve set‑return semantics (as governed by G.Core) and MUST NOT hard‑code a forced singleton outcome.

#M5 — CG‑FrameLibrary (published bindings index)

Governs (kit surface):

• CGFrameLibraryId bound to CG‑FrameContext

• an index of referenced CG‑Frame artefacts ready for reuse:

  • CHR/CAL/LOG bundles (by their ids; semantics governed by G.3, G.4, G.8)
  • published identifiers (UTS rows, Name Cards) per Part‑F governing definitions
  • additional Part‑F binding surfaces (e.g., RoleDescription templates, Concept‑Set rows) by governing definition‑ids only
  • RSCR test identifiers (e.g., from F.15) and worked examples (where applicable)

Boundary: M5 is a kit/library surface, not shipping. If a shipped pack is needed, governing-definition assignment is G.10.

#M6 — RefreshReadiness Card (telemetry hooks + wiring)

Governs (kit surface):

• RefreshReadinessCardId bound to CGFrameLibraryId (and thus to CG‑FrameContext)
• CGKitId (the versioned kit manifest) binding M1…M6 into a single reusable unit; it MUST enumerate the card ids and MAY carry references to deprecations/edition bumps minted by the canonical governing definitions
• declared telemetry hooks (what signals are observed, with what pins)
• declared RSCR wiring: which RSCRTriggerKindId are relevant (canonical ids), with minimal required payload pins (including SlotFillingsPlanItemRef[] when the chassis is bound into WorkPlanning)

Boundary: orchestration semantics are governed by G.11. M6 prepares refresh‑readiness metadata and wiring stubs; it does not define scheduling/priority heuristics.

#Minimal I/O surface (normative)

#Extensions (pattern‑scoped; non‑core)

All method/discipline/generator specifics MUST be expressed as GPatternExtension blocks.

Guard: G.1:Ext.* are PatternScopeId values (internal, pattern‑scoped), not new patterns and not new PatternId.

#GPatternExtension — G.1:Ext.HarvesterWiring

PatternScopeId: G.1:Ext.HarvesterWiring GPatternExtensionId: HarvesterWiring GPatternExtensionKind: GeneratorSpecific GoverningPatternId: G.2 Uses: {G.2} ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

• SoTAPaletteDescriptionId
• SoTA_SetId
• ClaimSheetId[] / BridgeMatrixId (as referenced by the chosen G.2 pack form)
• CNSpecRef.edition, CGSpecRef.edition (already required via GCorePinSetId.PartG.AuthoringMinimal) RSCRTriggerSetIds: {GCoreTriggerSetId.SoTAHarvestSynthesis} Notes (wiring‑only): harvesting semantics (living review funnels, inclusion policy families, SoS indicator families, etc.) are defined by G.2 and are not duplicated in G.1.

#GPatternExtension — G.1:Ext.ShortlistWiring

PatternScopeId: G.1:Ext.ShortlistWiring GPatternExtensionId: ShortlistWiring GPatternExtensionKind: MethodSpecific GoverningPatternId: G.5 Uses: {G.5, G.4} ⊑/⊑⁺: ∅

RequiredPins/EditionPins/PolicyPins (minimum):

• ShortlistId
• SCRId (assurance and rationale record by id; semantics governed by the selector and assurance governing definitions)
• DRRId? (when a decision‑rationale artefact is minted; otherwise omitted)
• TaskSignatureRef? (if selection is task‑templated; otherwise omitted)
• AcceptanceClauseId[] (as referenced from G.4 outputs)
• any explicit selector policy pins (policy‑id/ref; defined by the governing pattern) when not defaulted (the omitted default cites its governing definition through G.Core.DefaultGoverningDefinitionIndex)

Notes (wiring‑only): G.1 does not redefine selection: it binds M4’s output surface to the G.5 selector/dispatcher kernel.

#GPatternExtension — G.1:Ext.CreativityCHR

PatternScopeId: G.1:Ext.CreativityCHR GPatternExtensionId: CreativityCHR GPatternExtensionKind: DisciplineSpecific GoverningPatternId: C.17 Uses: {C.17, G.3} ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

• CHRPackId? (if creativity characteristics are published/typed)
• edition/policy pins required by the chosen creativity characteristic set (governed by C.17)

Notes (wiring‑only): G.1 only records which creativity characteristics are used for M3/M4 wiring; legality/typing lives in the CHR governing definitions.

#GPatternExtension — G.1:Ext.NQD

PatternScopeId: G.1:Ext.NQD GPatternExtensionId: NQD GPatternExtensionKind: MethodSpecific GoverningPatternId: C.18 Uses: {C.18, C.19} ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

• DescriptorMapRef.edition
• DistanceDefRef.edition
• InsertionPolicyRef (policy id / ref, as defined by the governing definition)
• TaskSignatureRef? (when QD is enabled via TaskSignature flags/traits rather than by an external switch)
• DHCMethodRef.edition? (when illumination/coverage summaries are pinned to a method)
• EmitterPolicyRef (policy‑id/ref; points to the exploration governance governing definition, e.g., C.19 when E/E‑LOG is used)

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

Notes (wiring‑only): QD/QD‑adjacent algorithm families and their parameterisations belong to C.18 and C.19; G.1 only fixes the pins needed to make the VariantPool and Shortlist reproducible.

#GPatternExtension — G.1:Ext.OpenEndedFamilyWiring

PatternScopeId: G.1:Ext.OpenEndedFamilyWiring GPatternExtensionId: OpenEndedFamilyWiring GPatternExtensionKind: GeneratorSpecific GoverningPatternId: G.2 (family semantics are governed by SoTA cards; this block only wires pins; selector-side wiring is governed by G.5.) Uses: {G.2, G.5, 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 (wiring‑only): this block enables declared sets of {Environment, MethodFamily} pairs without redefining generator semantics in G.1; it should cite/align with the selector‑side wiring in G.5:Ext.OpenEndedFamilyWiring.

#GPatternExtension — G.1:Ext.RefreshWiring

PatternScopeId: G.1:Ext.RefreshWiring GPatternExtensionId: RefreshWiring GPatternExtensionKind: GeneratorSpecific GoverningPatternId: G.11 Uses: {G.11} ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

• RefreshReadinessCardId
• RSCRTestId[]
• canonical RSCRTriggerKindId[] emitted/recorded (aliases only as labels, if any) RSCRTriggerSetIds: {GCoreTriggerSetId.RefreshOrchestration} Notes (wiring‑only): M6 declares readiness and wiring; orchestration semantics (queueing, prioritisation, cadence) are governed by G.11.

#GPatternExtension — G.1:Ext.ShippingWiring

PatternScopeId: G.1:Ext.ShippingWiring GPatternExtensionId: ShippingWiring GPatternExtensionKind: GeneratorSpecific GoverningPatternId: G.10 Uses: {G.10} ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

• CGFrameLibraryId
• SoTAPaletteDescriptionId, SoTA_SetId
• CHRPackId?, CALPackId?, SoS‑LOGBundleId?, ParityReportId? (as present in the library index)
• EvidenceGraphId?, BridgeMatrixId?, BridgeCalibrationTableId? (when cited by the shipped artefacts)
• UTSRowId[]? (when any public ids are minted/published)
• SlotFillingsPlanItemRef[]? (when planned baseline is bound by id into the shipment surface) Notes (wiring‑only): this block does not define shipping; it only records the minimum wiring from the chassis/library index to G.10 when shipping is performed.

#Archetypal Grounding — Tell–Show–Show (informative)

Tell. Use the six‑card chassis to make a CG‑Frame authoring effort reproducible: a scoped SoTA set, a traceable candidate pool, a set‑return shortlist, a publishable library index, and refresh readiness—without redefining spec-legality/selection/refresh governing definitions.

Show A (R&D multi‑criteria decisions; post‑2015 SoTA practice).

• M1: define CG‑FrameContext for “R&D decision options”, pin CNSpecRef/CGSpecRef editions, and publish entityOfConcern + ReferencePlane.
• M2: build SoTA_SetId via G.2 using a living‑review style funnel (e.g., PRISMA‑like trace + update cadence) and publish UTS stubs for reusable constructs.
• M3: emit a VariantPoolId where each candidate cites its emitter policy and provenance; if QD is used, wire DescriptorMapRef.edition and DistanceDefRef.edition via G.1:Ext.NQD.
• M4: produce ShortlistId as a selected-set / shortlist surface via G.5, with acceptance predicates sourced from G.4.
• M5: publish a CGFrameLibraryId indexing the chosen CHR/CAL/LOG bundles and UTS rows; register RSCR tests.
• M6: declare refresh readiness (telemetry pins + canonical RSCR trigger kinds) and wire to G.11.

Show B (clinical operations; safety‑first acceptability).

• M1: scope a CG‑Frame around dose adjustment decisions; pin legality and evidence minima explicitly.
• M2: harvest SoTA models and safety constraints as a reconstructible set (governed by G.2).
• M3: generate policy‑constrained candidate protocols; emitter trace and evidence pins are mandatory.
• M4: shortlist remains a set; “choose one” remains an explicit policy decision, not silently baked into the generator.
• M5/M6: publish and wire refresh (decay events, policy changes, and evidence updates retrigger along the P2W path).

#Bias‑Annotation (informative)

• Recency bias: “newest paper wins” (mitigate with explicit inclusion criteria and update cadence in G.2 wiring).
• Novelty bias: over‑rewarding novelty at the expense of legality/assurance (mitigate by making acceptance and assurance pins explicit and governed).
• Algorithmic favoritism: baking a preferred generator into “the chassis” (mitigate by keeping M3 method‑agnostic and pushing methods into Extensions).
• Scalarisation bias: collapsing selected sets or partial orders into a single score (mitigate by set‑return discipline pinned through G.Core).
• Hidden‑crossing bias: implicit reuse across contexts (mitigate by explicit crossing pins and Bridge‑only routing via G.Core).

#Conformance Checklist (normative)

#Common Anti‑Patterns and How to Avoid Them (informative)

• Anti‑pattern: “Shadow CN/CG spec inside the chassis.” Avoid: keep CN/CG as cited governing spec refs; use pins and governing definition references only.

• Anti‑pattern: “Chassis hard‑codes a favourite algorithm.” Avoid: keep M3 core method‑agnostic; add algorithm families only via Extensions with explicit governing patterns and edition pins.

• Anti‑pattern: “Shortlist = one winner.” Avoid: preserve selected-set returns; any singleton choice must be an explicit downstream decision rule (policy‑bound).

• Anti‑pattern: “Refresh plan described as prose triggers.” Avoid: record canonical RSCRTriggerKindId and payload pins; aliases only as labels and only if docked.

• Anti-pattern: “Packaging implies shipping governance.” Avoid: treat M5 as a library index; treat M6 as readiness wiring; ship only via G.10.

#Consequences (informative)

• Repeatable authoring: CG‑Frame work becomes reconstructible: what exists, what it depends on, and how it is refreshed.
• Method pluralism with discipline: multiple generator/selector families can coexist without turning the chassis into a shadow method spec.
• Better reuse: outputs land directly in published artefacts (UTS/Name/RSCR‑ready) rather than remaining local notes.
• Lower refactor cost: method changes localise to Extensions; core invariants remain stable and one governing definition.

#Rationale (informative)

• Why six cards? It matches the minimal decomposition needed to keep scope, harvesting, generation, selection, publication, and refresh explicitly separable (and thus auditable and evolvable).
• Why “kit/index” rather than “pack”? A CG‑Frame authoring effort must stay modular; shipping is a separate governing boundary (G.10).
• Why push method content into Extensions? It prevents conflating (i) universal invariants, (ii) frame‑specific kit surfaces, and (iii) method/generator families—supporting Phase‑2 universalisation goals.
• Why working‑model first? Many CG‑Frames fail due to premature formalism; a chassis with didactic micro‑examples improves correctness of pins, names, and boundaries before deep formalisation.

#SoTA‑Echoing (informative)

This chassis is designed to stay compatible with modern (post‑2015) practice without confusing “SoTA” with “currently popular”:

• Evidence synthesis: living systematic review protocols (e.g., PRISMA‑style traceability and update cadence) map naturally to M2 wiring governed by G.2.
• Quality‑Diversity and archives: modern QD families (MAP‑Elites‑class, CMA‑ME‑class, and related archive‑based exploration) fit as M3/M4 extensions (C.18/C.19) because they require explicit descriptor/distance/insertion pins and preserve set‑valued outcomes.
• Open‑ended exploration: post‑2015 open‑endedness systems (POET‑class, paired/adversarial environment generation lines, and modern curriculum‑generation approaches) fit when treated as generator‑family wiring (governed elsewhere) rather than as chassis semantics.
• Set‑valued decision outputs: modern multi‑objective and set‑valued evaluation practices align with the G.Core set‑return discipline, preventing hidden scalarisation.
• Governed traceability: contemporary reproducibility and accountability norms (mechanism disclosure, provenance anchors, and audit trails) are supported via pinned policies/editions and explicit module boundaries, without introducing data‑governance machinery.

#Relations

Builds on: G.Core, E.8, E.10, E.19. Uses: A.10 (Provenance Anchors), A.15.3 (SlotFillingsPlanItem), A.19 (CN‑Spec), G.0 (CG‑Spec), G.2 (SoTA Synthesis Pack), G.3 (CHR Pack@CG‑Frame), G.4 (CAL Pack@CG‑Frame), G.5 (Selector & Dispatch), G.10 (Shipping), G.11 (Refresh Orchestration), and (via Extensions) C.17, C.18, and C.19. Publishes to / consumes from: Part‑F publication surfaces (UTS, naming, RSCR tests, Role/Concept artefacts) as cited by their governing definitions.

#G.1:End

#SoTA Harvester & Synthesis

Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative)

Purpose. Provide a repeatable, auditable way to discover, triage, and synthesize state‑of‑the‑art (SoTA) across competing Tradition lineages before minting CHR/CAL/LOG assets for a CG‑Frame. The primary output is a SoTA Synthesis Pack@CG‑Frame that feeds:

• naming/publication (UTS),
• CHR authoring (G.3),
• CAL authoring (G.4),
• method/generator registries and dispatch (G.5).

Scope note. This pattern governs the harvesting + synthesis generator in Part G. Shipping governing-definition assignment is in G.10, refresh orchestration governing-definition assignment is in G.11.

Terminology note (normative). In normative clauses below, Tradition refers to the Tech token Tradition (a plural lineage with internally coherent commitments). Plain “tradition” is allowed only as a 1:1 synonym.

#Problem frame

A team extends FPF into a new CG‑Frame. The relevant literature is typically:

• plural (multiple Tradition lineages with incompatible commitments),
• source- and use-sensitive (results depend on the exact source and edition, claim region, EntityOfConcern, comparison basis, evidence, and receiving use),
• method‑heterogeneous (different evidence styles, operator sets, and validity regions),
• time‑sensitive (rapid drift post‑2015; frequent benchmark/protocol shifts).

Downstream Part-G work in CHR, CAL, selection, shipping, and refresh depends on citation-ready claims that keep each exact CG-frame, source edition, claim region, EntityOfConcern, comparison basis, evidence anchor, and actual cross-source relation recoverable.

#Problem

How can we systematically assemble a SoTA view that is:

1. pluralist but comparable (plurality preserved; comparability is achieved only via explicit crossings),
2. evidence‑addressable (claims cite auditable evidence surfaces and anchors),
3. actionable (produces inventories and citable publication forms usable in G.3, G.4, and G.5 without treating a card as a meaning container or selector authority),
4. refreshable (editions/policies/windows are pinned so RSCR/refresh can re‑audit and re‑run without semantic drift)?

#Forces

• Pluralism vs. consolidation. Consolidation is valuable, but unqualified fusion destroys meaning.
• Breadth vs. load‑bearing depth. Too broad becomes shallow; too deep misses rival lineages.
• Recency vs. stability. Freshness matters, yet durable “backbone” claims must be identified and kept visible.
• Pedagogy vs. rigour. Outputs must be teachable enough to support review, while remaining audit‑ready.
• Authoring vs. operations. This pattern lives in the authoring plane; operational runs and decisions belong to Work planes and to governing patterns.

#Solution

#G.Core linkage (normative)

Builds on: G.Core (Part‑G core invariants; citation/delegation hub)

GCoreLinkageManifest (normative). (Canonical form, Nil‑elision, and Expansion rule are defined in G.Core.)

`GCoreLinkageManifest := ⟨ CoreConformanceProfileIds := { GCoreConformanceProfileId.PartG.AuthoringBase, GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted }, RSCRTriggerSetIds := {GCoreTriggerSetId.SoTAHarvestSynthesis}, CorePinSetIds := {GCorePinSetId.PartG.CrossingVisibilityPins},

CorePinsRequired := { // Scope pins (G.2‑specific) CGFrameId, // identifies the exact CG-frame, which is the declared framing episteme; its cited ClaimGraph keeps source and edition, claim regions, EntityOfConcern, comparison basis, and intended use recoverable Tradition[], entityOfConcern := ⟨GroundingHolon, ReferencePlane⟩, SoTA_SetId, SoTAPaletteDescriptionId,

// Evidence / provenance pins (G.2‑specific)
CorpusLedgerId,
FlowRecordId,
EvidenceAnchorRef[],
EvidenceGraphId?,

// Crossing / synthesis pins (delta beyond CorePinSetIds; only when used)
GammaEpistSynthId[]?,

// Edition / policy pins (only when used)
HarvestPolicyRef?,
DistanceDefRef.edition?,
InclusionCriteriaId?,
ScreeningRubricId?

},

DefaultsConsumed := ∅, TriggerAliasMapRef := ∅ ⟩`

(RSCR payload pins: ClaimSheetId[], SoTA_SetId, SoTAPaletteDescriptionId, BridgeMatrixId?, GammaEpistSynthId[]?, UTSRowId[]?, DistanceDefRef.edition?, HarvestPolicyRef?, InclusionCriteriaId?, ScreeningRubricId?, PathId/PathSliceId? when path‑citable evidence or a stable freshness window is pinned.)

Pattern‑local default rules (governed by this pattern; not a Part‑G‑wide DefaultId).

FamilyCoverageFloorK := 3 (unless explicitly overridden by HarvestPolicyRef and recorded in FlowRecord)

#Kit: SoTA Synthesis Pack@CG‑Frame (surface governed by this pattern)

A conforming G.2 publication produces a notation‑independent pack whose internal organisation is free, but whose exported named components and views are stable and citable:

Each named component is addressable via a stable pack‑local identifier (e.g., CorpusLedgerId, ClaimSheetId, FlowRecordId) for citation and RSCR scoping. If any component is minted/evolved as a public id, it is published and cited via UTSRowId[] per CC‑GCORE‑UTS‑1 (delegation).

0. SoTA_Set@CG‑Frame (export view; “M2 output” consumed downstream) A read‑optimised view over the harvested candidate set that downstream generator/selector work treats as the “harvester output set”. Constraint (normative): SoTA_Set@CG‑Frame MUST be reconstructible from pack components by id (no “hidden extra set”).

1. G.2a CorpusLedger Ledger of candidate sources. Each row names the exact source and edition, claim region used, triage status (for example, include, park, or retire), evidence locator, and rationale for this CG-frame and receiving use.

2. G.2b ClaimSheets[Tradition] Typed Claim Sheets per Tradition, each with:

   • exact source and edition, claim region, effective ReferenceScheme where meaning matters, EntityOfConcern, and comparison basis for the stated use,
   • explicit evidence anchors/citations (A.10 and/or EvidenceGraph refs when available),
   • explicit freshness window notes and risk/trust cues (cite B.3 governing definitions when using trust/decay language).

3. G.2c OperatorAndObjectInventory Inventory of candidate CHR terms (characteristics/scales/coordinates) and candidate CAL operators/flows as stubs for downstream authoring.

4. G.2d BridgeMatrix A citable alignment/divergence surface across Tradition×Tradition, with explicit losses and row scopes. If any row asserts substitution or fusion across sources or across Tradition records, the pack MUST attach a GammaEpistSynthId record (alias: G.2‑F) per G.2:Ext.GammaEpistSynthesis (no silent fusion).

5. G.2e MicroExamples Worked micro-examples for load-bearing claims. Each names the exact source and edition, claim region, EntityOfConcern, comparison basis, and intended use; cites its A.10 carrier or evidence path; and annotates applicable assurance types (TA, VA, or LA). The example card is only a publication form for those claims.

6. G.2f UTSProposals Draft Name Cards + Minimal Definitional Sheets (MDS) + alias proposals (incl. concept‑set linkage where applicable), with the required publication pins.

7. G.2g entityOfConcern Map Map from key terms/claims/public ids to GroundingHolon, ReferencePlane, and minimal reference cues for later CHR/CAL authoring.

8. G.2h PRISMA Flow Record A screening/eligibility trail for how sources entered the pack (method‑profile is allowed; see Extensions). (Name is historical; the artefact remains notation‑independent.)

9. G.2i SoSIndicatorFamilies Indicator families as variants (windows/constraints/assumptions) with explicit Acceptance branches per variant (branch ids/labels only; threshold semantics belong to CAL governing definitions).

10. G.2j MethodFamilyCards Candidate method families with a shared signature and a plurality of implementations, each with validity regions, cost/complexity notes, and known failure modes. When the pack targets downstream registry/dispatch, MethodFamily cards SHOULD include the declared refs and pins G.5 needs (eligibility predicate refs, assurance profile cues, and the pack ids that justify the family).

11. G.2k GeneratorFamilyCards (if applicable) Candidate generator families for environment/task generation with declared validity regions and transfer hooks.

12. G.2l Annexes (optional; governing-definition-cited; see Extensions) For example: QD/NQD annexes, discipline‑specific indicator annexes, interop forms.

SoTAPaletteDescription (export view; required downstream) A view‑friendly description object (pack‑local SoTAPaletteDescriptionId) that binds together:

• the SoTA_Set@CG‑Frame view,
• ClaimSheetId[], OperatorAndObjectInventory, BridgeMatrixId?,
• SoSIndicatorFamilies (with variant/branch structure),
• MethodFamilyCards / GeneratorFamilyCards?,
• MicroExamples, UTSProposals,
• and the entityOfConcern Map for citation and later CHR/CAL authoring. Note (normative intent): this is the primary “consumable surface” for G.3/G.4/G.5; it prevents downstream patterns from scraping free prose.

Editorial template: 1‑page “SoTA Sheet” per Tradition (informative). When authoring ClaimSheets[Tradition], teams often benefit from a single‑page template: scope + claims + evidence anchors + validity region + failure modes + freshness window + cross‑Tradition reuse notes + pointers to micro‑examples.

#Harvester loop (conceptual choreography; pattern-governed)

A conforming G.2 pack publication is built by iterating the following conceptual loop until the declared gates are satisfied:

1. Declare scope and plurality. Identify the exact CG-frame (the declared framing episteme), the initial Tradition set, each intended claim region and EntityOfConcern, the comparison basis, and the receiving use. Record the cited CG-frame and source editions and evidence anchors in the pack pins rather than hiding them in a generic context field.

2. Discover and triage sources (ledger‑first). Populate CorpusLedger via:

   • seed sources,
   • expansion via citation chaining and keyword family exploration,
   • pruning using load‑bearing relevance tests tied to the declared CG‑Frame scope.

3. Distill claims per Tradition. For each Tradition, author a Claim Sheet that preserves internal commitments and cites evidence anchors. Do not fuse cross‑Tradition claims at this stage.

4. Inventory operators/objects for downstream authoring. Extract candidate measurement terms and operator stubs for later CHR/CAL authoring (without asserting legality or thresholds locally).

5. Build alignment/divergence surfaces. Where reuse across Tradition is desired, author Bridge‑backed alignment records and explicit loss notes in BridgeMatrix. Any consolidation is explicitly marked as requiring alignment proof.

6. (Alias: G.2‑F) Produce Γ_epist synthesis records when fusion/substitution is asserted. If a G.2 pack publication asserts fusion or substitution across sources or across Tradition records (beyond mere “parallel divergent claims”), it MUST emit GammaEpistSynthId records per G.2:Ext.GammaEpistSynthesis (provenance union + explicit object alignment refs + assurance tuple refs), and it MUST keep penalties routed to R_eff only by delegation (CC‑GCORE‑PEN‑1).

7. Publish teachable micro‑groundings. Attach worked micro-examples to load-bearing claims, each tied to the exact source and edition, claim region, EntityOfConcern, comparison basis, intended use, and A.10 carrier or evidence path.

8. Apply gates and record repairs. Enforce FamilyCoverageFloorK (and any optional diversity‑by‑distance gate). If a gate fails, the pack MUST:

   • record the failure and the repair iteration in FlowRecord and CorpusLedger,
   • pin the updated HarvestPolicyRef / criteria ids (if changed),
   • iterate the loop rather than silently weakening the gate.

9. Emit hand‑off manifests and export views. Produce explicit manifests to:

• G.3 (CHR authoring),
• G.4 (CAL authoring),
• G.5 (registry/dispatch), so that downstream work can cite pack components by id rather than re‑authoring them. The pack MUST also export SoTA_Set@CG‑Frame and SoTAPaletteDescription as the default downstream consumption surfaces (ids pinned).

#Interfaces (minimal I/O Standard)

Note: Orchestration of re‑runs is governed by G.11; this pattern only defines what a conforming (re)harvest produces and what pins it must expose.

#Extensions (pattern‑scoped; non‑core)

Extensions are pattern‑scoped annexes. They do not introduce Part‑G‑wide norms; they declare the additional pins required when those semantics are active and cite the corresponding governing patterns.

#GPatternExtension: GammaEpistSynthesis

PatternScopeId: G.2:Ext.GammaEpistSynthesis GPatternExtensionId: GammaEpistSynthesis GPatternExtensionKind: GeneratorSpecific GoverningPatternId: G.2 Uses: {G.Core, B.3, F.9, G.6} (penalty routing + trust/decay cues + bridges/CL + evidence path citation when used) ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

• GammaEpistSynthId[] (pack‑local ids of synthesis records; emitted iff fusion/substitution is asserted)
• EvidenceAnchorRef[] (provenance union; A.10 carriers)
• BridgeMatrixId and BridgeCardId[] (explicit object alignment references when crossing is involved)
• CL/CL^plane + Φ/Ψ/Φ_plane policy-ids (ids only; semantics governed by cited definitions; penalties → R_eff only by delegation)
• PathId/PathSliceId? (only when citing via G.6)

RSCRTriggerKindIds: {RSCRTriggerKindId.EvidenceSurfaceEdit, RSCRTriggerKindId.CrossingBundleEdit, RSCRTriggerKindId.ReferencePlaneEdit, RSCRTriggerKindId.PenaltyPolicyEdit, RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.EditionPinChange}

Notes (normative intent; duplication‑avoidant):

• Γ_epist^synth is an auditable record that binds: (i) provenance union, (ii) explicit object alignment refs, (iii) assurance tuple refs (via existing governing definitions) for each asserted fusion/substitution.
• This extension does not redefine Γ‑fold, Φ, or penalty semantics; it only requires the pins/refs needed for replayability and auditability (see G.Core delegations).

#GPatternExtension: HarvestProtocols

PatternScopeId: G.2:Ext.HarvestProtocols GPatternExtensionId: HarvestProtocols GPatternExtensionKind: Phase3Seed GoverningPatternId: G.2 Uses: {B.3, A.10} (for freshness/decay and provenance anchors, when protocol requires them explicitly) ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

• HarvestPolicyRef (declares the chosen protocol family and its parameters)
• FlowRecordId (protocol‑specific profile id or rubric id may be attached here)
• InclusionCriteriaId / ScreeningRubricId (ids only; semantics remain local to the protocol family)

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

Notes (extension discipline):

• This extension binds a declared protocol profile to the pack’s FlowRecord without redefining evidence semantics.

#GPatternExtension: DHCAlignmentHooks

PatternScopeId: G.2:Ext.DHCAlignmentHooks GPatternExtensionId: DHCAlignmentHooks GPatternExtensionKind: DisciplineSpecific GoverningPatternId: C.21 (DHC semantics are governed by C.21) Uses: {C.21, G.6, G.7} (DHC series + evidence path citations + bridge/CL regimes when alignment density is claimed) ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

• DHCMethodRef.edition
• WindowRef? (if the DHC series is windowed)
• exact F.17 SchemeSenseCell refs used by the DHC comparison set (use SenseCellAddressRef where a durable address is needed; cite UTSRowId[] only for independently public ids)
• UTSRowId[]? (only if a cited cell or series id is independently minted or evolved as a public id)
• PathId[] / PathSliceId[] (when alignment summaries cite evidence paths via G.6)

RSCRTriggerKindIds: {RSCRTriggerKindId.EditionPinChange, RSCRTriggerKindId.EvidenceSurfaceEdit, RSCRTriggerKindId.TelemetryDelta}

Notes (extension discipline):

• If DHC alignment summaries are emitted, this extension ensures the DHC method edition and the cited evidence paths are visible.
• Units and constraints governed by C.21 are pinned, not redefined here: for example bridges_per_100_cells, the exact F.17 cell comparison set, exact F.9 Bridge refs, CL_min = 2, and the stated interpretation of CL=3 when used. The count is over named cells and obtaining relations, not contexts.

#GPatternExtension: NQDAnnex

PatternScopeId: G.2:Ext.NQDAnnex GPatternExtensionId: NQDAnnex GPatternExtensionKind: MethodSpecific GoverningPatternId: C.18 (NQD-CAL semantics are governed by C.18; explore/exploit logging is governed by C.19 when used) Uses: {C.18, C.19} ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

• DescriptorMapRef.edition
• DistanceDefRef.edition
• InsertionPolicyRef (policy‑id/ref)
• EmitterPolicyRef (policy‑id/ref)
• TaskSignatureRef? (when QD mode is trait‑gated)

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

Notes (extension discipline):

• This extension only pins the required references for replayability; it does not redefine QD semantics, dominance, or acceptance rules.

#GPatternExtension: InteropForms

PatternScopeId: G.2:Ext.InteropForms GPatternExtensionId: InteropForms GPatternExtensionKind: InteropSpecific GoverningPatternId: G.13 Uses: {G.13} ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

• ExternalIndexRef.edition
• ClaimMapperRef.edition
• MappingPolicyRef (policy‑id/ref)
• UTSRowId[] (for published external ids/aliases where relevant)

RSCRTriggerKindIds: {RSCRTriggerKindId.EditionPinChange, RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.TokenizationOrNameChange, RSCRTriggerKindId.EvidenceSurfaceEdit}

Notes (extension discipline):

• Interop affects only representation and citation routes; it must not introduce alternate legality gates or acceptance semantics.

#Palette first

• SoTAPaletteDescription is one plurality-preserving palette.
• It is not by itself one Front, one Archive, or one Shortlist.
• When that palette's members are traditions, TraditionPalette is the reader-facing tradition-only palette head over the same palette declaration, not one second governing definition. For methods, hypotheses, or other members, keep SoTAPaletteDescription or Palette + SubjectKind explicit instead.
• Traditions remain in the palette until a later surface declares comparison, retention, or choice semantics explicitly.
• TraditionFront is one derived view over the declared palette under one declared Q; the Q basis stays pinned separately and the view does not rename Tradition or SoTAPaletteDescription.
• TraditionArchive is one derived retention view over that same palette under one declared reachability or coverage rule; that rule stays pinned separately and the view does not turn the palette into one archive by default.
• When one derived tradition view is shown, keep the base palette recoverable at the same time.
• When comparison or retention needs richer geometry or atlas language, treat that as support for the derivation rather than as the default meaning of the palette.
• A reader should be able to say both this is the palette and this is the derived tradition view currently being shown without collapsing those two objects.

#Atlas views stay optional neighboring interpretation over one declared palette and declared set results

• TraditionAtlasView is one declared optional neighboring interpretive view over one palette and any declared front, archive, or shortlist surfaces drawn from it, while the cited substrate-bearing line, the active source set or active set result, and any cited SearchSpaceRef, OutcomeSpaceRef, or other declared space refs remain recoverable.
• TraditionAtlasView is the G.2 use-site specialization of DeclaredSubstrateAtlasView; keep the generic interpretive-view declaration in A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW.
• It is not the default meaning of Tradition or SoTAPaletteDescription.
• Stay palette-first when the harvest or synthesis question can already be judged from the declared palette together with ordinary front, archive, or shortlist surfaces.
• Use TraditionAtlasView only when the reader must hold several declared derived views or interpretive qualifiers together to see why one tradition grouping, omission risk, or comparison boundary matters.
• A conforming TraditionAtlasView must keep the same atlas-form interpretation declaration that A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW requires by value: recoverable base palette, active source set or active set result, TypedSetViews when several declared set views are held together, cited SearchSpaceRef, OutcomeSpaceRef, or other declared space refs, cited declared map refs such as OutcomeMapRef, cited qualifiers such as SpaceMetricRef, TransitionRelationRef, and BridgeDistortionNote, and one explicit reason why thinner DeclaredSubstrateInterpretiveView is insufficient here.
• It may help explain where one tradition, method family, or retained line sits relative to another, but it should not silently redefine the base palette or one derived front view or archive view.
• If one atlas view uses several typed views over the same source set, keep the active set result, any cited SearchSpaceRef, OutcomeSpaceRef, or other declared space ref, and any BridgeDistortionNote recoverable instead of letting TraditionAtlasView hide those choices.
• Treat the atlas layer as optional neighboring interpretation, not as ordinary palette-first core. Use SpaceMetricRef or TransitionRelationRef only when one declared comparison, reachability, transition, or cross-scale state-change claim actually depends on that formal support; otherwise leave them unstated.
• Use OutcomeMapRef only when the atlas must show how one declared set result maps into one outcome-side or effect-side declared space/ref; it does not turn the palette, front, archive, or shortlist into that outcome-side declared space/ref.
• If one atlas reading would materially change the base source-to-outcome relation or distortion posture, reopen the substrate declaration instead of treating that change as one local G.2 convenience.
• If one thinner DeclaredSubstrateInterpretiveView already keeps the question legible, prefer that thinner interpretation form and leave atlas specialization unused.
• SearchSpaceRef and OutcomeSpaceRef doctrine, transition-aware novelty, metric-transfer loss, and cross-scale geometry belong to a heavier formal layer: keep them outside ordinary palette-first use unless the current comparison, reachability, transition, or multilevel claim explicitly needs them, and do not pull them in merely because one richer comparative reading is mathematically available.
• If no declared atlas view is needed, stay with the simpler palette-first and declared-derived-view surfaces.
• Different atlas views may rely on different declared spaces, metrics, bridges, or transition supports; keep that plurality visible rather than forcing one geometry monoculture across every neighboring view.
• If several mathematical traditions remain plausible, keep that plurality visible rather than pretending the atlas already fixes one final formalism.
• If the question is naming-side only, use F.18 for that wording choice rather than letting atlas-form interpretation language carry the naming decision by itself.

#Archetypal Grounding (System / Episteme)

#Bias-Annotation (informative)

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did.

• Selection bias (Gov/Onto). Any harvesting protocol can over‑represent certain venues, languages, or evidence styles. Mitigation: pluralism floor + explicit CorpusLedger + explicit protocol pins.

• Consolidation bias (Onto/Epist). Pressure to “merge” lineages can erase incompatible commitments. Mitigation: keep Claim Sheets disjoint by default; require explicit alignment proof for fusion; preserve loss notes.

• Recency bias (Prag). Overweighting newest papers can hide durable backbone results; underweighting them misses SoTA drift. Mitigation: publish freshness windows and make them RSCR‑relevant.

• Didactic bias (Did). Micro‑examples can steer interpretation toward familiar domains. Mitigation: require heterogeneous substrates and explicit A.10 anchors.

#Conformance Checklist (normative) — CC‑G2

#Common Anti‑Patterns and How to Avoid Them

• AP‑G2‑1: “One true SoTA score.” Avoid: selecting a single unqualified scalar metric as “the” SoTA. Do instead: represent evaluation constructs as families/variants; keep partial orders set‑returning (delegated).

• AP‑G2‑2: Fusion without explicit alignment proof. Avoid: merging rival Tradition claims into one statement “by common sense.” Do instead: preserve parallel Claim Sheets; if consolidation is required, publish explicit alignment proof or keep a divergence record.

• AP‑G2‑3: Hidden protocol drift. Avoid: changing the harvesting protocol (inclusion criteria, windowing, screening rubric) without pins. Do instead: pin harvesting policy/profile ids and treat changes as RSCR‑relevant.

• AP‑G2‑4: Unanchored pedagogy. Avoid: micro‑examples without carriers (they become folklore). Do instead: bind micro‑examples to A.10 anchors and declare entityOfConcern.

• AP‑G2‑5: Atlas by default. Avoid: writing as if every tradition comparison or NQD/OEE note needs TraditionAtlasView, or as if atlas wording renames the palette itself. Do instead: keep the base palette and derived front, archive, or shortlist explicit; use atlas form only when several declared views or interpretive qualifiers must be held together, and prefer thinner DeclaredSubstrateInterpretiveView when that is enough.

#Consequences

• Positive: Downstream CHR/CAL/dispatch work becomes faster and less ambiguous because the pack is citable and structured.
• Positive: Plurality is preserved while still enabling disciplined comparability through explicit crossings.
• Positive: Refresh becomes tractable because pins and typed causes exist.
• Negative: Adds authoring overhead (ledger, flow record, micro‑examples, explicit pins).
• Negative: Requires governance discipline to prevent the pack from becoming an uncontrolled “everything bucket”.

#Rationale

SoTA synthesis is a bottleneck for new CG‑Frame work: without a disciplined harvest, downstream formalization (CHR/CAL) and operational selection (G.5) either (i) inherit hidden semantic collisions, or (ii) re‑invent incompatible “mini‑standards.” G.2 resolves this by treating SoTA work as a publishable kit: explicit plurality, explicit crossings, explicit evidence anchors, and explicit hand‑offs.

#SoTA-Echoing (informative)

This pattern aligns its method options (via Extensions and authoring practice) with widely used post‑2015 SoTA practices, while keeping FPF’s semantics stable and id‑based:

1. PRISMA 2020 reporting discipline (Page et al., 2021) Status: Adopt (adapted) — we adopt the idea of a transparent screening trail as FlowRecord, but keep it notation‑independent and concept‑level.

2. Living systematic reviews (Elliott et al., 2017 and subsequent living‑review practice) Status: Adopt (as optional protocol family) — the “living” stance is expressed as a harvesting protocol profile (Extension), with explicit freshness windows and RSCR‑relevant change causes.

3. AMSTAR 2 critical appraisal (Shea et al., 2017) Status: Adapt — we adapt the idea of structured quality appraisal into Claim Sheet evidence cues, without turning it into a single scalar rating.

4. Science of Science synthesis (Fortunato et al., 2018) Status: Adopt (as content discipline) — SoS indicators are treated as families/variants and wired as citable artefacts, not as a single “score”.

5. Disruption / team‑structure indicators (Wu, Wang & Evans, 2019 and follow‑on work) Status: Adopt (as exemplar family) — useful as an example of a SoS‑indicator family with material dependence on windowing and corpus definition.

6. Quality‑Diversity and open‑ended generation (e.g., Fontaine et al., 2020 for CMA‑ME; Wang et al., 2019 for POET) Status: Adopt (as optional annex with explicit pin declarations) — when QD/OEE is relevant for the CG‑Frame, we include generator/method family cards and pin the required edition/policy surfaces via G.2:Ext.NQDAnnex, without embedding those semantics into the core pack.

#Relations

• Builds on:

  • G.Core (core invariants, typed RSCR causes, Default Governing Definition Index)
  • E.8 (pattern template discipline)
  • E.10 (lexical/ontological rules; strict distinction; kind‑suffix discipline)
  • E.19 (conformance discipline)
  • A.10 (provenance anchors / carriers)
  • A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW (generic interpretive-view and atlas discipline when TraditionAtlasView is used)
  • A.6.P (space/view/publication precision restoration when palette/support claims collapse)
  • B.3 (trust, freshness/decay as cited governing patterns)
  • F.9 (bridges and CL as cited governing patterns)
  • F.17 (UTS publication discipline; via delegation)
  • G.0 (CG‑Spec legality gate; cited when legality surfaces are referenced)
  • G.6 (EvidenceGraph / path citation surfaces when used)

• Used by:

  • G.1 (generator chassis consumes harvested SoTA sets)
  • G.3 (CHR authoring consumes operator/object inventory and claim sheets)
  • G.4 (CAL authoring consumes operator stubs, acceptance branch scaffolding)
  • G.5 (registry/dispatch consumes MethodFamily/GeneratorFamily cards)
  • G.10 (shipping cites the pack as payload)
  • G.11 (refresh orchestration can re‑invoke harvest via typed causes)

• Relates to:

  • G.13 (interop surfaces when external indices are used)
  • F.18 (naming-side support wording when the question is label choice rather than synthesis geometry)

#G.2:End

#CHR Authoring for a CG‑Frame: Characteristics, Scales, Levels, Coordinates

Tag. Architectural pattern (CHR kit; publishes lawful measurement primitives; constrains CAL authoring and selector/dispatch use) Stage. design‑time (authoring & publication; enables admissible run-time consumption by G.4 / G.5) Primary output. CHR Pack@CG‑Frame — a notation‑independent, UTS‑published CHR bundle that provides: typed Characteristics/Scales/Levels/Coordinates, legality + guard surfaces, aggregation/comparison specs, RSCR hooks/tests, and provenance pins. Primary hooks. G.1 (declared CG-frame, which is the framing episteme), G.2 (SoTA synthesis inputs), A.19.CHR (CHRMechanismSuite boundary + pins), A.15.3 (SlotFillingsPlanItem baseline), A.18/C.16 (MM-CHR legality), F.0.1, F.1, F.9, F.17, and F.18 (source-local meaning, selected source editions, actual relations between local-sense cells, and bounded use and reliance), B.3 / B.3.4 (trust, freshness/decay), A.10 (provenance anchors/carriers), G.6 (EvidenceGraph/Path citation), optional C.18 and C.19 (QD/OEE wiring), G.11 (refresh orchestration). Non‑duplication note. Universal Part‑G invariants (bridge‑only crossings, tri‑state semantics, penalties→R_eff‑only, set‑return semantics, P2W split, typed RSCR triggers + alias docking, defaults with one governing definition, linkage discipline) are governed by G.Core. This pattern cites them via G.3:4.1 and delegates where needed.

#Problem frame

A team is defining or evolving a CG‑Frame (via G.1) and has plural, competing SoTA traditions and constructs (via G.2). The team needs a admissibility-ready CHR publication that makes downstream work possible without hidden semantic drift:

• CAL authoring (G.4) needs typed, admissible operands and guard/legality surfaces to build admissibility and acceptance rules (thresholds and policy cut‑offs remain governed by CAL).
• Selector/dispatch (G.5) needs CHR‑typed quantities and explicit provenance pins so selection can remain set-returning and auditable under admissible orders.
• Reuse beyond the defining source or use must name the exact characteristic and scale editions, bearer, scope and validity window, reference plane, evidence, and intended downstream use. Cite an F.9 relation only when it actually obtains between the named F.17 cells; any claim that relies on the relation for this use remains a separate F.18 use and reliance claim.

The resulting publication is a CHR Pack that is CG‑Frame‑scoped, notation‑independent, and UTS‑published, with explicit edition/policy pins sufficient for reproducibility and RSCR.

#Problem

Without a disciplined CHR authoring layer, teams repeatedly produce “measurable slots” that are numerically manipulable but semantically unlawful:

• Meaning leaks when the same token is reused after its referent or sense, bearer, scope, validity window, evidence basis, or intended use has changed.
• Illicit arithmetic (e.g., averaging ordinals, mixing units, laundering polarity).
• Hidden normalizations that silently change scale type, polarity, or admissible transforms.
• Unreproducible comparisons (missing edition pins for methods/distances/policies; unclear reference plane).
• Unscoped reuse (the characteristic or scale lacks an exact edition, bearer, scope and validity window, reference plane, evidence basis, or intended downstream use; any relation needed for reuse is left unstated).
• Un-auditable aggregation (no explicit legality surface and guard surface; no proof hooks; unclear Γ‑fold governing-definition assignment).
• Refresh chaos (changes in names/editions/policies do not map to typed RSCR causes).

#Forces

#Solution — CHR authoring kit and publication surface

#G.Core linkage (normative)

Builds on: G.Core (Part‑G core invariants; citation/delegation hub)

GCoreLinkageManifest (normative; size‑controlled).

`GCoreLinkageManifest := ⟨ CoreConformanceProfileIds := { GCoreConformanceProfileId.PartG.AuthoringBase, GCoreConformanceProfileId.PartG.TriStateGuard, GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted }, CorePinSetIds := { GCorePinSetId.PartG.AuthoringMinimal, GCorePinSetId.PartG.CrossingVisibilityPins },

// Pins strengthened for CHR authoring (delta over PinSets) CorePinsRequired := { // NOTE: the frame pin inherited from GCorePinSetId.PartG.AuthoringMinimal denotes only the exact // declared CG-frame, which is the framing episteme here; it supplies no universal setting, scope, or reuse authority. // entityOfConcern, CNSpecRef.edition, and CGSpecRef.edition remain inherited; each card adds the exact use pins named below. UTSRowId[], // required: CHR terms are public ids (Name Cards plus public-id continuity records) PathId[]/PathSliceId[], // required: worked examples/tests and refresh anchoring cite paths ReferencePlane, // required: definitional claims are plane-scoped Φ/Ψ/Φ_plane policy-ids?, // iff crossings/plane moves are exercised in examples or imports ΓFoldRef.edition? // iff an explicit Γ-fold artefact is pinned (otherwise use DefaultId) // NOTE: method-/discipline-specific pins (e.g., DescriptorMapRef/DistanceDefRef/DHCMethodRef/InsertionPolicyRef) // are declared only inside Extensions (e.g., G.3:Ext.QD_OEE_Wiring) to keep core linkage universal. },

// consumed iff any published CHR.AggregationSpec relies on default Γ-fold (no explicit override pinned) DefaultsConsumed := { DefaultId.GammaFoldForR_eff },

RSCRTriggerKindIds := { RSCRTriggerKindId.EvidenceSurfaceEdit, RSCRTriggerKindId.TokenizationOrNameChange, RSCRTriggerKindId.CrossingBundleEdit, RSCRTriggerKindId.ReferencePlaneEdit, RSCRTriggerKindId.EditionPinChange, RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.DefaultGoverningDefinitionChange, RSCRTriggerKindId.FreshnessOrDecayEvent, RSCRTriggerKindId.LegalitySurfaceEdit, RSCRTriggerKindId.BaselineBindingEdit } ⟩`

(Nil‑elision + expansion rule are per G.Core:4.2. This pattern does not redefine the semantics of core conformance ids, trigger kinds, or defaults; it only declares applicability and required pins.)

#Output surface: CHR Pack@CG‑Frame (normative)

CHR Pack@CG‑Frame is the CHR kit payload that downstream patterns cite and pin (it is not a “shadow spec” for CN/CG).

Minimum exported objects (kit surface):

• CHR.Characteristic[]
• CHR.Scale[]
• CHR.Level[] (when the scale type requires explicit level sets / order structure)
• CHR.Coordinate[] (encodings + legality annotations; never an implicit “upgrade” of measurement structure)
• CHR.Guards (guard macro surface; semantics governed by cited definitions; see G.Core and A.18)
• CHR.LegalityMatrix (admissible operations per scale type / unit / polarity regimes)
• CHR.AggregationSpecs (typed aggregators/comparators + proof hooks + edition pins where applicable)
• UTS publication bundle: Name Cards (twin labels), public-id continuity notes, and (when applicable) bridge and loss notes
• RSCR artefacts: RSCRTestId[] + worked examples + provenance pins (ReferencePlane, Path/PathSlice, policy ids)

Mandatory provenance pins (conceptual, notation‑independent):

• ReferencePlane
• PathId/PathSliceId citations for worked examples/tests
• R‑anchors (conceptual; KD‑CAL lanes when used) realised via PathId/PathSliceId and, where applicable, A.10 anchor/carrier refs
• policy pins used by crossings or plane moves (when exercised)
• edition pins for any referenced method or metric definitions that affect interpretation

#CHR authoring chassis (S1–S8)

S1 — Charter the measurement scope (scope anchor). Identify the exact declared CG-frame (the framing episteme). For this CHR work, state the bearer or bearers and identify each as an entityOfConcern. Also state the scope, any applicable qualification and evaluation windows, ReferencePlane, evidence basis, intended downstream use, freshness or decay expectations, and any contested expression whose reuse may require an actual F.9 relation. Output a design-time MeasurementCharter and KindMap. If freshness/decay expectations are anything beyond an explicit “non‑decaying” declaration, wire them via G.3:Ext.DecayWiring (governing pattern: B.3.4) rather than encoding decay semantics in CHR prose. If assurance‑subtype lane tags are used (e.g., TA/VA/LA), declare the lane regime here so downstream evidence discipline can remain lane‑pure (taxonomy/semantics governed by B.3; evidence‑path representation & audit governed by G.6; this pattern only records wiring). Lane docking (wiring‑only; normative). If EvidenceLanes are used, the charter MUST:

• enumerate the lane tags used (e.g., TA/VA/LA) and cite their governing pattern taxonomy (governed by B.3), plus the upstream provenance for their use when available (e.g., SoTAPaletteDescriptionId via G.3:Ext.SoTAPackInputs);
• expose any lane‑dependent tolerances / proof requirements via explicit pins (policy‑id and/or edition‑pinned refs), not prose;
• treat lane tags as provenance metadata (not Contexts): they MUST NOT be “bridged away” or silently mixed;
• if any cross‑lane comparison/aggregation is claimed, it MUST be explicit and pinned to the governing acceptance/evidence policy (typically G.4) and auditable via evidence paths (G.6); otherwise downstream consumers treat it as illegal. Crossing semantics and penalty routing are cited via G.Core (do not restate).

S2 — Mint or reuse terms (UTS‑first). For each candidate characteristic, scale, level, or coordinate term: attempt reuse; otherwise mint via UTS Name Cards with twin labels and public-id continuity notes. When a term is imported across contexts, the import must be explicit and auditable (bridge and loss notes live with the crossing artefacts; CHR only cites them).

S3 — Define CharacteristicCard (the CHR unit of meaning). A CharacteristicCard is the minimum unit CHR publishes for downstream legality. It SHOULD include (field names are indicative; semantics governed by cited definitions):

CharacteristicCard := ⟨ UTSRowId, CharacteristicRef.edition, entityOfConcern, ClaimScope, ApplicableSliceRef[], QualificationWindow?, EvaluationWindow?, MeasurementMethodRef.edition?, MeasurementModelRef.edition?, EvidenceRef[], IntendedDownstreamUse, ReferencePlane, ObjectKind, Intent, Definition (typed), ObservableOf := ⟨instrument/protocol (A.10 anchors/carriers), uncertainty model, validity window⟩, EvidenceLanes? (KD‑CAL lanes; wiring only; semantics governed by G.4/G.6), ScaleRef.edition, Polarity ∈ {↑, ↓, ⊥}, Domain/Range, UnitSet, Bounds / zero semantics (as applicable), Freshness / half‑life (or explicit NonDecayingDecl; freshness/decay semantics governed by B.3.4), Missingness semantics (typed; include a classification/mapping when non‑trivial; downstream tri‑state handling is per G.Core), Stability/Reliability notes, RoleDecls? := RoleDecl[] (wiring‑only; each role declaration names its governing pattern + required pins; see G.3:4.5), QD.Role? ∈ {Q, D, QD-score} (interop alias for RoleDeclwithGoverningPatternId = C.18; see G.3:Ext.QD_OEE_Wiring), Micro‑examples (R‑anchors: Path/PathSlice cited; lane tags where applicable) ⟩

Where RoleDecl := ⟨ roleLabel, GoverningPatternId, EditionPins?, PolicyPins? ⟩ (wiring-only; the value of GoverningPatternId names the FPF pattern that governs the role declaration semantics).

Rules (CHR‑governed intent, semantics governed by cited definitions where indicated):

• Scale/unit/polarity legality obligations cite MM‑CHR governing definitions (A.18 and C.16) and must be checkable by downstream patterns.
• Missingness must be typed so downstream can apply tri‑state outcomes without silent coercion (tri‑state semantics are governed by G.Core).
• If EvidenceLanes are recorded, they are only lane tags for downstream evidence discipline (taxonomy governed by B.3; audit surface: G.6; any cross‑lane policy is governed by G.4); this pattern does not introduce lane semantics or invent bridge‑like constructs.
• If RoleDecls are used, each declaration MUST cite the FPF pattern that governs the declaration, for example C.18 or C.19, and surface the edition and policy pins required by that governing pattern; CHR does not define role semantics locally.
• Role docking (normative, wiring-only): if any RoleDecl is present with GoverningPatternId = X, then G.3 MUST include (or explicitly cite) a corresponding GPatternExtension block whose governing definition is X (or whose Uses includes X) and that surfaces the required pins for that role family. Otherwise the role declaration is non-conformant (it is an undocked semantic fragment).
• Freshness docking (normative, wiring-only): if a characteristic’s freshness/half-life is defined via a named decay model/policy (rather than a pure local statement), the relevant policy/ref MUST be pinned and cited through B.3.4 via G.3:Ext.DecayWiring.
• If a characteristic is intended to be promoted into CG‑Spec, the linkage is explicit and edition‑pinned (wiring lives in an Extension; semantics governed by G.0).

S4 — Define ScaleCard and LevelCard (lawful measurement). Publish the scale type and admissible transforms, plus levels/orders when applicable. CHR does not invent new legality semantics; it cites MM‑CHR governing definitions and makes the legality surface concrete for the frame’s characteristics.

Typical distinctions that must be representable:

• Nominal / categorical: equality + counting; transforms are permutations.
• Ordinal: order‑preserving transforms; no arithmetic that presupposes intervals.
• Interval: affine transforms; differences meaningful; means may be lawful if justified.
• Ratio: positive scalar transforms; ratios meaningful; products/sums subject to unit discipline.
• Count / rates: explicit exposure/timebase requirements; rate conversions must be explicit.
• Cyclic: wrap‑around discipline + principal interval declaration.

S5 — Define CoordinatePolicy (encodings without hidden cardinalization). When a numeric coordinate/embedding is used for convenience or tooling, CHR MUST publish:

• what invariants are preserved (order only / ratios / topology / wrap‑around),
• what remains illegal,
• what proof hooks are required if a structure with higher scale-type commitment is claimed.

A coordinate never silently upgrades a scale type; if an upgrade is claimed, the proof requirement is explicit and carried by MM-CHR governing definitions.

S6 — Publish legality + guard surfaces (Guard Macros + LegalityMatrix). CHR publishes a CHR.LegalityMatrix and a CHR.Guards surface that downstream operators can reference.

Guard macro names are allowed as authoring ergonomics, but their semantics MUST cite governing definitions (no “shadow semantics” in this pattern). Examples of macro intents (governing definitions in parentheses):

• CSLC_PROOF_REQUIRED(x) (MM‑CHR legality governing definitions: A.18/C.16)
• UNKNOWN_TRI_STATE(x) (tri‑state semantics governed by G.Core)
• UNIT_CHECK(x) (MM‑CHR legality governing definitions)
• RETURN_SET_FOR_PARTIAL_ORDERS() (set‑return semantics governed by G.Core)
• METRIC_EDITION_REF(...) (edition‑pin discipline governed by G.Core; metric semantics governed by C.18/C.21 as applicable)

S7 — Publish AggregationSpecs (typed, admissible, reproducible). CHR may publish typed aggregation/comparison specs that are safe by construction and usable as building blocks by G.4 and G.5. For any published spec:

• The legality regime is explicit (scale/unit/polarity constraints + required proof hooks).
• If a contributor folding policy (Γ‑fold) is used and not explicitly overridden, cite DefaultId.GammaFoldForR_eff through G.Core.DefaultGoverningDefinitionIndex; do not restate the default here.
• If method‑role declarations imply metric‑driven comparisons (e.g., QD roles), the relevant edition/policy pins are surfaced (wiring lives in an Extension; semantics governed by the referenced patterns).

S8 — Publish, test, and evolve (UTS + RSCR readiness). Publish the CHR pack and associated Name Cards to UTS. Attach:

• RSCR tests that check legality and guard coverage and reject illegal ops,
• worked examples with Path/PathSlice provenance,
• refresh/decay notes and deprecations with lexical continuity.

This step prepares the RSCR loop but does not govern orchestration (governing definition: G.11).

#Interfaces (normative)

#Extensions (pattern‑scoped; non‑core)

All blocks below are GPatternExtension modules (PatternScopeId-scoped; not new PatternIds). They store wiring only and cite governing patterns.

GPatternExtension: SuiteBoundaryLinkage

• PatternScopeId: G.3:Ext.SuiteBoundaryLinkage

• GPatternExtensionId: SuiteBoundaryLinkage

• GPatternExtensionKind: InteropSpecific

• GoverningPatternId: A.19.CHR

• Uses: {A.19.CHR, A.15.3}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • CHRMechanismSuiteDescriptionRef.edition? (when the suite description is cited as a reproducibility baseline)
  • CHRMechanismSuiteSlotFillingsPlanItem refs (when planned baseline binds CHR artefacts into WorkPlanning)

• RSCRTriggerKindIds: {RSCRTriggerKindId.BaselineBindingEdit, RSCRTriggerKindId.EditionPinChange}

• Notes (wiring‑only): This module binds CHR authoring outputs to the P2W seam (SlotFillingsPlanItem); suite semantics and membership are governed by A.19.CHR.

GPatternExtension: SoTAPackInputs

• PatternScopeId: G.3:Ext.SoTAPackInputs

• GPatternExtensionId: SoTAPackInputs

• GPatternExtensionKind: DisciplineSpecific

• GoverningPatternId: G.2

• Uses: {G.2}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • ClaimSheetId[] / operator & object inventory refs (as cited inputs)
  • SoTAPaletteDescriptionId? (when palette/traces are cited; used to dock contested‑term inventory and (if present) lane tags/tolerances)
  • BridgeMatrixId? (when terms/constructs are imported across traditions)
  • UTSRowId[] drafts/aliases from synthesis

• RSCRTriggerKindIds: {RSCRTriggerKindId.EvidenceSurfaceEdit, RSCRTriggerKindId.TokenizationOrNameChange, RSCRTriggerKindId.CrossingBundleEdit}

• Notes (wiring‑only): SoTA pluralism inputs are governed by G.2; this module only specifies which synthesis artefacts are cited while authoring CHR.

GPatternExtension: CGSpecPromotionWiring

• PatternScopeId: G.3:Ext.CGSpecPromotionWiring

• GPatternExtensionId: CGSpecPromotionWiring

• GPatternExtensionKind: InteropSpecific

• GoverningPatternId: G.0

• Uses: {G.0}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • CGSpecRef.edition (when a characteristic is promoted/linked into CG‑Spec)
  • CHR.Characteristic.id pointers included in CG‑Spec.Characteristics := [...] (no shadow ids; CG‑Spec stores pointers, see G.0)

• RSCRTriggerKindIds: {RSCRTriggerKindId.LegalitySurfaceEdit, RSCRTriggerKindId.EditionPinChange, RSCRTriggerKindId.PolicyPinChange}

• Notes (wiring‑only): Promotion semantics and legality gate governing-definition assignment stays with G.0; CHR only pins and cites.

GPatternExtension: MMCHRLegalityWiring

• PatternScopeId: G.3:Ext.MMCHRLegalityWiring

• GPatternExtensionId: MMCHRLegalityWiring

• GPatternExtensionKind: DisciplineSpecific

• GoverningPatternId: A.18

• Uses: {A.17, A.18, C.16}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • CSLC legality proof anchors/carriers (ids/refs as defined by MM‑CHR governing definitions; cite A.18/C.16)
  • Unit coherence references (where units exist)

• RSCRTriggerKindIds: {RSCRTriggerKindId.LegalitySurfaceEdit, RSCRTriggerKindId.ReferencePlaneEdit}

• Notes (wiring‑only): This module wires CHR artefacts to MM‑CHR legality proof obligations; legality semantics are governed by the referenced patterns.

GPatternExtension: DecayWiring

• PatternScopeId: G.3:Ext.DecayWiring

• GPatternExtensionId: DecayWiring

• GPatternExtensionKind: DisciplineSpecific

• GoverningPatternId: B.3.4 (freshness/decay semantics)

• Uses: {B.3.4, G.6}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • FreshnessWindowDeclRef (or equivalent window pin, as defined by the governing definition)
  • DecayPolicyIdRef? (policy-bound; if decay model is referenced by id)
  • PathSliceId[] (affected evidence carriers / examples that witness drift)

• RSCRTriggerKindIds: {RSCRTriggerKindId.FreshnessOrDecayEvent, RSCRTriggerKindId.EvidenceSurfaceEdit, RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.BaselineBindingEdit}

• Notes (wiring‑only): CHR does not define decay semantics; it only pins the defined by the governing pattern window/policy and ensures refresh can be triggered on decay events.

GPatternExtension: QD_OEE_Wiring

• PatternScopeId: G.3:Ext.QD_OEE_Wiring

• GPatternExtensionId: QD_OEE_Wiring

• GPatternExtensionKind: MethodSpecific

• GoverningPatternId: C.18

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • DescriptorMapRef.edition (if any Characteristic declares descriptor roles)
  • DistanceDefRef.edition (if any Characteristic declares distance roles)
  • DHCMethodRef.edition (if any Characteristic is used as Q / QD-score)
  • InsertionPolicyRef? (when archive insertion semantics are declared for reproducibility)

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

• Notes (wiring‑only): QD/OEE semantics are governed by C.18 and C.19. CHR only surfaces method‑role declarations (via RoleDecls or the interop alias QD.Role) and the edition/policy pins required for reproducible archive/front interpretation.

#Archetypal Grounding

AG‑1 — ML fairness auditing (post‑2015 selective and set‑valued practice). System: a CG‑Frame for evaluating deployed classifiers across cohorts with explicit abstention/defer behavior. CHR authoring: publish DemographicParityGap and EqualizedOddsGap as Characteristics with:

• explicit ReferencePlane (deployment population + sampling regime),
• ObservableOf (audit protocol + uncertainty model + window),
• interval scale (bounded; zero semantics explicit),
• missingness semantics (cohort sparsity and label noise are typed),
• legality surfaces and guard surfaces that forbid illicit cohort mixing and require explicit proof hooks for aggregation across cohorts.

Downstream: CAL acceptance binds thresholds and failure behavior; selector remains set‑returning under partial orders and may treat “defer/abstain” as a first‑class outcome (tri‑state semantics pinned through G.Core).

AG‑2 — Clinical diagnostics (post‑2015 evidence‑aware evaluation). System: a CG‑Frame for comparing diagnostic pipelines under evolving datasets and protocols. CHR authoring: publish Sensitivity and Specificity as ratio‑scale, dimensionless Characteristics on [0,1], with:

• explicit ObservableOf (trial protocol, inclusion criteria, uncertainty model),
• freshness/decay expectations (protocol drift is modelled as decay),
• legality surfaces that forbid averaging incompatible ordinal labels (e.g., severity grades) and require explicit unit/exposure constraints for any derived rate.

Downstream: CAL acceptance governs thresholds and guard‑bands; evidence wiring is cited via Path/PathSlice to make refresh triggers actionable.

AG‑3 — Quality‑Diversity / Illumination (post‑2015 MAP‑Elites/CMA‑ME lineage). System: a CG‑Frame where selection returns archives/fronts rather than a single winner. CHR authoring: declare which Characteristics play Q/D/QD‑score roles and pin the metric definitions (descriptor map, distance definition, method editions) so archives are reproducible across runs and refresh can be triggered on edition changes. CHR does not scalarize partial orders; set‑return semantics are pinned through G.Core.

#Bias‑Annotation

CHR authoring is where many biases become “baked in” as measurement choices. Typical risks:

• Proxy bias: a convenient observable substitutes for the intended construct. Mitigation: require ObservableOf + ReferencePlane + micro‑examples; force explicit “what is being measured” rather than relying on labels.
• Population and protocol shift: a characteristic’s meaning changes when the sampling regime or protocol changes. Mitigation: explicit validity windows and freshness/decay expectations; edition pins for protocol definitions; RSCR triggers on freshness/decay events and evidence surface edits.
• Ordinal misuse bias: ordinal ratings treated as interval/ratio by convenience. Mitigation: publish scale type + admissible transforms; legality matrix + guard macros; reject coordinate upgrades without proof hooks.
• Cross-tradition meaning bias: an imported expression erases its source-local meaning or makes a changed bearer, scope, window, reference plane, evidence basis, or intended use disappear. Mitigation: name those values, cite exact F.17 cells and an F.9 relation only when it obtains, and keep any downstream use and reliance explicit under F.18. Loss remains visible through the applicable G.Core penalty rule rather than silently altering Part F or Part G semantics.
• Metric gaming bias (QD and evaluation): changing descriptors/distances changes what “diverse” means. Mitigation: edition‑pin metric definitions and make role declarations explicit (wiring via C.18 and C.19).

#Conformance Checklist (normative)

#Common Anti‑Patterns and How to Avoid Them

• Hidden cardinalization. Don’t treat ordinal encodings as interval/ratio; do publish coordinate policies that explicitly preserve order‑only invariants and forbid arithmetic upgrades.
• Unit laundering. Don’t add or average quantities with incompatible units; do force explicit unit discipline and legality checks via MM‑CHR governing definitions.
• Polarity drift. Don’t rely on “higher is better” implicitly; do publish polarity explicitly and make downstream use auditable.
• Threshold leakage into CHR. Don’t embed policy cut‑offs in CHR; do keep thresholds in CAL acceptance artefacts.
• Unpinned semantics. Don’t cite “the metric” or “the distance” without edition pins; do require edition‑pinned references when semantics affect interpretation.
• Unscoped reuse. Don’t reuse a characteristic or scale beyond its defining source and use on token continuity alone. Name the exact editions, bearer, scope and applicable window, reference plane, evidence, and intended downstream use; cite F.9 only when an actual relation between the named local senses is needed and obtains.

#Consequences

• Legality becomes checkable. Downstream patterns can reject illegal operations and rely on explicit legality surfaces rather than implicit conventions.
• Comparability without semantic flattening. Plural traditions remain representable because CHR preserves local meaning while making lawful relations explicit.
• Reproducible downstream behavior. Edition/policy pins make “why did this change?” answerable and RSCR actionable.
• Authoring overhead. The pattern shifts effort to up‑front authoring: explicit cards, pins, and tests are non‑optional when CHR becomes a public kit surface.

#Rationale

CHR is the point where “numbers start moving” only if measurement semantics are stable enough to support lawful downstream reasoning. By making scale/unit/polarity explicit, publishing legality and guard surfaces, and requiring provenance pins, CHR authoring prevents downstream mechanisms from silently inventing their own legality assumptions.

Separating core invariants into G.Core prevents drift and ensures Part‑G‑wide properties (tri‑state, penalty routing, set‑return semantics, RSCR typing, Default Governing Definition Index) cite G.Core as their governing definition, while CHR remains responsible for CHR‑specific kit surfaces.

#SoTA‑Echoing

This pattern aligns with post‑2015 best practice by:

• treating abstention/defer and set‑valued outcomes as first‑class design objects (consistent with modern selective prediction and set‑valued reporting practice),
• keeping multiobjective and archive‑based reasoning set‑returning rather than silently scalarizing (consistent with QD/illumination and open‑ended evaluation practice after 2015),
• making evaluation semantics reproducible through explicit edition/policy pinning (aligned with the modern emphasis on reproducibility and “specifying the evaluation surface” rather than only reporting metrics),
• modularizing method‑family specifics (QD/OEE, explore‑exploit) via explicit wiring and governing-definition assignment rather than embedding method semantics into universal measurement admissibility.

#Relations

Builds on: G.Core, G.1, G.2, G.6 (EvidenceGraph / Path citation), A.19.CHR, A.15.3, A.17–A.18/C.16 (MM-CHR), F.0.1 (source-local meaning), F.1 (source selection), F.9 (actual relations between local-sense cells), F.17 (scheme-sense cells), F.18 (bounded use and reliance), B.3 / B.3.4, A.10, E.10, E.5.1–E.5.3. Uses (via Extensions): G.0 (promotion/linkage to CG‑Spec), optional C.18 and C.19 (QD/OEE wiring). Publishes to: G.4 (admissible operators plus legality and guard macros and freshness pins), G.5 (role declarations plus pins for reproducibility), UTS (Name Cards and public-id continuity notes), RSCR tests and hooks. Constrains: any CAL/LOG/selector usage that consumes CHR (must treat CHR artefacts as typed/legal surfaces, not as prose hints).

#G.3:End

#CAL Authoring for a CG-Frame: Operators, Acceptance Clauses, Evidence Wiring

Use this when. A team has typed characteristics and now needs to publish reusable operators, acceptance clauses, and legal compositions before any candidate is actually evaluated. The working object is one design-time CAL Pack@CG-Frame, not an evaluation run, verdict, selector outcome, assurance case, or decision.

First move. Write one plain acceptance statement for one task: “For subject x within ClaimScope S and evaluation window W, apply operator O to a C.16 measurement result for Characteristic K that argument declaration R admits. In the actual application, bind current result episteme E; clause A returns pass | fail | unknown under threshold or policy P and its currentness rule.” Then turn only the reusable nouns into stable CAL declarations. E belongs to the later application, not to reusable clause A.

Smallest viable CAL pack. Publish one charter for the exact CG frame, one typed operator card, one acceptance clause with ClaimScope, evaluation window, and unknown or failure behavior, one legal flow, one evidence and currentness profile, one proof-or-gap row, one worked declaration example, and a minimal editioned TaskMap that cites the exact charter, the C.22 TaskSignatureRef, and the declaration refs used by selection. Stop there when this pack answers the task; method-family extensions, archive surfaces, crossing records, and additional policy pins enter only when the case actually needs them.

What changes in practice. Thresholds and failure behavior stop hiding in code, illegal arithmetic becomes an authoring defect, and runtime workers can cite stable declarations without pretending that a card, flow, manifest, proof row, or stored evidence ref performed an evaluation.

Not this pattern. Use C.16 for the measurement result, A.19 for comparison or selection, A.13 and A.15.1 for each precise performer and independently admitted dated evaluation Work, F.6 only when exact assignment-bound attribution is current, A.6.1 for actual bindings, C.2.1 for the verdict episteme, A.10/G.6 for provenance, G.11 for currentness, B.3 for assurance, and C.11 for a decision. If the immediate question is whether a declared clause actually ran and what result obtained, go directly to the declaration-to-runtime boundary in §4.4a.

#Problem frame

A CG‑Frame has:

• one exact CG‑Frame with its EntityOfConcern, ReferencePlane, task, and assumption envelope,
• a plurality of method traditions and claims (SoTA inputs), and
• CHR‑typed measurement constructs (Characteristic/Scale/Coordinate + legality guard macros).

Before any run‑time selection, comparison, aggregation, or selected-set formation is executed downstream, the CG‑Frame needs an explicit, auditable CAL Pack that:

1. defines what operators exist and what they are allowed to do over CHR types,
2. externalizes fit-for-purpose acceptance as typed predicates whose use is bounded by an exact ClaimScope, evaluation window, and any separate qualification window that limits use, and
3. binds these choices to an evidence wiring surface (lanes, provenance anchors, policy pins, and refresh triggers) so that downstream selection, logging, parity, and shipping can cite stable ids rather than re‑inventing semantics.

This pattern provides the design‑time authoring kit and the publication surface for CAL artifacts, while delegating Part‑G‑wide invariants to G.Core and CN-Spec and CG-Spec legality to CG‑Spec/CN‑Spec.

#Problem

Teams repeatedly face drift and ambiguity in the CAL Pack that sits between “typed measurements exist” and “a selector/dispatcher runs”:

• Illicit operations slip in (implicit cardinalization, unit laundering, ordinal arithmetic).
• Acceptance is scattered (thresholds embedded in code or in CHR prose; predicates not typed; unknown handling inconsistent).
• Evidence wiring is underspecified (which provenance anchors matter, what policy ids are in force, what is plane‑scoped, what changes must trigger refresh).
• Cross-sense or cross-plane imports are silent (hidden reuse across distinct source-local meanings, ReferencePlanes, or editions without the obtaining relation, required crossing records, and loss accounting).
• Tooling artifacts become semantics (vendor flags or implementation details substitute for a conceptual specification).

#Forces

• Expressiveness vs legality. CAL must allow useful comparisons/aggregations while staying lawful under CHR typing and legality gates.
• Pluralism vs comparability. Multiple method traditions must coexist without forcing premature unification, yet remain cross‑citable and auditable.
• Decision support vs auditability. CAL must support selection and selected-set formation while preserving explicit, reviewable assumptions and proofs.
• Exploration vs assurance. CAL must support exploratory regimes (probing, novelty, open‑ended search) without letting un‑assured outputs silently become dominance claims.
• Locality vs portability. Each CAL clause stays bounded by its declared ClaimScope, window, source meanings, and ReferencePlane; reuse beyond that boundary requires the exact relation and crossing records that the changed value calls for.

#Solution — author the smallest lawful CAL pack

#Practitioner authoring path C1–C9

Complete these actions in order; widen a step only when its stated input is needed by the current task.

1. C1 — Charter the scope. Name the exact CG‑Frame, EntityOfConcern, ReferencePlane, task, CNSpecRef.edition, and CGSpecRef.edition. State the assumption envelope in ordinary language.
2. C2 — Declare one typed operator. Give it a stable id, CHR-typed signature, preconditions, result kind, and failure behavior. This is an A.6.1 operation declaration, not evidence of an application.
3. C3 — Declare one acceptance clause. Name the exact Characteristic and the A.6.1 argument declaration that admits the corresponding C.16 measurement-result episteme, then declare the predicate or threshold, ClaimScope, evaluation window, any separate qualification window that limits use, unknown handling, and the stated stop, degrade, or abstain behavior. Keep the exact current result episteme for the later application. If the clause claims statistical risk or coverage control, also name the loss, target, calibration population and window, sampling or exchangeability assumptions, declared treatment of shift, and the exact policy that states the guarantee.
4. C4 — Compose only a legal flow. Cite the operators and gating clauses, preserve the lawful result kind, and keep a selected set when no lawful scalarization exists. A declared DAG is possible composition, not performed work.
5. C5 — Name the minimum evidence/currentness need. Cite the exact A.10 source/provenance anchors and G.11 window needed to judge the clause. Do not turn an evidence profile, citation, or graph membership into a verdict or actual reliance.
6. C6 — Add an extension only when the task needs one. Select its current subject pattern first, then pin only the descriptor, distance, insertion, exploration, branch, or path records that change the present CAL action. Otherwise omit the extension.
7. C7 — Record proof or an explicit gap. For every operator, flow, or clause, cite the legality/monotonicity/boundedness justification actually required; when it is missing, publish the gap and the consequent degrade/abstain behavior.
8. C8 — Exercise declaration behavior. Provide one worked authoring example and focused conformance tests for illegal operations, pass | fail | unknown, freshness, and failure behavior. The example and test remain declarations/test records unless separately grounded dated work is named.
9. C9 — Publish and hand off. Mint stable ids and continuity notes, then emit the smallest immutable TaskMap edition. It cites the exact charter edition, the already constituted C.22 TaskSignatureRef, the task, and edition-bearing operator, flow, gating-clause, and evidence-profile refs; the cited evidence profiles carry the needed currentness pins. It neither constructs the TaskSignature nor copies clause thresholds. Use G.11 for change refs; G.4 defines no refresh rule or runtime occurrence or result.

The authoring path is complete when a cold reader can reconstruct the plain acceptance sentence from the published ids and can also say what still has to happen at runtime. The maintainer-facing manifests, schemas, interfaces, and optional extension blocks below make the same pack machine-citable; they do not add another practitioner sequence.

#G.Core linkage (normative)

Builds on: G.Core (Part‑G core invariants; citation/delegation hub)

GCoreLinkageManifest (normative). Canonical shape, Nil‑elision, and the Expansion rule are defined in G.Core.

`GCoreLinkageManifest := ⟨ CoreConformanceProfileIds := { GCoreConformanceProfileId.PartG.AuthoringBase, GCoreConformanceProfileId.PartG.TriStateGuard, GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted, GCoreConformanceProfileId.PartG.ShippingBoundary },

CorePinSetIds := { GCorePinSetId.PartG.AuthoringMinimal, GCorePinSetId.PartG.CrossingVisibilityPins },

CorePinsRequired := { UTSRowId[], // CAL artefacts are public ids (Name Cards plus public-id continuity notes) ΓFoldRef.edition? // only when an explicit Γ‑fold override is pinned (otherwise use DefaultId) },

// consumed iff no explicit ΓFoldRef.edition override is pinned DefaultsConsumed := { DefaultId.GammaFoldForR_eff },

RSCRTriggerSetIds := { GCoreTriggerSetId.SoTAHarvestSynthesis }, RSCRTriggerKindIds := { // deltas (Expansion rule applies) RSCRTriggerKindId.PenaltyPolicyEdit, RSCRTriggerKindId.DefaultGoverningDefinitionChange, RSCRTriggerKindId.BaselineBindingEdit } ⟩`

By the G.Core Expansion rule, the effective conformance ids / trigger kinds / pin obligations for G.4 are the expansions of the referenced profiles/sets/pin‑sets plus the explicit deltas above.

Notes (normative intent, delegated semantics):

• The semantics of tri‑state outcomes, penalty routing, set‑return discipline, crossing visibility, P2W split, typed RSCR causes, and the Default Governing Definition Index are governed in G.Core and are not redefined here.
• EvidenceGraph/Path pins (when used) are declared only via G.4:Ext.EvidenceGraphWiring in G.4:4.5 (so G.Core linkage stays minimal and does not “pull in” G.6 by default).
• Method‑specific pins (e.g., QD descriptor/distance/insert policy pins; open‑ended transfer rules pins) MUST appear only in Extensions blocks (see G.4:4.5) and MUST NOT introduce competing defaults.

#CAL Pack@CG-Frame surface (kit governed by this pattern)

CAL Pack@CG-Frame is the CG‑Frame’s published CAL Pack. Minimally, it provides:

• CAL.Charter — identification and assumption basis for this CAL pack:

  • cites the exact CGFrameId, EntityOfConcernRef, and ReferencePlane,
  • cites the governance and legality records (CNSpecRef, CGSpecRef) by edition,
  • records the assumption envelope on which the acceptance predicates rely without minting another governance or legality record.

• TaskMap — the conditional G.4 handoff record to G.5 when CAL gates are current; one exact edition names the task, cites the already constituted C.22 TaskSignatureRef and exact charter edition, and cites the acceptance-clause, operator, flow, and evidence-profile refs that selection actually consumes. It does not constitute the TaskSignature or contain threshold values.

• CAL.Operator[] — UTS‑published typed operation declarations governed by A.6.1; a card declares possible arguments, result kinds, and conditions but does not assert that an operation ran:

  • explicit signature over CHR types,
  • explicit preconditions/postconditions (incl. legality guard macros references),
  • explicit provenance/evidence hooks (by ids/pins, not by tool behavior).

• CAL.Acceptance[] — typed predicate declarations whose use is bounded by the declared ClaimScope, evaluation window, and any separate qualification window; a clause declares how an actual application is judged but is not itself a verdict:

  • binds to CHR characteristic ids and to exact A.6.1 argument declarations for admissible C.16 measurement-result epistemes (and, when inducing numeric comparison or aggregation, to CG‑Spec.characteristic ids),
  • keeps the exact current result episteme in the later application binding rather than in the reusable clause,
  • exposes unknown handling and failure behavior via policy pins.

Each resultInputDeclarationRef resolves an A.6.1 ArgumentDeclaration whose meaning names the C.16 measurement-result episteme expected by the clause, whose exact ValueKind and binding designation rule are explicit, and whose admissibility conditions require the named Characteristic and result shape. A deliberately one-off clause may also cite an already existing episteme in fixedResultEpistemeRefs[]?; mark that clause one-off instead of presenting it as reusable.

• CAL.Flow[] — legality‑checked declarations of possible operator composition; a declared DAG is not performed work:

  • declares result kind (scalar only when lawful; selected-set / set-result when partial orders remain partial orders),
  • records which acceptance clauses gate which flows.

• CAL.EvidenceProfiles — evidence wiring surface:

  • lane tags (F/G/R) / provenance anchors / policy pins needed for SCR and audit surfaces,
  • explicit freshness/decay hooks (freshness window + decay/Γ_time selectors) as pinned policies/refs (not prose).
  • explicit ReferencePlane + penalty routing policy ids (Φ(CL), Ψ(CL^k), Φ_plane) as citable pins; any such policy family is justified in CAL.ProofLedger (monotone + bounded).

• Optional CAL.NQD[] — QD/OEE‑related calculus surfaces when declared:

  • descriptor/distance/insertion artifacts are pinned by ids/editions,
  • semantics are governed by method‑specific governing definitions (e.g., C.18, C.19) and not redefined by CAL.

• CAL.ProofLedger — a proof/justification ledger:

  • links legality, monotonicity, boundedness, and other soundness obligations to operator/flow/clause ids.

• Publication artifacts:

  • UTS Name Cards (twin labels) for all public ids,
  • RSCR tests ids and Worked‑Examples ids,
  • deprecation notices and edition bump notes as public-id continuity records.

Boundary discipline (normative):

• No shadow specs: CAL artefacts cite CN‑Spec/CG‑Spec and do not introduce competing “local specs” (delegated; see CC‑GCORE‑CN‑CG‑1 via CC‑G4‑CoreRef).
• No shipping governance: CAL does not govern shipping; see CC-GCORE-SKP-1 via CC-G4-CoreRef.
• No refresh governing-definition assignment: CAL does not govern refresh orchestration; it only publishes pins/payload for refresh (governing definition: G.11).

Minimal schema fragments (notation‑independent; fields for citation, not an implementation schema):

CAL.Charter :=
  ⟨ charterId, charterEdition, cgFrameId, entityOfConcernRef, referencePlaneRef,
    CNSpecRef.edition, CGSpecRef.edition, assumptionEnvelope ⟩
CALCharterRef := <charterId, charterEdition>

TaskMap :=
  ⟨ taskMapId, taskMapEdition, charterRef := CALCharterRef,
    taskRef, taskSignatureRef := TaskSignatureRef,
    acceptanceClauseRefs[], operatorRefs[], flowRefs[], evidenceProfileRefs[] ⟩
TaskMapRef := <taskMapId, taskMapEdition>

CAL.Pack@CG-Frame :=
 ⟨ calPackId, charterRef, taskMapRef, operatorIds[], acceptanceClauseIds[], flowIds[],
 evidenceProfileIds[], proofLedgerId, nqdIds[]?,
    utsRowIds[], workedExampleIds[], rscrTestIds[], publicIdContinuityNoteIds[] ⟩

CAL.Operator :=
  ⟨ operatorId(UTS), signature(CHR-typed), preconditions[], postconditions[],
  evidenceProfileRefs[]?, failureBehaviorRef?, crossingRefs[]? ⟩

CAL.Acceptance :=
  ⟨ clauseId(UTS), characteristicRefs[], resultInputDeclarationRefs[],
    fixedResultEpistemeRefs[]?,              // deliberately one-off clause only
    cgSpecCharacteristicRefs[]?, predicateRef, claimScopeRef,
    evaluationWindow, qualificationWindow?, unknownHandlingRef,
    failureBehaviorRef, evidenceProfileRefs[]?, crossingRefs[]? ⟩

CAL.Flow :=
  ⟨ flowId(UTS), dag(operatorIds, edges), gateClauses(acceptanceClauseIds),
    resultKind, decisionAidPolicyRef? ⟩

CAL.EvidenceProfile :=
  ⟨ evidenceProfileId(UTS), lanes(F/G/R), anchors(A.10)[],
    freshnessPolicyPins[]?, penaltyPolicyPins[]?, ΓFoldRef.edition? ⟩

CALCharterRef and TaskMapRef each resolve one immutable edition. A changed charter, task, TaskSignature edition, clause, operator, flow, evidence profile, or edition-bearing cited list creates a new taskMapEdition; an old TaskMapRef continues to resolve its old values. The C.22 TaskSignature remains a separately constituted episteme. The map relates that exact signature to the CAL declarations used by selection but neither derives the signature nor duplicates their thresholds.

#Interfaces (minimal I/O surface)

#Declaration-to-runtime evaluation boundary (normative)

A CAL pack is a reusable design-time declaration. A stored operator card, clause, flow, TaskMap, proof-ledger row, test, or evidence-profile reference establishes neither an actual participant nor performed evaluation. When a CAL declaration is applied, recover the runtime chain explicitly:

1. Name one exact EvaluationMethod (U.Method). Its U.MethodDescription may state generic participants, parameters, effects, and evaluation conditions, but it carries no actual-participant slots and no intrinsic claim that a test, proof, or acceptance event occurred.
2. Cite the exact CAL.Operator, CAL.Flow, and CAL.Acceptance declarations as A.6.1 operation semantics. Resolve the clause's resultInputDeclarationRef, then bind the exact current C.16 measurement-result episteme in this application and test it against the declaration's Characteristic and admissible result shape. Use the exact A.6.1 declaration and application bindings; do not infer them from a compatible signature, TaskMap, or stored reference.
3. First recover every precise performer's A.13 core for the exact evaluation action, scope, working situation, and window, including the same obtaining assignment later used by any attribution. A.15.1 then independently admits one dated EvaluationWork : U.Work from its performance history, enacted Method, extent, and containing-System relation. Add F.6 afterward only when the receiving claim needs exact assignment-bound attribution through that same assignment. Recover the evaluated or affected referent, actual resources, and every concrete participant through its direct subject relation or an A.6.1 application binding. A compact attribution account may omit only an assignment identifier unused by its receiving claim; it omits no consumed fact. Ordinary activity not claimed as U.Work does not enter this branch.
4. State the local result under its direct predicate and pattern. A CAL.Acceptance application yields its exact pass | fail | unknown verdict; use A.19 for comparison and selection results, C.16 for measurement results, and C.11 for a decision result. No generic evaluation-result or work-result field substitutes for these objects.
5. When a durable assertion is needed, constitute one C.2.1 result episteme whose ClaimGraph states that local result, evaluated subject, interpretation basis, polarity or domain status, and uncertainty when current. The episteme is not the domain result and does not create it.
6. Attach source recovery and provenance through A.10/G.6 and currentness through G.11. For an ordinary bounded use below B.3's material-reliance threshold, state the exact A.10 evidence-provenance path and local RelianceDisposition; enter B.3 only for an assurance claim or material reliance. A citation, ledger edge, evidence profile, disposition, or assurance record does not establish the work, participant, application, or local result it describes.
7. A later selector, acceptance action, or decision is another governed occurrence. It relies on the result episteme through an exact premise, reference, decision-use, or operation-argument relation; mere storage, citation, or graph membership does not establish actual use.

This chain keeps declaration, execution, local result, result episteme, provenance, bounded reliance, currentness, acceptance, and decision independently recoverable.

#Extensions (pattern‑scoped; non‑core)

G.4 supports method‑family and discipline‑specific calculus variations exclusively via pattern‑scoped extensions.

GPatternExtension block: G.4:Ext.EvidenceGraphWiring

• PatternScopeId: G.4:Ext.EvidenceGraphWiring
• GPatternExtensionId: EvidenceGraphWiring
• GPatternExtensionKind: InteropSpecific
• GoverningPatternId: G.6
• Entry: use only when this CAL pack must cite a shared, addressable G.6 path or slice across more than one downstream consumer.
• Stop: omit the block when a local A.10 source-to-use account is sufficient; remove it when no current clause, proof, or example cites the path.
• Uses: {G.6}
• ⊑/⊑⁺: ∅
• RequiredPins/EditionPins/PolicyPins (minimum):
  • EvidenceGraphId?
  • PathId[]/PathSliceId[]
  • UTSRowId[] (for cited artifacts)
• RSCRTriggerSetIds: ∅
• RSCRTriggerKindIds: {RSCRTriggerKindId.EvidenceSurfaceEdit, RSCRTriggerKindId.EditionPinChange, RSCRTriggerKindId.PolicyPinChange}
• Notes (wiring‑only): This block does not define EvidenceGraph semantics; it only fixes that CAL proofs/examples may cite evidence by Path ids.

GPatternExtension block: G.4:Ext.NQD

• PatternScopeId: G.4:Ext.NQD
• GPatternExtensionId: NQD
• GPatternExtensionKind: MethodSpecific
• GoverningPatternId: C.18
• Entry: use only when the current task applies a C.18 quality-diversity/archive method and its descriptor, distance, insertion, or archive policy must be pinned for CAL use.
• Stop: omit or retire the block when the task has no current archive/QD clause or when those refs no longer change a CAL action.
• Uses: {C.18}
• ⊑/⊑⁺: ∅
• RequiredPins/EditionPins/PolicyPins (minimum):
  • DescriptorMapRef.edition
  • DistanceDefRef.edition
  • InsertionPolicyRef
  • ArchiveRef?
  • TaskSignatureRef? (if activation is TaskSignature‑bound)
• RSCRTriggerSetIds: ∅
• RSCRTriggerKindIds: {RSCRTriggerKindId.EditionPinChange, RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.TelemetryDelta, RSCRTriggerKindId.FreshnessOrDecayEvent}
• Notes (wiring‑only): CAL does not redefine QD semantics; it only pins the descriptor, distance, and insertion records needed for reproducible archive behavior. Any archive/illumination summaries (e.g., coverage / QD‑score / occupancyEntropy / filledCells) are published as report‑only outputs unless an explicit CAL acceptance clause/policy authorizes promotion.

GPatternExtension block: G.4:Ext.EELog

• PatternScopeId: G.4:Ext.EELog
• GPatternExtensionId: EELog
• GPatternExtensionKind: MethodSpecific
• GoverningPatternId: C.19
• Entry: use only when the current task has a C.19-governed exploration/exploitation budget or probe-accounting rule that changes a CAL clause or failure branch.
• Stop: omit or retire the block when no current CAL action consumes those C.19 refs.
• Uses: {C.19}
• ⊑/⊑⁺: ∅
• RequiredPins/EditionPins/PolicyPins (minimum):
  • ExploreExploitBudgetPolicyRef
  • ProbeAccountingRef?
  • FailureBehaviorRef? (if probe/sandbox is policy‑bound)
• RSCRTriggerSetIds: ∅
• RSCRTriggerKindIds: {RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.TelemetryDelta, RSCRTriggerKindId.FreshnessOrDecayEvent}

GPatternExtension block: G.4:Ext.SoSLogBranches

• PatternScopeId: G.4:Ext.SoSLogBranches
• GPatternExtensionId: SoSLogBranches
• GPatternExtensionKind: MethodSpecific
• GoverningPatternId: C.23
• Entry: use only when C.23-governed SoS-LOG branches currently explain a CAL degrade/abstain path.
• Stop: omit or retire the block when those branch/rule ids no longer change a current CAL clause, flow, or explanation.
• Uses: {C.23}
• ⊑/⊑⁺: ∅
• RequiredPins/EditionPins/PolicyPins (minimum):
  • SoSLogRuleId[]
  • SoSLogBranchId[]
  • FailureBehaviorPolicyId
• RSCRTriggerSetIds: ∅
• RSCRTriggerKindIds: {RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.MaturityRungChange, RSCRTriggerKindId.TelemetryDelta}
• Notes (wiring‑only): This block only pins branch/rule ids for degrade/abstain explanation; it does not redefine rule semantics.

#Archetypal Grounding

Tell. A CG‑Frame must choose and justify a set of candidate methods (possibly a selected set or archive) under explicit legality, evidence, and scope constraints. CHR provides the typed measurement basis; CAL declares auditable predicates and flows that separately grounded runtime work may apply.

Show 1 (bounded CAL pack skeleton). Use: R&D selected-set choice. The pack names the exact CG frame and EntityOfConcern, candidate-set ClaimScope, ReferencePlane, and evaluation window. CHR defines SafetyClass(ord↑), CostUSD_2026(ratio↓), Readiness(nominal).

• CAL.Operator: DominatesPareto Signature over CHR types, precondition references CHR guard macros.
• CAL.AcceptanceClause: AC_SafetyGate Reusable typed predicate for SafetyClass (and its levels), citing SafetyResultArgument-D1, the A.6.1 argument declaration that admits a C.16 measurement-result episteme for that Characteristic. Thresholds are valid for the stated ClaimScope and evaluation window; unknown handling uses tri-state pins. The clause names no current measurement-result episteme.
• CAL.Flow: Flow_ParetoPortfolio Produces a selected-set result kind; gates by AC_SafetyGate and AC_Budget.
• CAL.EvidenceProfile: EP_SafetyEvidence Declares anchor ids and freshness policy pins required for SCR.

When this CAL pack supplies selector gates, it publishes TaskMapRef=<SafetySelectionMap, E3>. That map cites CALCharterRef=<SafetyCALCharter, E2>, C.22 TaskSignatureRef=SafetyPortfolioTaskSignature-E4, the exact task, and edition-bearing refs AC_SafetyGate-E2, Flow_ParetoPortfolio-E1, DominatesPareto-E3, and EP_SafetyEvidence-E4; it contains no threshold values. Downstream G.5 consumes the exact TaskSignatureRef and this TaskMapRef together, verifies that the map cites the same signature, and resolves the charter and declarations through their refs. If the charter or a cited clause changes, G.4 publishes another TaskMap edition; selectors that still cite <SafetySelectionMap, E3> continue to replay the old boundary.

Show 2 (explicit cross-sense or ReferencePlane import). A SafetyClass result uses an expression with a different F.17 source-local meaning or comes from another ReferencePlane. CAL may author a clause using it only after the exact F.17 cells and obtaining F.9 relation are cited when meanings differ, and the applicable plane or edition crossing records are cited when those values differ. The clause keeps its declared ClaimScope and window; the import does not silently widen either.

Show 3 (one performed acceptance evaluation).

Before the candidate action is admitted as Work, A.13 recovers SafetyEvaluatorSystem-17 : U.System for exact action SafetyAcceptanceEvaluationAction-17. Its admitted SafetyEvaluatorBoundary-17 contains the evaluation controller, its active decision state, and the input/output channels through which it applies the clause; it excludes the CAL declarations, measurement-result episteme, candidate, assignment, and containing team System. The action's scope is SafetyAcceptanceClaimScope-17, its working situation is SafetyGateEvaluationSituation-17, and its window is 2026-07-30T09:00:00Z through 2026-07-30T09:20:00Z. It is directed by SafetyAcceptanceDecisionNorm-17: apply the current clause to admissible current inputs, return unknown rather than force a threshold verdict when uncertainty crosses the boundary, and reject an input whose declared result shape is incompatible. The relevant conditions are clause edition, result-shape admissibility, measurement currentness, and uncertainty relative to the threshold.

The local kind SafetyAcceptanceEvaluatorSystemRole is declared under A.2. Its membership criterion requires the stable work-facing contribution of safety-acceptance evaluation and goal-directed, condition-sensitive regulation under SafetyAcceptanceDecisionNorm-17: the holder must bind admissible inputs, choose the clause-defined verdict, and abstain or return unknown when the declared conditions require it. SafetyEvaluatorDecisionTrace-17 shows SafetyEvaluatorSystem-17 rejecting an incompatible result shape and returning unknown when the admissible uncertainty interval crosses the threshold; the system-boundary and runtime records show that those actions occurred within SafetyEvaluatorBoundary-17. A.10 evidence-use claims support the criterion facts, and the case independently classifies SafetyEvaluatorSystem-17 under SafetyAcceptanceEvaluatorSystemRole. Neither the candidate Work nor the assignment supplies that classification. No Grade, autonomy result, characteristic profile, or stronger assurance claim is consumed here.

The same A.13 core uses SafetyAcceptanceEvaluationAssignment, a directly declared U.SystemRoleAssignment species under A.2.1. The species defines holder, assigned-kind, and evaluation-candidate participant meanings; its predicate appoints the holder to evaluate that candidate under the applicable clause for the stated scope, situation, and window. SafetyAcceptanceEvaluationAssignment-17 obtains with SafetyEvaluatorSystem-17 as holder, SafetyAcceptanceEvaluatorSystemRole as assigned-kind value, and C-17 as evaluation candidate. Its maximal uninterrupted predicate-true interval covers the full stated window.

Only after that A.13 core is established does A.15.1 independently admit EvalWork-2026-07-30-17 : U.Work from its exact performance history, enacted SafetyAcceptanceMethod, temporal extent, and obtaining containing-System relation to independently admitted SafetyEvaluationTeamSystem-17. The actual A.6.1 application SafetyAcceptanceApplication-17 separately binds candidate C-17 and current C.16 measurement-result episteme SafetyMeasureResult-E17 to SafetyResultArgument-D1 while using unchanged reusable clause AC_SafetyGate. Neither the assignment nor an F.6 conclusion is an A.15.1 admission premise.

Because this worked case explicitly says that the Work was performed under an assignment, F.6 afterward establishes performedUnderAssignment(EvalWork-2026-07-30-17, SafetyAcceptanceEvaluationAssignment-17) through the same obtaining A.13 assignment. The direct case fact links that exact pair, holder equality holds, and the assignment interval covers the Work. A different overlapping assignment held by the same performer would not establish this attribution.

SafetyMeasureResult-E17 states the measured safety characteristic, scale, attributed value, uncertainty, model, calibration, and measurement Work; it is neither the raw detector output nor the acceptance verdict. The clause application obtains unknown because the uncertainty interval crosses the threshold. A later SafetyMeasureResult-E18 can bind through separately identified SafetyAcceptanceApplication-18 while AC_SafetyGate remains unchanged. A C.16 result for CostUSD_2026, a result with an incompatible declared shape, or raw detector output fails SafetyResultArgument-D1 before the predicate runs; it does not cause a new reusable clause edition. A separate C.2.1 episteme asserts that exact verdict and cites its provenance under A.10 and, when the EvidenceGraph extension is present, G.6; G.11 supplies currentness. A later C.11 result may record defer, and its claim uses the verdict episteme through an exact premise or decision-use relation. Any decision-making Work remains separate. The clause card, proof-ledger row, evidence edge, and decision record do not retroactively establish the measurement Work or the evaluation occurrence.

#Bias-Annotation

CAL is where “what counts as acceptable” is encoded. Typical bias vectors include:

• threshold‑selection bias (arbitrary floors masquerading as natural laws),
• measurement bias amplified by illegitimate arithmetic or hidden scalarization,
• survivorship bias in Worked‑Examples and probe telemetry,
• Goodhart pressures when report‑only telemetry is accidentally treated as dominance.

The pattern mitigates these by requiring typed acceptance clauses, explicit policy pins, and an auditable ledger of proofs and justifications, while keeping cross-sense and ReferencePlane reuse explicit and placing penalties only in the explicit assurance lane.

#Conformance Checklist (normative)

#Common Anti-Patterns and How to Avoid Them

• Hidden thresholds. Avoid: embedding cutoffs in CHR prose or in operator descriptions. Prefer: CAL.AcceptanceClause with explicit ids and pins.

• Untyped “score(x)”. Avoid: operators with implicit units and untracked legality assumptions. Prefer: explicit CHR‑typed operator signatures + cited legality checks.

• Silent cross-sense or cross-plane reuse. Avoid: importing expressions with distinct source-local meanings, or values across ReferencePlanes or editions, without the obtaining relation and required crossing records. Prefer: cite the exact F.17 cells and F.9 relation when meanings differ, cite the applicable plane or edition crossing records, and keep each clause bounded by its stated ClaimScope and window.

• Acceptance as implementation detail. Avoid: acceptance embedded in tool logic. Prefer: publish acceptance as citable CAL artifacts; downstream consumes ids.

• Exploratory telemetry treated as dominance. Avoid: letting probe/illumination telemetry quietly become a dispatch criterion. Prefer: keep it report‑only unless an explicit policy‑bound acceptance clause authorizes promotion.

• Declaration mistaken for execution. Avoid: treating a CAL card, TaskMap, proof-ledger row, worked example, or evidence edge as proof that an operator ran or a verdict obtained. Prefer: recover every precise performer's A.13 core, let A.15.1 independently admit the dated Work, and add F.6 only when exact assignment-bound attribution through the same obtaining assignment is current; recover actual direct bindings separately. Compact wording may omit only an unused assignment identifier and no consumed fact. Keep the domain-local result and any result episteme separate from both.

#Consequences

• CAL becomes a stable, citable CAL Pack: operator/acceptance semantics are explicit artifacts, not tacit code behavior.
• Legality failures are surfaced as authoring defects (RSCR‑testable) rather than run‑time surprises.
• Downstream patterns (G.5, G.8, G.9, G.10, G.11) can reference stable ids/pins without redefining acceptance or operator semantics.
• Method pluralism is supported: multiple calculi can coexist as separate operator/flow/acceptance families, wired via Extensions rather than mixed into the core kit.

#Rationale

CAL sits at the boundary where typed measurement becomes actionable choice. Making CAL a published, typed, and testable artifact reduces semantic drift and prevents “shadow legality gates” from emerging in tools or in downstream prose.

The design separates concerns:

• CHR governs measurement typing and legality guard macros,
• CG‑Spec and CN‑Spec govern the legality gate and governance card, respectively,
• G.Core governs Part‑G invariants and trigger/default discipline,
• G.4 governs the CAL kit: authoring objects, publication surface, and handoff manifest.

This yields modularity (one governing definition per invariant or default), auditability (pins/ids and proof refs), and extensibility (method families attach through explicit extension modules).

#SoTA-Echoing

Source qualification was checked on 2026-07-30. The source identities below are immutable publications; the G.4 adoption decisions remain qualified through 2027-07-30 unless a governing neighbour adopts a successor earlier or a new result contradicts the named assumption boundary.

Distributionally robust and broad multi-objective families are discovery leads, not G.4 decision sources. Current comparison, partial-order, and selected-set law stays with A.18/A.19; a future external source enters this table only after it changes a present C1–C9 action, worked case, or conformance row. Source refresh is local to the row's named rule, example, and check.

#Maintainer-facing architecture and publication inventory

G.4 is a design-time authoring pattern. It publishes a notation-independent CAL Pack@CG-Frame with a charter for the exact CG frame, EntityOfConcern, ReferencePlane, specification editions, and assumption envelope; stable operator, clause, and flow ids; evidence and currentness refs; proof-or-gap records; worked examples and tests; continuity notes; and a minimal TaskMap. It uses G.Core, G.0, and G.1–G.3 for Part-G, CG-frame, SoTA, CHR, and legality disciplines; A.6.1 for declarations and actual bindings; A.13 and A.15.1 for precise performers and independently admitted runtime Work; F.6 only for a current assignment-bound attribution through the same obtaining assignment; C.2.1 for result epistemes; and A.10, G.11, B.3, and C.11 for provenance, currentness, assurance, and decisions. G.6 is used only when G.4:Ext.EvidenceGraphWiring is present. Method-specific semantics remain in the applicable extension pattern. The detailed manifests, schemas, and interfaces above are maintainer-facing citation surfaces for this one practitioner path, not a second workflow.

#Relations

Builds on: G.Core (and the pattern template discipline in E.8).

Uses: G.1 (CG‑Frame Card), G.2 (SoTA Synthesis Pack), G.3 (CHR Pack), G.0 (CG‑Spec legality gate), A.19 (CN‑Spec plus direct comparison and selection patterns), A.18 (CSLC), A.2.6 (U.ClaimScope), A.6.1 (declarations and actual bindings), A.13 (precise performer core), A.15.1 (independent Work admission), A.2.1 (assignment species and occurrences), and F.6 only for exact assignment-bound attribution through the same obtaining assignment, C.2.1 (result epistemes), C.11 (decision results), A.10 (provenance and bounded reliance), B.3 (assurance), G.11 (currentness), and E.18, A.21, F.9, F.17, and E.17 (GateCrossing harness).

Uses (via Extensions): G.6 (EvidenceGraph/Path citation; when G.4:Ext.EvidenceGraphWiring is present), C.18 (NQD), C.19 (E/E‑LOG), C.23 (SoS‑LOG).

Used by: G.5 (selector/dispatcher), G.8 (SoS‑LOG bundles), G.9 (parity), G.10 (shipping), G.11 (refresh orchestration). Publishes to: UTS (public ids and public-id continuity records), RSCR (tests and trigger emissions), G.5 (handoff manifest), and, as cited payload, shipped packs governed by G.10.

Constrains: any run‑time LOG implementation that executes CAL operators/flows must treat CAL artifacts as citable specifications and must not re‑invent acceptance semantics.

#G.4:End

#Multi‑Method Dispatcher and MethodFamily Registry

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.

#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 and SelectionSlot bindings 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 relation, 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.

• several method families or generator families can admissibly act on 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 C.11 has already emitted one local choice result, C.19 one pool-policy result, or 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 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 typed slot, scale, and coordinate definitions from G.3 and G.4 yield admissible calculi and acceptance clauses - 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.

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

• 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 relation 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 eligibility and assurance gating (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.

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 that carries the selected set 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). A standard result-content boundary emits:

• 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 relation independently obtains.

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

• An admissible G.5 result therefore declares a set-return shortlist or a narrowed handoff plan, 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 participates in 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 this family only over the exact Method candidates admitted through its kernel; G.5-6 DeclareSetResult emits it 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), [A.19.CPM](/generated/patterns/A.19.CPM), [C.19](/generated/patterns/C.19), [C.36](/generated/patterns/C.36), [F.17](/generated/patterns/F.17), [F.18](/generated/patterns/F.18), and [F.9](/generated/patterns/F.9) for those distinct questions.

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

• 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

• SelectionSlot returns one selector outcome, not one forced 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 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.