#Part G – Discipline SoTA Patterns Kit

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

#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 legality (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 legality 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),
• context‑sensitive (results depend on U.BoundedContext and declared entityOfConcern),
• method‑heterogeneous (different evidence styles, operator sets, and validity regions),
• time‑sensitive (rapid drift post‑2015; frequent benchmark/protocol shifts).

Downstream Part‑G work (CHR/CAL/selection/shipping/refresh) depends on the team producing consumable, citation‑ready artefacts without collapsing semantic boundaries across contexts or planes.

#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 cards that G.3/G.4/G.5 can consume),
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) CG-FrameContext, 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 with Context and triage status (e.g., include / park / retire) and explicit rationale hooks.

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

• explicit U.BoundedContext and entityOfConcern,
• 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 citing A.10 carriers, declaring context + entityOfConcern, and annotating assurance type(s) (TA/VA/LA, where applicable).

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. Declare CG-FrameContext, the initial Tradition set, and the entityOfConcern surface for each intended claim region. Record these declarations in the pack pins (not as implicit assumptions).

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 A.10 carriers and declaring context + entityOfConcern.

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)
• DHCSenseCellId[] (pack‑local ids for emitted DHC SenseCells; if any are public, cite via UTSRowId[])
• UTSRowId[]? (only if any DHC SenseCells / series ids are minted/evolved as public ids)
• 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/constraints (governing pattern: C.21) must be pinned, not redefined here (e.g., bridges_per_100_DHC_SenseCells, CL_min = 2 for cross‑Context counting, and the “CL=3 implies free substitution” interpretation when used).

#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 (CG‑FrameContext), G.2 (SoTA synthesis inputs), A.19.CHR (CHRMechanismSuite boundary + pins), A.15.3 (SlotFillingsPlanItem baseline), A.18/C.16 (MM‑CHR legality), F.1–F.9 (Contexts/UTS/Bridges), 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.
• Cross‑context reuse must be explicit (bridges + loss accounting + pinned policy ids), and refresh must be tractable by typed RSCR causes rather than prose.

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 across contexts (same token, different referent/sense).
• 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 (no explicit bridge and loss notes; unclear entityOfConcern changes).
• 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: CG-FrameContext, entityOfConcern, CNSpecRef.edition, CGSpecRef.edition are already required // by GCorePinSetId.PartG.AuthoringMinimal (cite, don’t restate here). 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). Declare the CHR U.BoundedContext and scope for the CG‑Frame, including: entityOfConcern boundaries, ReferencePlane, freshness/decay expectations, and the list of contested terms likely to require bridging. Output a design‑time MeasurementCharter and KindMap@Context. 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, Context, 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, 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/cross‑context bias: imported terms erase local meaning. Mitigation: require explicit imports and loss notes; downstream penalties route to R_eff only (pinned through G.Core), making loss visible rather than silently altering F/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 CHR terms across contexts without explicit import and loss notes; do keep crossings explicit and auditable (pinned through G.Core).

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

#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.1–F.9 (Contexts/UTS/Bridges), 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

Tag. Architectural pattern (publishes CAL Pack@CG-Frame; consumes CHR Pack@CG-Frame; constrains selector/dispatcher usage; binds GateCrossing discipline; exposes ReferencePlane and penalty/guard policy pins to SCR)

Stage. design‑time (authoring & publication; enables lawful run‑time evaluation)

Primary output. A notation‑independent CAL Pack@CG-Frame containing: CAL.Charter@Context, CAL.Operator[], CAL.Acceptance[], CAL.Flow[], CAL.EvidenceProfiles, CAL.ProofLedger, optional CAL.NQD[] (when declared), UTS entries (Name Cards with twin labels and public-id continuity notes, including deprecations and lexical-continuity notes), RSCR tests, Worked‑Examples, and a TaskMap@Context (TaskMap; handoff record consumed by G.5).

Primary hooks. G.Core (Part‑G invariants + RSCR trigger catalogue + Default Governing Definition Index), G.1 (CG‑FrameContext), G.2 (SoTA Synthesis Pack), G.3 (CHR Pack), G.0 (CG‑Spec legality gate), A.19 (CN‑Spec), A.18 (CSLC), A.10 (provenance anchors), B.3 (trust / freshness / decay), E.18 + A.21 + F.9/F.17/E.17 (GateCrossing / CrossingBundle harnesses), G.6 (EvidenceGraph / PathId / PathSliceId; wired via Extensions), G.5 (Selector & Dispatch), G.10 (shipping), G.11 (refresh orchestration), plus Contexts/UTS/LEX disciplines already fixed elsewhere in the spec.

Non‑duplication note. Universal Part‑G invariants (no shadow specs, crossing visibility, tri‑state guard, penalties→R_eff‑only, set‑return semantics, P2W split, typed RSCR causes, Default Governing Definition Index, shipping boundary) are governed in G.Core and are pulled into G.4 only through the G.Core linkage manifest in G.4:4.1 (and via explicit delegations in CC).

#Problem frame

A CG‑Frame has:

• a declared CG-FrameContext (scope, EntityOfConcern, plane),
• 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 (with Context‑local thresholds), 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‑context imports are silent (hidden reuse of constructs across contexts or planes/editions without published GateCrossings 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. CAL must be Context‑local by default but prepared for explicit reuse via Bridges and published crossing bundles.

#Solution — CAL authoring kit and publication surface

#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@Context — scope anchor for this CAL pack:

  • cites CG-FrameContext, entityOfConcern, ReferencePlane,
  • cites the governance card and legality gate (CNSpecRef, CGSpecRef) by edition pins,
  • records the “assumption envelope” that acceptance predicates rely on (without minting a new governance card or legality gate).
  • emits TaskMap@Context (TaskMap) as the canonical handoff record to G.5 (task→gates/flows/evidence pins).

• CAL.Operator[] — typed operator cards (UTS‑published):

  • 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 predicates with Context‑local thresholds:

  • binds to CHR characteristic ids (and, when inducing numeric comparison/aggregation, to CG‑Spec.characteristic ids),
  • exposes unknown handling and failure behavior via policy pins.

• CAL.Flow[] — legality‑checked compositions of operator cards:

  • 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.Pack@CG-Frame :=
 ⟨ calPackId, charterId, taskMapId, 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[], cgSpecCharacteristicRefs[]?,
    predicateRef, 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? ⟩

#CAL authoring chassis C1–C9 (kit governed by this pattern)

C1 — CAL Charter (scope anchor). Authors declare a CAL.Charter@Context that:

• anchors CAL to the CG‑Frame scope (CG-FrameContext, entityOfConcern, ReferencePlane),
• pins the relevant governance card and legality gate refs (CNSpecRef.edition, CGSpecRef.edition),
• records the local assumption envelope used by acceptance predicates (as explicit statements to be audited, not as hidden algorithmic assumptions),
• declares which CAL artifacts are intended to be cited downstream (UTS ids).
• emits a TaskMap@Context (TaskMap) that binds each declared TaskSignature (or task family) to:
  • eligible CAL.FlowId[] / CAL.OperatorId[],
  • gating AcceptanceClauseId[] (ids of CAL.Acceptance clauses),
  • required CAL.EvidenceProfileId[],
  • and any required policy pins/edition pins for reproducibility. This is the canonical “handoff manifest” consumed by G.5 (thresholds remain only inside CAL.Acceptance).

C2 — Operator Cards (typed & lawful). Each CAL.Operator is a UTS‑published, typed unit with:

• OperatorId (UTS),
• Signature over CHR types,
• Preconditions (including references to CHR guard macros where applicable),
• Postconditions / invariants,
• EvidenceProfileRef[] (or an explicit “none”),
• FailureBehaviorRef (policy‑bound) for safe degradations and non‑catastrophic fallbacks.

C3 — Acceptance Clauses (typed predicates; thresholds live here). Each CAL.Acceptance is a UTS‑published predicate with:

• stable ClauseId (UTS) for citation,
• explicit CharacteristicRefs (CHR ids) used by the predicate,
• CGSpecRefs? required iff the clause induces numeric comparison/aggregation,
• EvidenceProfileRefs? identifying evidence consulted (so SCR can surface the relevant pins),
• explicit freshness envelope (freshness window + decay/Γ_time selector refs/pins) when evidence recency is part of admissibility,
• UnknownHandling as a tri‑state choice (via G.Core semantics),
• FailureBehaviorRef (policy‑bound) for degrade/abstain behavior.
• GateCrossingId[] / CrossingBundleId[] iff the clause relies on cross-context, cross-plane, or cross-edition imports (no “silent reuse”). Missing required crossing artefacts is a conformance failure and blocks publication of the affected clause/flow (GateCrossing harness: E.18/A.21/F.9/F.17/E.17; crossing invariants: G.Core).

C4 — Aggregation & comparison flows (safe by construction). CAL.Flow composes operators into legality‑checked DAGs and declares:

• which acceptance clauses gate the flow,
• which operator outputs are decision‑relevant vs report‑only,
• what the result kind is (scalar only where lawful; otherwise selected-set / set-result).
• any thinning/decision‑aid policy (e.g., ε‑front selection) as an explicit policy pin that does not silently replace the declared result kind.

C5 — Evidence wiring surface. CAL.EvidenceProfile makes evidence hooks explicit:

• provenance anchor references (A.10‑style carriers/anchors, cited by id),
• lane tags (F/G/R) for each evidence contribution (no implicit lane mixing; penalties route only to R_eff as governed by G.Core),
• pinned policy ids for penalty routing and freshness/decay handling (incl. freshness window + decay/Γ_time selector pins; and Φ(CL)/Ψ(CL^k)/Φ_plane policy ids when used),
• declared inputs needed for SCR fields at run‑time (without embedding run‑time “gate decisions” into design‑time artifacts).

C6 — NQD/OEE surface (optional; method‑specific semantics delegated). If the CG‑Frame declares QD/OEE‑style regimes, CAL may publish CAL.NQD[] as a surface that:

• declares descriptor space and distance/insertion artifacts by ids and edition pins,
• records archive/illumination intent and “report‑only vs dominance” gating as explicit policy pins,
• does not redefine QD/OEE semantics (those remain governed by method‑specific patterns such as C.18 / C.19 and are wired via Extensions).

C7 — ProofLedger (soundness & legality obligations). CAL.ProofLedger links each operator/flow/clause to:

• legality proof refs (incl. CSLC refs when numeric comparison/aggregation is induced),
• monotonicity/boundedness/stability proof refs for penalty/aggregation policies where relevant,
  • in particular: if an explicit ΓFoldRef is pinned (override), ProofLedger includes monotonicity + boundedness/boundary behavior proof refs for that fold.
• explicit statements of degradation conditions (what must happen when assumptions fail).

C8 — Publication + RSCR + Bridges. CAL publication emits:

• UTS entries (Name Cards + twin labels) for all CAL ids,

• Worked‑Examples that exercise legality and acceptance claims,

• RSCR tests ensuring:

  • illegality is detected (e.g., forbidden ordinal arithmetic),
  • guard macro use is coherent,
  • flow legality checks are exercised,
  • acceptance clauses behave as authored on examples.

Any cross-context, cross-plane, or cross-edition import required by CAL publication is handled through GateCrossing/CrossingBundle discipline (as governed by G.Core), and CAL publication is blocked if required crossing artifacts are missing.

C9 — Packaging & refresh readiness (without governing orchestration). CAL pack versions:

• record changes as edition‑pinned updates,
• publish deprecation notices and public-id continuity notes for public ids,
• emit RSCR‑relevant trigger payload pins (editions/policies/UTS ids/paths) for refresh orchestration (governing definition: G.11).

#Interfaces (minimal I/O surface)

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

GPatternExtension block: G.4:Ext.AcceptanceRiskControl (Phase‑3 seed)

• PatternScopeId: G.4:Ext.AcceptanceRiskControl
• GPatternExtensionId: AcceptanceRiskControl
• GPatternExtensionKind: Phase3Seed
• GoverningPatternId: governing pattern not yet selected
• Uses: ∅
• ⊑/⊑⁺: ∅
• RequiredPins/EditionPins/PolicyPins (minimum):
  • RiskControlPolicyRef
  • CalibrationWindowRef?
  • CoverageTargetRef?
• RSCRTriggerSetIds: ∅
• RSCRTriggerKindIds: {RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.TelemetryDelta, RSCRTriggerKindId.FreshnessOrDecayEvent}
• Notes (non‑normative seed): Intended for post‑2015 acceptance families such as conformal risk control / set‑valued selective prediction, distributionally‑robust acceptance envelopes, and calibrated abstention policies; semantics must be governed elsewhere before becoming normative.

#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 turns it into executable, auditable predicates and flows.

Show 1 (in‑context CAL pack skeleton). Context: R&D selected-set choice. 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 Typed predicate binding SafetyClass (and its levels) with Context‑local thresholds; unknown handling uses tri‑state pins.
• 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.

Downstream, G.5 consumes only the handoff manifest: clause ids, operator ids, and evidence profile ids (no embedded thresholds).

Show 2 (explicit cross‑context import). A SafetyClass value is imported from a different Context or plane. CAL may still author an acceptance clause using that value, but only after the reuse is made explicit as a published crossing bundle and the CAL artifacts cite the relevant ids/pins. The CAL pack remains Context‑local; portability is achieved through explicit crossings and citations, not by silently widening scope.

#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 proof/justification ledger, while keeping cross‑context reuse explicit and penalized 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‑context reuse. Avoid: importing constructs across Contexts/planes/editions without published crossings. Prefer: explicit crossing artifacts and citations; keep CAL pack Context‑local.

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

#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

CAL authoring is compatible with post‑2015 best practice families without confusing “popular” with “best‑available”:

• Risk‑controlled acceptance: modern conformal / selective / set‑valued prediction families where “abstain” is a first‑class, audited outcome (fits tri‑state gating + explicit calibration pins).
• Robust acceptance envelopes: distribution‑shift‑aware and distributionally‑robust acceptance styles, expressed as policy‑pinned predicates rather than hidden heuristics.
• Modern multi‑objective practice: preference‑aware, interactive, and set‑returning multi‑objective decision families that preserve partial orders and selected sets.
• Quality‑Diversity after 2015: archive‑based search families (e.g., CMA‑ME‑class) attach as wiring via edition‑pinned descriptor/distance/insertion artifacts.
• Open‑ended exploration after 2015: environment‑method co‑evolution families (e.g., POET‑class) attach through explicit generator family wiring and policy‑bound acceptance branches.

All of these remain method‑specific semantics and therefore belong in Extensions blocks (or their governing patterns), while G.4 keeps the calculus kit stable and auditable.

#Relations

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

Uses: G.1 (CG‑FrameContext), G.2 (SoTA Synthesis Pack), G.3 (CHR Pack), G.0 (CG‑Spec legality gate), A.19 (CN‑Spec), A.18 (CSLC), A.10 (provenance anchors), B.3 (trust/freshness/decay), E.18 + A.21 + F.9/F.17/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 & MethodFamily Registry

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

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

Intent. Govern the dispatcher/registry object set for rival method families and publish selector-facing retained-set outcomes without collapsing plurality into one hidden scalar winner.

#Use this when

• 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, one SpecialistHandoff, one other narrowed handoff plan, or one abstain outcome without pretending that there is always one scalar winner
• the published result must carry enough basis pins for 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
• selected-set publication gets hidden inside C.11, C.19, or C.24, so the published result no longer makes clear whether it carries local choice, pool policy, enactment, or publication
• exploration, open-ended, or specialization pressure leaks in as one architecture convenience rather than one explicit policy-bound choice

#What this buys

• one registry that keeps rival method families disjoint but dispatchable
• one selector result form that can publish candidate sets, Shortlist, RankedShortlist, one SpecialistHandoff, narrowed handoff plans, or abstain outcomes honestly
• one DRR/SCR-addressable trace with explicit basis pins instead of one hidden selector rationale
• one explicit publication closure so the declared outcome kind, any applicable public selected-set label, retained members or handoff content, ordering status, and basis pins are stated directly in the emitted result

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

#First-minute questions

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

#First output

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

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

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

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

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

#Problem frame

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

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

You need a notation‑independent way to:

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

#Problem

How to design a general, auditable dispatcher that:

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

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

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

• cleanly separates:

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

#Forces

• Pluralism vs. forced totalisation. Many selection regimes are inherently partial‑order; forcing a scalar winner often creates illegal semantics.
• Evidence realism vs. hard gates. Eligibility/acceptance frequently depends on incomplete evidence; selection must remain auditable under tri‑state unknowns.
• Reuse vs. leakage. Cross‑Context reuse is valuable but must be explicit (Bridge + loss notes) and must not silently re‑ground semantics.
• Exploration vs. exploitation. Dispatch sometimes must probe alternatives under explicit policy/risk envelopes, but probing must not become an implicit fourth status.
• Evolvability vs. churn. Registries evolve (new families, deprecations, edition bumps); continuity must not be broken by “rename by meaning”.

#Solution

#Causal method dispatch declarations

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

Optional MethodFamily.causalUseDispatchSpec?:

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

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

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

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

#G.Core linkage (normative)

Builds on: G.Core (Part‑G core invariants; Default Governing Definition Index 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.1). Profiles/sets + explicit deltas; Nil‑elision applies.

• CoreConformanceProfileIds :=

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

• CorePinSetIds :=

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

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

  • TaskSignatureRef (see G.5:4.2 / S2)
  • MethodFamilyId[] (registry keys in scope)
  • GeneratorFamilyId[]? (when generator families are in scope)
  • PathId[] (audit citations for “why” and for evidence)
  • PathSliceId[] (audit citations for “why” and for evidence)
  • UTSRowId[] (published identities for selected/registered families and selector policy records)
  • FailureBehaviorPolicyId? (only when degrade/abstain behavior is explicitly policy‑bound)
  • SoSLogBranchId? (only when degrade/abstain behavior is explicitly policy‑bound)

• DefaultsConsumed :=

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

• RSCRTriggerSetIds :=

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

#Dispatcher & Registry object set (notation‑independent)

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

S1 — MethodFamily Registry (design‑time; per CG‑Frame). A registry row represents a family, not a single implementation. Minimal fields (conceptual, notationally independent):

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

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

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

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

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

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

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

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

Admission rule for SpecialistHandoff: use that handoff kind only when the truthful published result is one heterogeneous handoff bundle whose members occupy different specialization roles that still need to travel together. Do not use it when one ordinary Shortlist, RankedShortlist, ExplorationArchive, or another narrower named result kind already states the result more precisely.

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

S4 — Composition & fallbacks templates (design‑time). A library of composition shapes (preconditioner → solver → verifier; cascades; meta‑selectors) as templates, legality‑checked and pinned. Concrete strategy semantics stay in the referenced method families; G.5 only carries the composition template.

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

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

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

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

#Selector head and narrower selector families

Selection/dispatch stays one generic selector head. Narrower selector families may refine it, but they do not redefine the universal invariants 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/exploit lenses, or preference comparators do not become part of the selector head. They arrive only through explicit extension declarations and the pins those extensions require.

#Interfaces (minimal I/O record)

#Worked selector slice

• A catalyst-search team is choosing among three method families for the same declared TaskSignature and C.22.1 adaptation signature.
• The shared profile pins one work-measure threshold target, one freshness window, one prior-exposure declaration, and one adaptation budget. One family reaches threshold quickly but carries high downside on adjacent tasks. One family is slower but transfers cleanly. One family never clears MinimalEvidence and must abstain.
• An admissible G.5 result therefore publishes a set-return shortlist or a narrowed handoff plan, with DRR/SCR citing why the third family was excluded and why the first two remain non-dominated. The selector does not invent one scalar winner and does not hide the specialization profile in auxiliary side notes.
• When one upstream C.19 pass has already narrowed the live pool to one internal retained subset over registered families, G.5 may publish that result as one Shortlist with one ShortlistId and explicit basis pins only when selector-facing publication is now the question. Until that emission occurs, the internal retained subset is not yet one public shortlist result.
• When one upstream C.11 pass has already fixed one local choice over one declared source set, or one C.24 pass has already produced one enactment-facing narrowed handoff, G.5 may publish the selected-set or narrowed-handoff result only when selector-facing publication is now the question. Until this G.5 emission occurs, the ChoiceResult, CallPlan, or CheckpointReturn is not itself one public Shortlist, RankedShortlist, or ShortlistId-bearing result.

#Published selected-set result and closure rule

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

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

The admissible selector outcome families here are:

• SelectorOutcomeKind = SetResultOutcome, with SetResultFamily = Shortlist when one retained set is published without one material internal order and SetResultFamily = RankedShortlist when ordering materially belongs to the result;
• SelectorOutcomeKind = HandoffOutcome, with HandoffKind = SpecialistHandoff or one other narrowed handoff plan when heterogeneity is the truthful downstream result;
• SelectorOutcomeKind = AbstainOutcome when no admissible candidate exists and the truthful result is one abstain;
• SelectorOutcomeKind = EscalationOutcome when no admissible candidate exists and the truthful result is one escalation.

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

A publication result should state at least these fields:

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

A compact result may therefore 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
)

or:

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

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

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

#Publication quick card

The smallest useful G.5 publication card usually states:

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

A short conforming card may therefore read:

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

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

#Derived tradition-view publication 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, the public selected-set label still closes as Shortlist or RankedShortlist; when SelectorOutcomeKind = HandoffOutcome, the result closes as one SpecialistHandoff or one other narrowed handoff. The derived tradition view disciplines the source, not the emitted outcome family.
• When such a derived tradition view is active, publish 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/coverage rule, cite that declared basis directly in DRR/SCR or equivalent basis pins rather than leaving the derivation implicit.
• If no derived tradition view is active, stay with the declared palette, front, archive, or shortlist families already named by the selector record.

#Worked publication closure slice

Three short contrasts keep the publication law practical.

Several survivors, no public order belongs to the result. When the selector has retained more than one admissible family but no downstream public order belongs to the published result, G.5 should close as one Shortlist over the registered surviving rows:

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

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

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

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

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

GPatternExtension block: G.5:Ext.EELog

• PatternScopeId: G.5:Ext.EELog

• GPatternExtensionId: EELog

• GPatternExtensionKind: MethodSpecific

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

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

• Notes (extension discipline; semantics cited):

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

GPatternExtension block: G.5:Ext.SoSLOG

• PatternScopeId: G.5:Ext.SoSLOG

• GPatternExtensionId: SoSLOG

• GPatternExtensionKind: MethodSpecific

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

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • SoSLogRuleId[]
  • SoSLogBranchId[] (including escalation branches, if used)
  • FailureBehaviorPolicyId (if degrade behavior is made explicit)
  • MaturityRungId[]? (when maturity ladders are used as gates; semantics come from [C.23](/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/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)}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

• Notes (extension discipline; semantics cited):

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

GPatternExtension block: G.5:Ext.OpenEndedFamilyWiring

• PatternScopeId: G.5:Ext.OpenEndedFamilyWiring

• GPatternExtensionId: OpenEndedFamilyWiring

• GPatternExtensionKind: GeneratorSpecific

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

• Notes (extension discipline; semantics cited):

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

#Selector-facing outcome kinds

• SelectionSlot returns one selector outcome, not one forced single winner.
• The emitted result should declare its SelectorOutcomeKind.
• 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 the lens-declared selected set emitted from SelectionSlot.
• RankedShortlist names one ordered specialization of that shortlist result.
• ShortlistId is the emitted public token when the shortlist publication must be carried or cited.
• ChoiceSet may be used only as the mathematical set gloss for that shortlist when the set object itself is under analysis; it does not replace the public shortlist head.
• PortfolioMode states how the selector operated; it does not rename the emitted set result.
• The default PortfolioMode=Archive means that an unspecified selector/generator operating mode must preserve retained exploration evidence rather than pretending one current front or selected shortlist has already been emitted. It does not make every returned object an Archive, does not override SetResultFamily, and does not change the declared DominanceSet.
• If one selector consumes both a front and an archive, say so explicitly rather than blurring them into one generic portfolio.
• If one selector consumes one derived tradition view, keep that derived view explicit rather than silently treating it as the default meaning of Tradition.
• 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+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 Shortlist.
• BasePaletteRef is one cited ref/id, not one kind.
• If one selected result comes from one declared source set, publish 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, backstop_confidence, or sequencing pressures matter, keep them explicit in the surrounding choice doctrine instead of smuggling them into set-result declaration fields.
• Selector-facing results should name the set-result kind, source-set kind, derived-view declaration when needed, the emitted shortlist family, and promotion/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). System must choose among rival families without lying about measurement legality, crossings, or evidence. Episteme insists that what is chosen must remain comparable, auditable, and stable under refresh.

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

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

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

#Bias-Annotation

Potential biases and failure modes this pattern explicitly guards against:

• Monoculture bias (single Tradition dominance by default). Mitigation: registry requires explicit eligibility/assurance records; selection is set‑returning under partial orders; method‑specific policies stay explicit pins rather than hard-coded defaults.
• Hidden scalarisation bias. Mitigation: set‑return semantics is core‑routed; dominance regimes are explicit and each default cites one declared governing definition.
• “Tool equals method” bias. Mitigation: notation independence + prohibition of tool keywords in core registry/eligibility fields; tool choices are outside the core.
• Cross‑Context leakage bias. Mitigation: explicit crossing pins only; Bridges + CL are required when crossings occur; no implicit crossings.
• Survivorship bias in refresh. Mitigation: RSCR triggers are typed/id‑based; freshness/decay and telemetry deltas are first‑class causes with canonical ids.

#Conformance Checklist (normative)

#Common Anti-Patterns and How to Avoid Them

• Anti‑pattern: “Selector as a shadow spec.” Symptom: local acceptance/legality rules appear in selector prose/code, diverging from CN/CG/CAL. Avoid: route all constraint semantics via CNSpecRef/CGSpecRef and pinned CAL records; keep G.5 core as a facade.

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

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

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

• Anti‑pattern: “Churn by meaning.” Symptom: registry entries are “renamed” to reflect updated interpretation, breaking continuity. Avoid: version/deprecate; keep stable ids; use explicit edition pins and deprecation notices.

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

• Anti‑pattern: “Published result without closure record.” Symptom: a Shortlist, narrowed handoff, or abstain result is named, but the emitted result still does not state its members, ordering status, or basis pins. Avoid: publish the head, retained members, ordering status, abstain or escalation condition, and basis pins directly in G.5.

#Consequences

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

#Rationale

• Why registries? Dispatch requires stable, auditable family objects with explicit eligibility and assurance records; otherwise selection collapses into ad-hoc tooling.
• Why separation via Extensions? QD/OEE/preference-learning and similar families are fast-moving and method-specific; making them part of the selector head would force a universal semantics and violate strict distinction.
• Why set-return? Partial orders are common and often the only admissible representation under heterogeneous scales; set-return preserves semantics and makes tie criteria explicit.
• Why explicit defaults with one declared source? Defaults are unavoidable; single-source indexing prevents competing defaults from silently diverging across patterns.
• Why selected-set publication here? Once the current question is to publish one retained set for downstream use, the selector should publish that result directly instead of leaving it implicit in local choice, pool-policy, or enactment notes written for other purposes.

#SoTA-Echoing

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

• Quality-Diversity / illumination (post-2015 refinements). Archive-centric QD families fit naturally as G.5:Ext.NQD extension declarations with explicit descriptor, distance, and insertion pins. The practical implication is to keep publication honest about whether the selector is returning one admissible set, one ranked result, or no admissible survivor at all.

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

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

• Budgeted specialist acquisition. Current agentic search lines compete on time or budget to threshold plus truthful selected-set return when heterogeneous specialists remain non-dominated, so G.5 keeps specialization profiles and set-return semantics explicit instead of forcing one static breadth winner.

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

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

#Relations

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

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

• Governing spec refs: A.19 (CN‑Spec), G.0 (CG‑Spec).
• Upstream object sets: G.1 (CG‑Frame Card), G.2 (SoTA Pack), G.3 (CHR Pack), G.4 (CAL Pack).
• Evidence & crossings: G.6 (EvidenceGraph; PathId/PathSliceId), G.7 (Bridge/CL calibration), E.18/A.21 (CrossingBundle/GateChecks).
• Planning/enactment boundary: A.15.3 (SlotFillingsPlanItem) as the plannedBaselineRef (cited, not redefined).
• Causal-use method dispatch: C.28 when method selection involves causal effect, counterfactual comparison, causal fairness, causal policy, causal RL, or simulation-only causal-use claims.
• Optional method/generator extensions via G.5:Ext.*: C.18, C.19, C.23, plus any future extension-bearing patterns that add extra selector pins.
• Mathematical-lens use: apply C.29 when a selector input depends on a claim-relevant comparator, distance, descriptor geometry, embedding, normalization, surrogate model, learned representation, QD archive descriptor, model-family label, or model-selection basis whose mathematical object, mapping mode, preserved/lost structure, or stop condition is not yet recoverable. C.29 may return NoMathLensUseNeeded, MathLensUse.LensCandidateNote, MathLensUse.OneLine, MathLensUse.MiniCard, MathLensUse.FullCard, or NeighborGoverningPatternNote for the stated selector use. It does not publish the selected set, selector policy, registry row, shortlist, ranked shortlist, or selector evidence pins; those stay in G.5 and its governing refs.

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

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

#G.5:End

#Evidence Graph and Provenance Ledger: Citable Evidence-Provenance Paths

Type: Evidence and provenance pattern Status: Stable Normativity: Normative where conformance rows say so; examples and SoTA rows are informative guidance.

#Problem Frame

Use this pattern when a claim, admission result, assurance result, selector result, maturity transition, benchmark result, or refresh decision needs a citable evidence-provenance path rather than a local evidence-use statement.

Use it when the working question is:

• which evidence-use relations, source records, work occurrences, method descriptions, proof checks, measurements, status-use relations, or causal-use references make the claim traceable;
• that the evidence relation is a graph path in a declared provenance graph, while actual work and transformation-flow claims remain governed by A.15.1 and E.18;
• which time window, bounded context, reference plane, bridge, edition, policy, or source-currentness relation changes the admissible use;
• which downstream selector record, assurance record, release package, benchmark record, audit record, or refresh record may cite the evidence path without copying the whole evidence table;
• what stronger downstream use is not carried by the evidence path and which direct pattern governs that use.

Primary EntityOfConcern. The primary EntityOfConcern is addressable evidence provenance: an EvidenceGraph, its graph-path addresses PathId and PathSliceId, and the provenance ledger entries that make those paths replayable. The pattern governs addressable provenance. It does not create U.EvidenceRole, does not make an episteme hold a work-facing role, and does not replace A.10, A.2.4, B.3, C.28, or F.10.

First useful move. Write the smallest PathCitationRecord: claim or use, EvidenceGraphRef, graph path, bounded context, downstream citation use or evidence-use relation, time window, source or provenance constraints, bridge or edition refs when current, and NotCarried.

What goes wrong if missed. Evidence is summarized as a story, badge, confidence phrase, benchmark score, proof label, or dashboard tile; downstream users cannot find which sources and checks carried the claim; context crossings are hidden; refresh becomes a global rerun instead of a local path update.

What this buys. A selector, auditor, assurance user, benchmark consumer, or refresh process can cite one stable path and later replay exactly the sources, relations, windows, and constraints that made the claim admissible.

Not this pattern when. If only one episteme is being used as evidence or status before a full path is needed, use A.2.4. If the current question is ordinary evidence relation and source-currentness without Part-G path addressing, use A.10. If the claim is assurance, use B.3. If the claim is causal use, use C.28. If the question is status-family mapping, use F.10. If the question is publication, view, source-use, explanation-use, or specification-use, use E.17, E.17.0, E.17.2, E.17.EFP, or E.10.D2. If the question is performed work, use A.15.1.

#Problem

Large projects need to rely on evidence that is distributed across proofs, measurements, work traces, source publications, credentials, model cards, benchmarks, bridge records, and status sources. A compact evidence-use statement is often enough for a local claim, but it is not enough when downstream work must cite, replay, compare, refresh, or audit the whole provenance line.

The common failures are:

1. Narrative provenance. A report says "because the evidence carries the claim" but does not expose the graph path from claim to evidence relations, sources, checks, and work occurrences.
2. Hidden crossing. Evidence accepted in one bounded context, reference plane, edition, or status window is reused in another as if no bridge or currentness relation were needed.
3. Role drift. A proof, dataset, status cell, report, or benchmark result is treated as if it held an evidence role, instead of being a value in an evidence-use, status-use, source-use, or provenance relation.
4. Path metaphor drift. A graph path is read as an action route or workflow. The pattern then starts teaching how work flows, rather than how a provenance graph is addressed.
5. Ledger process drift. A provenance ledger is confused with work-progress, review-comment, or process evidence. The pattern then records development status instead of citable evidence-provenance facts.
6. Refresh fanout. A source edit, edition change, decay event, bridge change, or policy change forces a broad "rerun everything" because the affected evidence paths were never addressable.

#Forces

#Solution

Create a citable EvidenceGraph and PathCitationRecord set when a local evidence-use statement is too small for the reliance being claimed. Keep the graph declarative and typed: nodes and edges carry provenance relations; PathId and PathSliceId cite graph paths; a provenance ledger records replayable path entries.

#Boundary to Neighboring Patterns

G.6 is a path-addressing pattern over evidence provenance. It consumes or cites the following values without redefining them:

Do not add a local EvidenceRole value set. Older labels such as "proof role", "measurement role", "benchmark role", or "status role" are repair prompts. Recover the direct evidence-use, status-use, source-use, causal-use, assurance, work, or publication-use relation first.

#EvidenceGraph

An EvidenceGraph is a typed directed acyclic graph used for evidence-provenance citation. It is a graph because path identity, path slicing, and path-local refresh depend on graph structure. The graph is not a holarchy, not a transformation-flow structure, not a work plan, and not a method.

Minimal graph fields:

EvidenceGraph:
  EvidenceGraphId:
  BoundedContext:
  ClaimFamilyOrUse:
  ReferencePlane:
  GraphNodeSet:
  GraphEdgeSet:
  TimePolicyOrWindow:
  SourceCurrentnessPolicy:
  BridgeOrTransferRefs:
  EditionOrPolicyRefs:
  GraphPathAddressingRule:

Minimal node kinds: