#Part G – Discipline SoTA Patterns Kit

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

#Content

#G.Core - Part G Core Invariants

Tag. Architectural pattern (Part‑G core invariants hub; refactoring/deduplication) Stage. design‑time (authoring discipline + ID‑stable routing; 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. Draft (Phase‑2 deliverable)
Placement. Part G → immediately after G.0 (without renumbering G.0…G.13)
Normativity. Normative unless explicitly marked informative

Purpose. Provide a single owner for Part‑G‑wide invariants (delegation‑first routing), plus a typed RSCR trigger kind catalogue and a Default Ownership 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 owner‑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 single‑owner discipline 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 SemanticOwnerPatternId), 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 reside in G.Core as a single-owner pattern 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 a single owner for Part‑G‑wide invariants, Part G drifts in at least six recurring ways:

1. Shadow contract surfaces emerge: downstream patterns restate CN‑Spec / CG‑Spec constraints, accidentally creating “local specs” that can diverge from the canonical contract surfaces.
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 ownership: downstream patterns drift into “owning” what should remain owned by the suite boundary (A.6.7/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

• Single source of truth 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 owners (A.6.7 / A.15.3 / A.19 / G.0 / A.19.CHR / E.*). G.Core must route to them rather than duplicating semantics.
• Backwards compatibility: Public CC IDs and legacy trigger tokens must remain stable; 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 contract surfaces (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 owner‑patterns, or marked Phase‑3 seeds (appendix) without new Phase‑2 norms.

#G.Core:4 - Solution

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

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

G.Core is a routing hub, not a “second spec”. For any Part‑G‑wide invariant that already has an owner, G.Core:

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

Routing table (normative index; no semantic duplication).

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

• the typed RSCRTriggerKindId catalogue (single writer),
• the Default Ownership Index (single owner 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 contract 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; owner is resolved via G.Core.DefaultOwnershipIndex; cite owner, 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/backward compatibility (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 - Owner model

• TriggerOwner := 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 legacy G.6:H3 and G.11:T0…T7 triggers 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.DefaultOwnerChange

#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 legacy tokens 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 legacy 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 Ownership Index

G.Core provides an index of Part‑G defaults with a single owner per DefaultId. The index is not a “second spec”; it is a cross-reference table that points to the true owner (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).

• DefaultOwnerRef A reference to the single owner 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 owner per DefaultId.
• Any other mention in G.x MUST be a citation/delegation to the owner, not a competing statement.
• A default may be conditional (default-rule) with explicit applicability conditions.
• The Default Ownership Index SHALL NOT be used to “smuggle” mandatory invariants as defaults. Invariants remain invariants (typically routed via CC‑GCORE‑… to canonical owners).

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

This table may grow over time; the rule is that the owner must already exist (or be intentionally set to G.Core when the default is truly Part‑G‑wide and not owned elsewhere). Any change in a row (add/remove/change owner) SHALL be treated as a refresh‑sensitive edit and recorded as RSCRTriggerKindId.DefaultOwnerChange (payload: affected DefaultId.*, old owner ref, new owner 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.

Legacy trigger tokens (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 owning G.x;
• introduce method-family taxonomies, discipline packs, or generator orchestration mechanisms; those remain as Extensions in their owners (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 are routed to canonical owners (A.6.7 / A.15.3 / A.19 / G.0 / A.19.CHR), while RSCR causes and default ownership become typed and single-owned.

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 Ownership Index points to a single owner (currently CC‑G5.23). Other patterns (e.g., bundles/log patterns) must cite that owner 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: A single hub can become too “thick”. Mitigation: delegation-first routing; 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 Ownership Index allows conditional default rules with explicit applicability conditions.
• Single-writer bias: prefers single‑writer authoring for catalogs and explicit ownership tables.
  Mitigation: delegation-first routing; 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 contract surfaces, 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 / G.0; route via 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‑* routed to canonical owners); restrict the Default Ownership 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 Ownership Index; delegate duplicate statements to the single owner.

• 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 become single-owned; 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 via single-owner discipline.
• 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 source of truth. Delegation-first routing prevents duplication and makes ownership explicit, while typed triggers and default ownership 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 portfolio/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 (routing surface)
  • 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, single-owner defaults, 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), describedEntity, SCP, MinimalEvidence, CNSpecRef, Γ‑fold, Φ(CL) / Φ_plane policy pins, UTS publication (Name Cards + edition pins). Non-duplication note. Universal Part‑G invariants are owned by G.Core and are satisfied here only via delegation (CC‑G0‑CoreRef → CC‑GCORE‑*). Single‑owner contract-surface discipline (CN/CG) 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 portfolio selection). 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 lawful 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 be strong enough to matter, 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 owned by CAL, not by CG‑Spec),
• optional method-family hooks (e.g., illumination/QD or explore↔exploit guards) as wiring only, with semantics owned 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; single-owner routing)

GCoreLinkageManifest (normative; size-controlled via profiles/sets).

Effective obligations/pins/triggers are computed by union expansion of the referenced ids (per G.Core:4.2). 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} (owner: CC‑G5.4 per G.Core.DefaultOwnershipIndex)
• RSCRTriggerSetIds := {GCoreTriggerSetId.CGSpecGate}
• RSCRTriggerKindIds := (delta over TriggerSets)
  • RSCRTriggerKindId.EvidenceSurfaceEdit
  • RSCRTriggerKindId.TokenizationOrNameChange
  • RSCRTriggerKindId.DefaultOwnerChange
• 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 owned 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},

  describedEntity := ⟨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 (single-owner)

  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 owned 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 owned by CAL (G.4)

  // Optional hooks are wiring-only; semantics live in owners.
  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/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 + lifecycle + bridge notes),
  Lifecycle := ⟨owner, DRR link, refresh cadence, decay/aging, 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)

#Authoring workflow for CG‑Spec (informative)

1. Charter the frame. Declare Context, Scope, describedEntity, 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 single owner 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. Lifecycle 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 semantic owners.

GPatternExtension: ContractSurfaces

• PatternScopeId: G.0:Ext.ContractSurfaces

• GPatternExtensionId: ContractSurfaces

• GPatternExtensionKind: InteropSpecific

• SemanticOwnerPatternId: 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

• SemanticOwnerPatternId: 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

• SemanticOwnerPatternId: 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 owned 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

• SemanticOwnerPatternId: 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 owned 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/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 portfolio selection across traditions

Tell. A team selects an R&D portfolio 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 portfolio (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 describedEntity or reference planes; mitigation: require explicit describedEntity 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) owns 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 owner 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 ownership, P2W split, linkage discipline, shipping boundary) are single‑owner in G.Core and are only cited here.

Start here when. Your first deliverable is a reusable generator / selector / portfolio scaffold rather than a one-off plan, one-off comparison, or tool-specific workflow 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.

Typical next owners. 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 escalations / reroutes. If the real burden is only a one-off governed comparison or shortlist, reroute to A.19 / G.0 / G.5; if the real burden is project alignment rather than kit authoring, reroute to A.15; if tooling choice is being treated as the first artefact, hold the route here until 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, describedEntity, contract surfaces),
• a local SoTA set (scoped and provenance‑anchored),
• a variant pool (candidate ideas / decision options / method variants),
• a shortlist (a set/portfolio 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 live in G.2,
• selection/dispatch semantics live in G.5,
• CHR/CAL payload semantics live in G.3 / G.4,
• shipping ownership lives in G.10,
• refresh orchestration ownership lives in 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 },

  // Pattern‑owned kit identifiers (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 (single‑owner; this pattern only cites owners via `G.Core.DefaultOwnershipIndex`).
  DefaultsConsumed := {
    DefaultId.GammaFoldForR_eff,   // owner: CC‑G5.4
    DefaultId.PortfolioMode,       // owner: CC‑G5.23
    DefaultId.DominanceRegime      // owner: CC‑G5.28
  }
⟩

Routing rule (normative): the semantics of CC‑GCORE‑*, RSCRTriggerKindId.*, and DefaultId.* are single‑owner in their canonical owners (primarily G.Core, and for the defaults above the owners listed in G.Core.DefaultOwnershipIndex). 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 owned 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)

Owns (kit surface):

• CG‑FrameContext and its binding pins:

  • describedEntity := ⟨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 contract/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)

Owns (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

Semantic owner: harvesting discipline and SoTA‑pack payload are owned 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)

Owns (kit surface):

• VariantPoolId bound to CG‑FrameContext
• per‑candidate minimal traceability fields (emitter identity, EmitterPolicyRef (policy‑id/ref; owner‑defined), 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.

Semantic owner of method payload: method‑specific emitter semantics live in 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)

Owns (kit surface):

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

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

#M5 — CG‑FrameLibrary (published bindings index)

Owns (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 owned by G.3, G.4, G.8)
  • published identifiers (UTS rows, Name Cards) per Part‑F owners
  • additional Part‑F binding surfaces (e.g., RoleDescription templates, Concept‑Set rows) by owner‑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, ownership is G.10.

#M6 — RefreshReadiness Card (telemetry hooks + wiring)

Owns (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 owners
• 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 owned 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 SemanticOwnerPatternId: 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 SemanticOwnerPatternId: G.5 Uses: {G.5, G.4} ⊑/⊑⁺: ∅

RequiredPins/EditionPins/PolicyPins (minimum):

• ShortlistId
• SCRId (assurance/rationale surface by id; semantics owned by the selector/assurance owners)
• 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; owner‑defined) when not defaulted (default ownership is routed via G.Core.DefaultOwnershipIndex)

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 SemanticOwnerPatternId: 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 (owned 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 owners.

#GPatternExtension — G.1:Ext.NQD

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

• DescriptorMapRef.edition
• DistanceDefRef.edition
• InsertionPolicyRef (policy id / ref, as defined by the owner)
• 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 owner, 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/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 SemanticOwnerPatternId: G.2 (family semantics live in SoTA cards; this block only wires pins; selector‑side wiring is owned 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 portfolios 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 SemanticOwnerPatternId: 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 owned by G.11.

#GPatternExtension — G.1:Ext.ShippingWiring

PatternScopeId: G.1:Ext.ShippingWiring
GPatternExtensionId: ShippingWiring
GPatternExtensionKind: GeneratorSpecific
SemanticOwnerPatternId: 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 contract/legality/selection/refresh owners.

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

• M1: define CG‑FrameContext for “R&D decision options”, pin CNSpecRef/CGSpecRef editions, and publish describedEntity + 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 portfolio set 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 (owned by G.2).
• M3: generate policy‑constrained candidate protocols; emitter trace and evidence pins are mandatory.
• M4: shortlist remains a set; “choose one” is deferred to explicit policy, 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 owned).
• Algorithmic favoritism: baking a preferred generator into “the chassis” (mitigate by keeping M3 method‑agnostic and pushing methods into Extensions).
• Scalarisation bias: collapsing portfolios/partial orders into a single score (mitigate by set‑return discipline routed via 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 contract surfaces; use pins and owner references only.

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

• Anti‑pattern: “Shortlist = one winner.” Avoid: preserve set/portfolio 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 ownership.” 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 single‑owner.

#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 ownership 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 workflows (e.g., PRISMA‑style traceability and update cadence) map naturally to M2 wiring owned 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 (owned 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/C.19. Publishes to / consumes from: Part‑F publication surfaces (UTS, naming, RSCR tests, Role/Concept artefacts) as cited by their owners.

#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 owns the harvesting + synthesis generator in Part G. Shipping ownership is in G.10, refresh orchestration ownership 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 describedEntity),
• 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 owner patterns.

#Solution

#G.Core linkage (normative)

Builds on: G.Core (Part‑G core invariants; routing 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[], describedEntity := ⟨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 (owned 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 (pattern‑owned surface)

A conforming G.2 publication produces a notation‑independent pack whose internal organisation is free, but whose exported named components / 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 home context and describedEntity,
• explicit evidence anchors/citations (A.10 and/or EvidenceGraph refs when available),
• explicit freshness window notes and risk/trust cues (cite B.3 owners 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 cross‑source / cross‑Tradition substitution or fusion, 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 + describedEntity, 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 describedEntity 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 owners).

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 wiring stubs needed by G.5 (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; owner‑routed; 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 describedEntity 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‑owned)

A conforming G.2 work product 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 describedEntity 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 work product asserts cross‑source / cross‑Tradition fusion or substitution (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 + describedEntity.

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 owned 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 modules. They do not introduce Part‑G‑wide norms; they provide wiring/pins and cite semantic owners.

#GPatternExtension: GammaEpistSynthesis

PatternScopeId: G.2:Ext.GammaEpistSynthesis
GPatternExtensionId: GammaEpistSynthesis
GPatternExtensionKind: GeneratorSpecific
SemanticOwnerPatternId: G.2 (this pattern owns synthesis semantics; module exists for modularity + later extraction)
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 routed via owners; 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 owners) for each asserted fusion/substitution.
• This module 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 SemanticOwnerPatternId: owner TBD (Phase‑3 seed: harvesting protocol taxonomy not yet extracted into a dedicated owner) 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 (wiring‑only):

• This module 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 SemanticOwnerPatternId: C.21 (DHC semantics are owned 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 (wiring‑only):

• If DHC alignment summaries are emitted, this module ensures the DHC method edition and the cited evidence paths are visible.
• Units/constraints (semantic owner: 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 SemanticOwnerPatternId: C.18 (NQD‑CAL semantics owned by C.18; explore/exploit logging 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 (wiring‑only):

• This module 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 SemanticOwnerPatternId: 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 (wiring‑only):

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

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

#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 strong 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 wiring) — 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 ownership routing)
  • E.8 (pattern template discipline)
  • E.10 (lexical/ontological rules; strict distinction; kind‑suffix discipline)
  • E.19 (conformance discipline)
  • A.10 (provenance anchors / carriers)
  • B.3 (trust, freshness/decay as cited owners)
  • F.9 (bridges and CL as cited owners)
  • 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)

#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 lawful 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/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, single‑owner defaults, linkage discipline) are owned 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 lawful characterization layer that makes downstream work possible without hidden semantic drift:

• CAL authoring (G.4) needs typed, lawful operands and guard/legality surfaces to build admissibility and acceptance rules (thresholds and policy cut‑offs remain CAL‑owned).
• Selector/dispatch (G.5) needs CHR‑typed quantities and explicit provenance pins so selection can remain set‑returning and auditable under lawful 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 deliverable 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/loss notes; unclear describedEntity changes).
• Un-auditable aggregation (no explicit legality/guard surface; no proof hooks; unclear Γ‑fold ownership).
• 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; routing/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, describedEntity, 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 + lifecycle) 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.DefaultOwnerChange, 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 routed to owners; see G.Core + 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), lifecycle notes, and (when applicable) bridge/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

#Authoring workflow: CHR authoring chassis (S1–S8)

S1 — Charter the measurement scope (scope anchor). Declare the CHR home context/scope for the CG‑Frame, including: describedEntity 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 (semantic owner: 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 owned by B.3; evidence‑path representation & audit owned 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 semantic owner taxonomy (owner: 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 owning 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/coordinate term: attempt reuse; otherwise mint via UTS Name Cards with twin labels and lifecycle notes. When a term is imported across contexts, the import must be explicit and auditable (bridge/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 routed to owners):

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 owned by G.4/G.6), ScaleRef, Polarity ∈ {↑, ↓, ⊥}, Domain/Range, UnitSet, Bounds / zero semantics (as applicable), Freshness / half‑life (or explicit NonDecayingDecl; freshness/decay semantics owned 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 semantic owner + required pins; see G.3:4.5), QD.Role? ∈ {Q, D, QD-score} (interop alias for RoleDeclwithSemanticOwnerPatternId = C.18; see G.3:Ext.QD_OEE_Wiring), Micro‑examples (R‑anchors: Path/PathSlice cited; lane tags where applicable) ⟩

Where RoleDecl := ⟨ roleLabel, SemanticOwnerPatternId, EditionPins?, PolicyPins? ⟩ (wiring‑only; semantics owned by SemanticOwnerPatternId).

Rules (CHR‑owned intent, semantics routed where indicated):

• Scale/unit/polarity legality obligations are routed to MM‑CHR owners (A.18/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 owned by G.Core).
• If EvidenceLanes are recorded, they are only lane tags for downstream evidence discipline (taxonomy owner: B.3; audit surface: G.6; any cross‑lane policy is owned by G.4); this pattern does not introduce lane semantics or invent bridge‑like constructs.
• If RoleDecls are used, each declaration MUST cite its semantic owner pattern (e.g., C.18/C.19) and surface the edition/policy pins required by that owner; CHR does not define role semantics locally.
• Role docking (normative, wiring-only): if any RoleDecl is present with SemanticOwnerPatternId = X, then G.3 MUST include (or explicitly cite) a corresponding GPatternExtension block whose owner 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 routed to 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 owned 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 owners 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 stronger structure is claimed.

A coordinate never silently upgrades a scale type; if an upgrade is claimed, the proof burden is explicit and routed to MM‑CHR owners.

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 be routed (no “shadow semantics” in this pattern). Examples of macro intents (owners in parentheses):

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

S7 — Publish AggregationSpecs (typed, lawful, 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, it is referenced via DefaultId.GammaFoldForR_eff (single‑owner routing is via G.Core.DefaultOwnershipIndex; do not restate defaults 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 owned 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/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 own orchestration (owner: 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 semantic owners.

GPatternExtension: SuiteBoundaryLinkage

• PatternScopeId: G.3:Ext.SuiteBoundaryLinkage

• GPatternExtensionId: SuiteBoundaryLinkage

• GPatternExtensionKind: InteropSpecific

• SemanticOwnerPatternId: 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 owned by A.19.CHR.

GPatternExtension: SoTAPackInputs

• PatternScopeId: G.3:Ext.SoTAPackInputs

• GPatternExtensionId: SoTAPackInputs

• GPatternExtensionKind: DisciplineSpecific

• SemanticOwnerPatternId: 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 owned 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

• SemanticOwnerPatternId: 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 ownership stay with G.0; CHR only pins and cites.

GPatternExtension: MMCHRLegalityWiring

• PatternScopeId: G.3:Ext.MMCHRLegalityWiring

• GPatternExtensionId: MMCHRLegalityWiring

• GPatternExtensionKind: DisciplineSpecific

• SemanticOwnerPatternId: 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 owners; 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 owned by the referenced patterns.

GPatternExtension: DecayWiring

• PatternScopeId: G.3:Ext.DecayWiring

• GPatternExtensionId: DecayWiring

• GPatternExtensionKind: DisciplineSpecific

• SemanticOwnerPatternId: 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 owner)
  • 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 owner-defined 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

• SemanticOwnerPatternId: 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 owned by C.18/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/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 routed via 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 owns 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 routed via 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 (routed via 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/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 owners.
• 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 (routed via 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 ownership) are single‑owner, 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 ownership 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/C.19 (QD/OEE wiring). Publishes to: G.4 (admissible operators + legality/guard macros + freshness routing), G.5 (role declarations + pins for reproducibility), UTS (Name Cards + lifecycle), RSCR tests/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 + twin labels + lifecycle notes incl. deprecations and lexical‑continuity notes), RSCR tests, Worked‑Examples, and a TaskMap@Context (TaskMap; handoff surface consumed by G.5).

Primary hooks. G.Core (Part‑G invariants + RSCR trigger catalogue + default ownership 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 + A.27 (GateCrossing / CrossingBundle harnesses), F.9 (BridgeCard / CL), 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 ownership discipline, shipping boundary) are single‑owned by 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, described entity, plane),
• a plurality of method traditions and claims (SoTA inputs), and
• CHR‑typed measurement surfaces (Characteristic/Scale/Coordinate + legality guard macros).

Before any run‑time selection, comparison, aggregation, or portfolio formation is executed downstream, the CG‑Frame needs an explicit, auditable calculus layer (CAL) 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 contract legality to CG‑Spec/CN‑Spec.

#Problem

Teams repeatedly face drift and ambiguity in the calculus layer 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/planes/editions without published GateCrossings and loss accounting).
• Tooling artifacts become semantics (vendor flags or implementation details substitute for a conceptual contract).

#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 portfolio 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; routing/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 + lifecycle 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.DefaultOwnerChange, 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, routed semantics):

• The semantics of tri‑state outcomes, penalty routing, set‑return discipline, crossing visibility, P2W split, typed RSCR causes, and default ownership are single‑owned by 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 (pattern‑owned kit)

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

• CAL.Charter@Context — scope anchor for this CAL pack:

  • cites CG-FrameContext, describedEntity, 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 surface 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; set/portfolio 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 owned by method‑specific owners (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 layer:

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

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 ownership: CAL does not own shipping (delegated; see CC‑GCORE‑SKP‑1 via CC‑G4‑CoreRef).
• No refresh ownership: CAL does not own refresh orchestration; it only publishes pins/payload for refresh (owner: 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[], lifecycleNoteIds[] ⟩

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 (pattern‑owned kit)

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

• anchors CAL to the CG‑Frame scope (CG-FrameContext, describedEntity, 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/plane/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/A.27; 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 set/portfolio).
• 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 routed 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 routed). 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 owned 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/plane/edition import required by CAL publication is handled through GateCrossing/CrossingBundle discipline (as routed by G.Core), and CAL publication is blocked if required crossing artifacts are missing.

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

• record changes as edition‑pinned updates,
• publish deprecations/lifecycle notes for public ids,
• emit RSCR‑relevant trigger payload pins (editions/policies/UTS ids/paths) for refresh orchestration (owner: 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
• SemanticOwnerPatternId: 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
• SemanticOwnerPatternId: 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 artifacts needed for reproducible archive/descriptor 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
• SemanticOwnerPatternId: 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
• SemanticOwnerPatternId: 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
• SemanticOwnerPatternId: owner TBD
• 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 owned elsewhere before becoming normative.

#Archetypal Grounding

Tell. A CG‑Frame must choose and justify a set of candidate methods (possibly a portfolio) under explicit legality, evidence, and scope constraints. CHR provides the typed measurement surface; CAL turns it into executable, auditable predicates and flows.

Show 1 (in‑context CAL pack skeleton). Context: R&D portfolio 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 set/portfolio 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/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 through the routed 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 calculus layer: 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 owns measurement typing and legality guard macros,
• CG‑Spec and CN‑Spec own the legality gate and governance card, respectively,
• G.Core owns Part‑G invariants and trigger/default discipline,
• G.4 owns the CAL kit: authoring objects, publication surface, and handoff manifest.

This yields modularity (single owner per invariant/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 portfolios.
• 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 semantic owners), 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 + A.27 (GateCrossing harness), F.9 (BridgeCard/CL).

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 + lifecycle), RSCR (tests + trigger emissions), G.5 (handoff manifest), and (as cited payload) shipped packs owned by G.10.

Constrains: any run‑time LOG implementation that executes CAL operators/flows must treat CAL artifacts as citable contracts 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 surfaces 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 lawfully act on the same declared task family or work target
• you need one selector to return a Shortlist, RankedShortlist, portfolio, narrowed handoff plan, or abstain outcome without pretending that there is always one scalar winner
• the published result must carry enough basis pins to support later comparison, handoff, or escalation without changing its public head

#What goes wrong if missed

• rival families are compared under silent comparator drift, hidden baseline changes, or unspoken crossing costs
• the selector hides one dogmatic winner even when only a partial order is lawful
• selected-set publication gets hidden inside C.11, C.19, or C.24, so the published artifact 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 surface that can publish candidate sets, Shortlist, RankedShortlist, specialist portfolios, 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 public head, retained members, ordering status, and basis pins are stated directly in the emitted result

Registry and dispatch remain the primary owner burden here; selected-set publication is the explicit closure surface of that selector burden, not a replacement for it.

#First-minute questions

• What public head is this selector result actually emitting: Shortlist, RankedShortlist, portfolio, narrowed handoff, or abstain?
• 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 burden is one published selected-set artifact: Shortlist, RankedShortlist, one specialist portfolio, one narrowed handoff plan, or one abstain/escalation result, with the public head, 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 surfaces here and leaves universal Part-G invariants to G.Core; method- or generator-specific semantics stay in their named source patterns and arrive here only through explicit pins.

When C.11 has already emitted one local choice result, C.19 one pool-policy posture, or C.24 one enactment-facing next move, G.5 begins where the burden 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 public head and basis pins explicit in the result itself.

A publication result remains unfinished if the public head, retained members, ordering status, abstain or escalation condition, or basis pins are still only implicit in upstream notes.

#Problem frame

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

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

You need a notation‑independent way to:

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

#Problem

How to design a general, auditable dispatcher that:

• supports pluralism (families from competing Traditions stay disjoint) while remaining dispatchable (selection is possible and explainable);

• does not embed algorithmic dogma in the core selector kernel;

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

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

• cleanly separates:

  • selector kit/surfaces (registry + selector façade + publication surfaces),
  • 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

#G.Core linkage (normative)

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

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

• CoreConformanceProfileIds :=

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

• CorePinSetIds :=

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

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

  • TaskSignatureRef (see G.5:4.2 / S2)
  • MethodFamilyId[] (registry keys in scope)
  • GeneratorFamilyId[]? (when generator families are in scope)
  • PathId[] (audit citations for “why” and for evidence)
  • PathSliceId[] (audit citations for “why” and for evidence)
  • UTSRowId[] (published identities for selected/registered families and selector policy surfaces)
  • 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 kit (notation‑independent)

G.5 defines the kit surfaces 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 surface (tri‑state per G.Core), expressed in CHR/CAL terms and pinned to the relevant editions.
• AssuranceProfileRef: evidence‑lane expectations and assurance surface 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 surfaces (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 surface, 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 surfaces).
• 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 surface; 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 contract surfaces,
• applies eligibility/assurance gating (tri‑state),
• computes a lawful (possibly partial) order,
• returns a set/portfolio result (per DefaultId.PortfolioMode and explicit overrides),
• emits audit artefacts (DRR/SCR‑addressable pins).

S3.A — TaskFamilySpecializationProfile@Context (run‑time; conditional). When the real selector burden is acquisition of usable specialization on a declared task family, the selector may publish one TaskFamilySpecializationProfile@Context for each candidate, specialist portfolio, or 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 consumes this burden over C.22.1; it does not re-own the adaptation-signature field vocabulary.

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 burden, and any corridor-entry baseline, corridor-entry evidence, or stepping-stone evidence item that materially affects comparison.

When the declared task family is heterogeneous, the selector may return one composed specialist portfolio, one 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 surface.

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

• DRR (decision rationale) + SCR (support/confidence routing) with explicit pins,
• portfolio/return‑set artefacts,
• telemetry pins to refresh orchestration (G.11), without owning orchestration.

When the publication burden is one selected-set surface rather than one generic registry trace, Shortlist is the public head, 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 head.

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

#Selector head and narrower selector families

Selection/dispatch stays one generic selector head. Narrower selector families may refine it, but they do not redefine the universal invariants routed via G.Core, do not add hidden mandatory inputs beyond pinned policy or edition refs, and do not mutate SlotKinds.

Method- and generator-specific pressures such as QD archives, open-ended portfolios, explore/exploit lenses, or preference comparators do not become part of the selector head. They arrive only through explicit extension wiring and the pins those extensions require.

#Interfaces (minimal I/O surface)

#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 burden on adjacent tasks. One family is slower but transfers cleanly. One family never clears MinimalEvidence and must abstain.
• A lawful G.5 result therefore publishes a set-return shortlist or a narrowed handoff plan, with DRR/SCR citing why the third family was excluded and why the first two remain non-dominated. The selector does not invent one scalar winner and does not hide the specialization profile in wiring 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 burden. Until that emission occurs, the internal retained subset is not yet one public shortlist artifact.

#Published selected-set result and closure rule

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

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

The lawful published heads here are:

• Shortlist when one retained set is published without one material internal order;
• RankedShortlist when ordering materially belongs to the published result;
• one specialist portfolio or narrowed handoff plan when heterogeneity is the truthful result;
• one explicit abstain or escalation result when no admissible candidate exists.

Shortlist and RankedShortlist are public selector artifacts over registered rows. They are not merely one upstream internal retained subset copied forward under one prettier head. G.5 is the owner that turns selector state into one public artifact with one explicit head, one explicit member set, and one explicit basis surface.

A publication result should state at least these fields:

• the public head being emitted;
• retained members, or the narrowed handoff content, or the abstain condition;
• ordering status when ordering matters;
• basis pins and policy pins sufficient to justify the result;
• one explicit next downstream use posture when the result is a handoff rather than one terminal publication.

A compact result may therefore look like:

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

or:

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

Close as Shortlist when several retained members survive lawfully but no public internal order belongs to the result. Close as RankedShortlist when order materially belongs to the published artifact. Close as one specialist portfolio or narrowed handoff when heterogeneity itself is the truthful downstream surface. Close as abstain or escalation when no admissible candidate exists under the pinned constraints.

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

#Publication quick card

The smallest useful G.5 publication card usually states:

• publicHead = Shortlist | RankedShortlist | portfolio | narrowed handoff | abstain
• membersOrHandoff = ...
• ordering = ranked | unordered | n/a
• publicId = ... when one public identity is emitted
• basisPins = ...
• nextUse = downstream comparison | specialist handoff | escalation | none

A short lawful card may therefore read:

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

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

#Worked publication closure slice

Three short contrasts keep the publication law practical.

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

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

Order now materially belongs to the published result. When one ordered public handoff is required, G.5 should say so directly instead of leaving order implicit:

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

No admissible candidate survives. When no family clears the pinned legality or evidence gates, G.5 should close as one abstain or escalation result rather than as one empty shortlist pretending to be progress:

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

The practical distinction is simple: an internal retained subset can remain real upstream without yet being one public selector artifact. G.5 begins only when that selector-facing publication burden starts, and it closes only after the public head, surviving members, and basis pins are emitted directly.

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

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

GPatternExtension block: G.5:Ext.EELog

• PatternScopeId: G.5:Ext.EELog

• GPatternExtensionId: EELog

• GPatternExtensionKind: MethodSpecific

• SemanticOwnerPatternId: C.19

• Uses: {C.19}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

• Notes (wiring‑only; semantics routed):

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

GPatternExtension block: G.5:Ext.SoSLOG

• PatternScopeId: G.5:Ext.SoSLOG

• GPatternExtensionId: SoSLOG

• GPatternExtensionKind: MethodSpecific

• SemanticOwnerPatternId: C.23

• Uses: {C.23}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

• Notes (wiring‑only; semantics routed):

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

GPatternExtension block: G.5:Ext.NQD

• PatternScopeId: G.5:Ext.NQD

• GPatternExtensionId: NQD

• GPatternExtensionKind: MethodSpecific

• SemanticOwnerPatternId: C.18

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

• Notes (wiring‑only; semantics routed):

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

GPatternExtension block: G.5:Ext.OpenEndedFamilyWiring

• PatternScopeId: G.5:Ext.OpenEndedFamilyWiring

• GPatternExtensionId: OpenEndedFamilyWiring

• GPatternExtensionKind: GeneratorSpecific

• SemanticOwnerPatternId: G.2 (family semantics live in SoTA cards; G.5 only wires pins)

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

• Notes (wiring‑only; semantics routed):

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

#Archetypal Grounding

Tell (archetype). System must choose among rival families without lying about measurement legality, crossings, or evidence. Episteme insists that what is chosen must remain comparable, auditable, and stable under refresh.

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

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

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

#Bias-Annotation

Potential biases and failure modes this pattern explicitly guards against:

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

#Conformance Checklist (normative)

#Common Anti-Patterns and How to Avoid Them

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

• 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 sets/portfolios; 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 head. Avoid: publish the selected-set artifact directly, with explicit head, members, and basis pins, instead of leaving the shortlist implicit in neighboring doctrine.

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

#Consequences

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

#Rationale

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

#SoTA-Echoing

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

• Quality-Diversity / illumination (post-2015 refinements). Archive-centric QD families fit naturally as G.5:Ext.NQD wiring with explicit descriptor, distance, and insertion pins. The practical implication is to keep publication honest about whether the selector is returning one lawful set, one ranked artifact, or no admissible survivor at all.
• Open-Endedness (post-2015 wave). 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 portfolio-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 surfaces and typed telemetry pins, rather than hard-coded scoring rules. The practical safeguard is that the publication head 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 portfolio 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 artefacts with explicit editions when they are actually declared.

SoTA here is treated as best-known practice for a declared goal and constraint regime, not whatever is currently popular. Evidence-tier clarification: peer-reviewed anchors carry the strongest support for typed comparison, budget-to-threshold, and truthful portfolio return. Faster-moving workshop, poster, or frontier-exploration lines remain explicit support for corridor-entry or open-ended pressure, not silently equal evidence for every selector claim.

#Relations

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

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

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

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

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

#G.5:End

#Evidence Graph & Provenance Ledger

Tag. Architectural pattern Stage. design‑time (assembly) + run‑time (telemetry ingestion) Primary output. A notation‑independent EvidenceGraph + a stable PathId / PathSliceId citation surface + an SCR projection (“Assurance SCR”) suitable for audit, selection explainability, and refresh/RSCR wiring. Primary hooks. A.10 (evidence anchors/carriers; SCR/RSCR anchoring), B.3 (assurance lanes and F/G/R skeleton), F.9 (BridgeCard/CL), G.4 (CAL EvidenceProfiles + ProofLedger linkage), G.Core (Part‑G invariants, RSCR trigger catalogue, default‑ownership index), E.18/A.21 (GateCrossing + CrossingBundle checks), F.17 (UTS publication), F.15 (RSCR), E.10 (LEX), E.5.* (notation‑independence discipline). Non‑duplication note. Universal Part‑G invariants (no shadow specs; Bridge‑only crossings; tri‑state discipline; penalties→R_eff only; P2W split; typed/id‑based RSCR causes; single‑owner defaults; Δ‑discipline) are owned by G.Core and are cited via CC‑GCORE‑*. This pattern defines only the EvidenceGraph kit and its path‑addressable provenance surfaces.

#Problem frame

SoTA claims, operators, and method families are admitted (or gated) using assurance signals derived from diverse artefacts and anchors. FPF already mandates Evidence Graph Referring (A.10), lane discipline, and the assurance skeleton (B.3). What is often still missing in practice is a first‑class, citable object that makes the provenance of an admission/decision addressable:

• exactly which anchors and bindings were used,
• under which ReferencePlane and BoundedContext,
• with which explicit crossings and penalty policies,
• for which time window (freshness/decay),
• in a way that selectors, audits, and maturity transitions can cite without copying tables or re‑telling a story.

This pattern introduces the missing kit: a typed, lane‑aware EvidenceGraph plus stable PathId / PathSliceId addresses that downstream LOG, UTS, parity, and refresh can cite.

Why here (not in G.4)? G.4 owns CAL artefacts (EvidenceProfiles, ProofLedger, acceptance policies). G.6 packages cross‑artefact provenance as a graph and mints path identities that downstream surfaces can cite without duplicating CAL tables or re‑inventing legality rules.

#Problem

1. Readers cannot reliably audit crossing/penalty and decay impacts on claims without chasing many tables and informal narratives.
2. Cross‑Context/plane reuse must remain Bridge‑only and explicit, but provenance often hides crossings (or treats them as “obvious”).
3. Selection and maturity decisions need a stable path address to re‑check later, including after edition/policy/freshness changes.

#Forces

#Solution — EvidenceGraph (notation‑independent; lane‑aware; path‑addressable)

#G.Core linkage (normative)

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

GCoreLinkageManifest (normative; size‑controlled).

GCoreLinkageManifest := ⟨ CoreConformanceProfileIds := { GCoreConformanceProfileId.PartG.AuthoringBase, GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted }, RSCRTriggerSetIds := { GCoreTriggerSetId.EvidenceGraphKit }, CorePinSetIds := { GCorePinSetId.PartG.AuthoringMinimal, GCorePinSetId.PartG.CrossingVisibilityPins }, CorePinsRequired := { EvidenceGraphId, EvidenceGraphRef.edition?, // iff editioned as a published artefact PathId[]/PathSliceId[], // strengthened (unconditional for G.6) UTSRowId[], // strengthened (UTS Name Cards + PathCards are required outputs) Γ_timePolicy?, // iff empirical legs exist (or equivalently: window id carried by PathSliceId) ΓFoldRef.edition?, // iff an explicit Γ-fold artefact is pinned CAL.ProofLedgerId[]? // iff Γ-fold is overridden (cite CAL ProofLedger ids; owner: G.4) }, DefaultsConsumed := { DefaultId.GammaFoldForR_eff }, TriggerAliasMapRef? := G.Core.TriggerAliasMap.G6 ⟩

Conditional add‑on (tri‑state guard). If G.6 is used to publish or consume guard outcomes (e.g., via G.6:Ext.SoSLOGPathCitationWiring), additionally require: CoreConformanceProfileIds += { GCoreConformanceProfileId.PartG.TriStateGuard }.

(Nil‑elision + expansion rule are per G.Core:4.2.)

#EvidenceGraph (object; kit‑owned surface)

Definition (object). An EvidenceGraph is a typed DAG whose nodes are resolvable to A.10 anchors/carriers and evidencing roles, and whose edges represent minimal, normative provenance relations suitable for audit and path citation.

• Nodes. Each node is an A.10‑anchored evidence carrier or evidence role (e.g., a proof carrier, a measurement record carrier, a tool‑qualification carrier). Nodes MUST remain grounded in A.10 anchors and MUST NOT introduce mereological structure (A.10 firewall).

  • Node kinds (explicit; stable). Nodes MUST have an explicit kind tag nodeKind ∈ {U.EvidenceRole, SymbolCarrier, TransformerRole, MethodDescription, Observation} (as used in the existing Part‑G vocabulary), so downstream projections can remain notation‑independent and audit‑checkable.
  • Extension pins. Method‑family‑specific pins (e.g., QD/OEE) MUST NOT be introduced as new “core node kinds”; they are carried as additional pins only when the relevant GPatternExtension is in use and are recorded on UTS PathCards / SCR projections as required by that extension.

• Edges (minimal normative vocabulary). The pattern admits a small set of provenance edges sufficient for audit:

  • verifiedBy (formal line),
  • validatedBy (empirical line),
  • fromWorkSet (run‑time trace provenance),
  • happenedBefore (temporal ordering),
  • derivedFrom (controlled derivation).
  • (Informative only) usedCarrier, interpretedBy MAY appear as authoring aids, but MUST NOT be relied on for conformance checks (their semantics remain non‑normative in G.6). Additional narrative edges MAY exist as informative annotations but MUST NOT be relied on for conformance checks.

• Lane tags. Every binding on a path is lane‑typed with assuranceUse ∈ {TA, VA, LA} (lane separation remains explicit through to SCR projections; no silent cross‑lane averaging).

• Externality (no self‑evidence). Any evidencing TransformerRole that would certify the evaluated holon MUST be modelled as external (or model a meta‑holon explicitly); G.6 does not permit reflexive “self‑evidence” shortcuts.

• Context and plane attachment. Nodes and claims carry BoundedContext and ReferencePlane. Any movement across context/kind/plane/design↔run/edition boundaries is represented via explicit GateCrossing/CrossingBundle artefacts (with crossing pins routed per G.Core).

#PathId and PathSliceId (citable justification addresses)

PathId (address for justifications). A PathId is a stable identifier minted for a claim‑local, lane‑typed path in an EvidenceGraph under a declared scope slice (including a time selector where applicable) and a declared ReferencePlane. A PathId is meant to be citable from downstream artefacts (LOG, UTS, parity, shipping) without duplicating evidence tables.

A PathId citation surface SHALL include, at minimum:

• the lane split (TA/VA/LA) for the path,
• the explicit crossing pins (when crossings are traversed),
• the freshness/time attachment status for empirical legs (when present), including any explicit validUntil/expiry marker when one is declared (or a decay/freshness policy pin that implies expiry),
• the pinned policy identifiers relevant to the path’s penalty/trust wiring (policy ids are cited; policies remain owned elsewhere),
• the effective crossing‑trust “bottleneck” information when crossings exist (e.g., lowest CL/CL^k/CL^plane encountered on the cited slice),
• the effective Γ‑fold in force for any published/relied‑upon R_eff projection (default or explicit override), and (when overridden) the cited CAL ProofLedger ids that justify the override,
• the EvidenceGraphId and enough addressability to resolve the path to SCR/RSCR anchors.

PathSliceId (time‑ & plane‑lifted snapshot). A PathSliceId denotes a release‑quality snapshot key for a path under explicit time/plane binding (e.g., window policy + ReferencePlane) and is intended as the address used when refresh/RSCR wants path‑granular recomputation.

The universal definition of “what kinds of changes force refresh” is owned by G.Core (typed trigger kinds). G.6 only makes the slice addressable and pin‑complete.

When downstream methods require additional edition/policy pins for reproducibility (e.g., archive/illumination/QD surfaces), such pins are specified by the relevant GPatternExtension module(s) and are treated as required pins when that extension is used.

#Assurance and legality binding (delegation‑first; no shadow specs)

G.6 does not redefine B.3 or legality rules; it binds evidence paths to existing owners:

• Assurance skeleton. Lane separation and the F/G/R skeleton are as per B.3. Any statement about penalty routing or default Γ‑fold is delegated to G.Core and the default‑ownership index (do not restate).
• CAL linkage. When a path claims a proof obligation or an override (e.g., an explicit Γ‑fold override), it MUST cite the relevant CAL ProofLedger / EvidenceProfiles artefacts (G.4) rather than inventing local semantics.
• Legality binding. If a path includes numeric comparisons/aggregations, the legality surface MUST be cited via CG‑Spec (G.0) rather than re‑implemented in G.6 prose.

#Conceptual interface (notation‑independent surface; informative shapes)

These are conceptual shapes, not tool APIs (E.5 discipline).

• Explain(pathId | pathSliceId) → returns a citation‑ready explanation bundle: lane split, relevant pins (crossings/policies/editions), freshness binding, and links to contributing anchors (A.10) and any CAL evidence/profile refs.
• PathsFor(claim, scopeSlice, referencePlane) → enumerates admissible paths, returning PathId[] with enough metadata to support selection/audit queries.
• Snapshot(pathId | pathSliceId) → emits a release‑grade snapshot record (SCR/RSCR‑grade) whose keys are citable and whose pins are explicit.

#Extensions (pattern‑scoped; non‑core)

All blocks below are GPatternExtension modules (PatternScopeId‑scoped, not new PatternIds). They store wiring only and cite semantic owners.

GPatternExtension: LegacyTriggerAliases

• PatternScopeId: G.6:Ext.LegacyTriggerAliases

• GPatternExtensionId: LegacyTriggerAliases

• GPatternExtensionKind: InteropSpecific

• SemanticOwnerPatternId: G.Core

• Uses: {G.Core} (cites G.Core.TriggerAliasMap.G6; does not redefine meanings)

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • RSCRTriggerKindId (canonical id recorded)
  • RSCRTriggerAliasId? (e.g., legacy human labels such as G.6:H3:... recorded as labels only)
  • scope: PathSliceId[] | PathId[] | PatternScopeId
  • TriggerAliasMapRef := G.Core.TriggerAliasMap.G6 (docking reference)

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

• Notes (wiring‑only): This module preserves ergonomics/back‑compat by allowing G.6:H3:* labels, while requiring that recorded causes use canonical RSCRTriggerKindId (per CC‑GCORE‑TRIG‑3).

GPatternExtension: SoSLOGPathCitationWiring

• PatternScopeId: G.6:Ext.SoSLOGPathCitationWiring

• GPatternExtensionId: SoSLOGPathCitationWiring

• GPatternExtensionKind: InteropSpecific

• SemanticOwnerPatternId: C.23

• Uses: {C.23, C.19, G.5, G.11} (SoS‑LOG decisions cite paths; optional lens/attribution wiring is owned by C.19; refresh consumes triggers)

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • SoSLogRuleId[] / BranchId[] (as cited labels; semantics owned by C.23)
  • FailureBehaviorPolicyId (when degrade(mode=...) is used)
  • PathId[] | PathSliceId[] (the cited justification addresses)
  • LensId? (when a C.19 lens is used for attribution/explainability; id only; semantics owned by C.19)

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

• Notes (wiring‑only): G.6 does not define LOG semantics; it defines the path‑citation surface that LOG must cite.

GPatternExtension: BridgeSentinelWiring

• PatternScopeId: G.6:Ext.BridgeSentinelWiring

• GPatternExtensionId: BridgeSentinelWiring

• GPatternExtensionKind: InteropSpecific

• SemanticOwnerPatternId: G.7

• Uses: {G.7, G.11} (bridge/sentinel semantics & calibration artefacts are owned by G.7; refresh orchestration is owned by G.11)

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum; conditional on use):

  • BridgeId/BridgeCardId
  • RegressionSetId? / SentinelId[]? (as published by G.7, when sentinel wiring is used)
  • PathId[] | PathSliceId[] (paths that cite the bridge and must be re‑audited on bridge/sentinel changes)

• RSCRTriggerKindIds: {RSCRTriggerKindId.CrossingBundleEdit, RSCRTriggerKindId.PenaltyPolicyEdit, RSCRTriggerKindId.FreshnessOrDecayEvent, RSCRTriggerKindId.EditionPinChange, RSCRTriggerKindId.PolicyPinChange}

• Notes (wiring‑only): This module requires that bridge/sentinel changes re‑trigger RSCR path‑locally for affected PathId/PathSliceId scopes, without redefining sentinel semantics (owned by G.7) and without inventing new trigger kinds (owned by G.Core).

GPatternExtension: QD_OEE_TelemetryPins

• PatternScopeId: G.6:Ext.QD_OEE_TelemetryPins

• GPatternExtensionId: QD_OEE_TelemetryPins

• GPatternExtensionKind: MethodSpecific

• SemanticOwnerPatternId: C.18 (QD artefact semantics); uses C.19 for exploration/logging/lens wiring as needed

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum; conditional on use):

  • DescriptorMapRef.edition
  • DistanceDefRef.edition
  • InsertionPolicyRef (policy id or pinned policy ref, per owner semantics)
  • EmitterPolicyRef?
  • LensId? (when a C.19 lens is used in selection/telemetry attribution)
  • TransferRulesRef.edition? / EnvironmentValidityRegionRef? (when open‑ended / transfer events are in scope)

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

• Notes (wiring‑only): This module enforces reproducibility of archive/illumination and open‑ended telemetry when those surfaces are used, without pulling QD/OEE semantics into the EvidenceGraph core.

#Archetypal Grounding (System / Episteme)

System (Γ_sys): Autonomous brake envelope claim. Claim: “Stop within 50 m from 100 km/h.” EvidenceGraph nodes include proof carriers (TA/VA), instrumented track tests (LA/VA), calibration carriers, and an external test lab as an external evidencing role (no self‑evidence). A PathId provides a stable justification address; empirical legs are bound to explicit windows; crossings (if any) are explicit and pinned.

Episteme (Γ_epist): Benchmark parity/replication lineage (post‑2015 practice). Claim: “Method family M attains parity on ImageNet‑style tasks under a declared evaluation protocol.” EvidenceGraph nodes include replication carriers (LA), legality/metric‑soundness carriers (VA), and tool‑qualification carriers (TA). The cited PathId binds the ReferencePlane, the scope slice, and the pinned evaluation/legal surfaces (by edition/policy ids rather than prose). When refresh triggers occur (edition pin change, evidence surface edit, decay events), downstream artefacts can re‑cite or re‑compute using the same PathSliceId addressing discipline.

#Bias‑Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for the EvidenceGraph kit; any method‑specific telemetry/portfolio wiring is modularized as Extensions and cited to its semantic owners.

#Conformance Checklist (normative) — CC‑G6

#Interfaces & Hooks (normative)

Each hook below defines: Trigger → Obligation → Publishes/Consumes → Invariants. Where universal invariants apply (crossings, penalties, trigger typing), this section cites G.Core rather than redefining semantics.

#H1 — UTS Name Card for Evidence Artefacts

• Trigger. A new EvidenceGraph node is minted (an A.10‑anchored evidence artefact or role).
• Obligation. Mint a UTS Name Card with twin labels (Tech/Plain), citing the home context anchor and any required edition pins.
• Publishes/Consumes. Publishes: UTS row. Consumes: A.10 anchor metadata.
• Invariants. UTS publication and any deprecation/aliasing follow G.Core routing to F.17 (UTS discipline).

#H2 — UTS PathCard (PathId/PathSliceId)

• Trigger. A new PathId (or PathSliceId) is minted.
• Obligation. Publish a UTS PathCard with twin labels, listing the explicit pins required by §4.1 (context/plane/time binding, crossing pins if any). If an extension requires additional pins for reproducibility (e.g., G.6:Ext.QD_OEE_TelemetryPins), those pins MUST be present when the extension is in use.
• Publishes/Consumes. Publishes: UTS row(s). Consumes: EvidenceGraph path metadata + any extension‑required pins.
• Invariants. Crossing visibility and penalty routing are delegated to G.Core (CC‑GCORE‑CROSS‑1, CC‑GCORE‑PEN‑1).

#H3 — RSCR Trigger on Evidence‑Impacting Edit (typed; alias‑dockable)

• Trigger. Any edit in G.6 that can change a path’s audit‑relevant surface (evidence structure, crossing pins, penalty policy pins, plane binding, freshness binding, edition/policy pins, or telemetry‑bound fields).
• Obligation. Emit RSCR triggers using canonical RSCRTriggerKindId (from G.Core) and record affected scope (PathId/PathSliceId) plus payload pins required for downstream refresh. If a legacy G.6:H3:* label is recorded, it is recorded as an alias label and docked via G.Core.TriggerAliasMap.G6. When G.6:Ext.BridgeSentinelWiring is used, include the bridge/sentinel payload pins required by that extension.
• Publishes/Consumes. Publishes: RSCR triggers and any associated RSCR test ids. Consumes: relevant pins/refs and CAL artefact references where applicable.
• Invariants. Trigger typing and alias docking are delegated to G.Core (CC‑GCORE‑TRIG‑*). Penalty routing invariants are delegated (CC‑GCORE‑PEN‑1).

#H4 — SoS‑LOG Path Citation (selector explainability)

• Trigger. A SoS‑LOG rule yields a tri‑state decision for a selection‑relevant pair (e.g., (TaskSignature, MethodFamily)), and the decision is justified by evidence.
• Obligation. The branch record MUST cite the relevant PathId/PathSliceId(s) and the minimal pins required to re‑audit the justification. Any method‑specific attribution fields are handled via Extensions (e.g., G.6:Ext.SoSLOGPathCitationWiring for LensId/FailureBehavior wiring, G.6:Ext.BridgeSentinelWiring for bridge‑monitoring payload pins when cross‑context reuse is invoked, G.6:Ext.QD_OEE_TelemetryPins for QD/OEE pins).
• Publishes/Consumes. Publishes: an SCR‑visible branch record with cited paths. Consumes: EvidenceGraph path queries.
• Invariants. Tri‑state semantics are core‑owned (CC‑GCORE‑GUARD‑1); G.6 does not add a new decision value.

#H5 — Maturity Rung Transition Justification

• Trigger. A maturity rung transition is proposed and justified by evidence.
• Obligation. The transition MUST cite one or more PathId/PathSliceId(s) and MUST publish an updated maturity entry with those citations. Missing path citations forbid rung advance.
• Publishes/Consumes. Publishes: updated UTS entry for maturity artefacts. Consumes: cited paths and A.10 anchors.
• Invariants. Any thresholding policy remains owned by CAL/LOG owners; G.6 provides citation, not policy.

#H6 — Bridge/CL Edge Annotation (GateCrossings)

• Trigger. An EvidenceGraph edge traverses a declared GateCrossing boundary (context/kind/plane/design↔run/edition).
• Obligation. Publish a CrossingBundle‑checkable crossing record with explicit crossing pins (UTS row id, Bridge id/card id if applicable, CL regime pins if applicable, and plane pins if applicable).
• Publishes/Consumes. Publishes: crossing row/pins. Consumes: GateCrossing metadata and Bridge artefacts (when present).
• Invariants. Crossing visibility is core‑owned (CC‑GCORE‑CROSS‑1); penalties routing is core‑owned (CC‑GCORE‑PEN‑1).

#H7 — ReferencePlane penalty policy publication (ids only)

• Trigger. A path binds across different reference planes.
• Obligation. Publish the relevant policy identifiers (ids only; not tables) required to audit plane effects, alongside the path’s pins.
• Publishes/Consumes. Publishes: SCR/UTS fields containing policy ids. Consumes: the owner’s policy registries as cited artefacts (do not duplicate tables).
• Invariants. Penalty routing is delegated (CC‑GCORE‑PEN‑1); no shadow specs (CC‑GCORE‑CN‑CG‑1).

#H8 — CrossingBundle exposure (E.18)

• Trigger. G.6 artefacts are exported for release or consumed by downstream patterns that require GateCrossing checks.
• Obligation. Provide harness‑readable ids/pins so GateCrossing checks can verify: required crossing records exist, lexical constraints hold, and crossing pins are explicit.
• Publishes/Consumes. Publishes: checkable ids/pins. Consumes: GateCrossing + lexical rules.
• Invariants. Crossing discipline and ID continuity are core‑owned (CC‑GCORE‑CROSS‑1, CC‑GCORE‑ID‑*).

#H9 — SCR surface for assurance provenance

• Trigger. A downstream artefact cites a path for audit/selection/maturity.
• Obligation. Expose the required provenance fields in SCR views: lane split, context/plane pins, freshness binding, crossing pins (when present), and links to A.10 anchors and CAL refs.
• Publishes/Consumes. Publishes: SCR view(s). Consumes: EvidenceGraph paths and cited owner artefacts.
• Invariants. Default ownership is routed (CC‑GCORE‑DEF‑1) when defaults are cited.

#H10 — ProofLedger linkage (CAL ↔ G.6)

• Trigger. A proof obligation or evidence role is attached to a claim and is represented in G.4 artefacts.
• Obligation. Link EvidenceGraph nodes/edges to CAL ProofLedger/EvidenceProfiles entries and to A.10 carriers via the minimal provenance edge vocabulary.
• Publishes/Consumes. Publishes: CAL proof refs as pins in the path explanation surface. Consumes: CAL artefacts.
• Invariants. G.6 does not redefine CAL proof semantics; it only cites them.

#H11 — Telemetry ingest (selector & probe outcomes)

• Trigger. Run‑time outcomes (selection, probes, parity runs, measurement updates) produce observations that bear on previously asserted claims.
• Obligation. Ingest the observation as a run‑time evidence line (anchored in A.10), with explicit lane typing and explicit scope/time binding. If method‑specific telemetry pins are required, they are governed by Extensions (e.g., G.6:Ext.QD_OEE_TelemetryPins).
• Publishes/Consumes. Publishes: new EvidenceGraph nodes/edges + any required UTS rows + typed RSCR triggers when impacts occur. Consumes: run‑time carriers/attestations as conceptual anchors.
• Invariants. P2W split is respected (CC‑GCORE‑P2W‑1); typed trigger discipline is respected (CC‑GCORE‑TRIG‑*).

#Minimal conformance (hooks)

1. UTS publication for minted evidence artefacts and paths (H1–H2), per routed UTS discipline.
2. Typed RSCR triggers on evidence‑impacting edits (H3) using canonical trigger kind ids.
3. LOG and maturity artefacts cite paths when evidence is used (H4–H5).
4. GateCrossing/crossing records are explicit and checkable when crossings occur (H6–H8).
5. SCR views expose the minimal provenance pins for cited paths (H9–H10).
6. Run‑time telemetry is ingested without collapsing design↔run boundaries (H11).

#Common Anti-Patterns and How to Avoid Them

• Narrative‑only provenance (“because story”). Avoid: mint PathId/PathSliceId and require citation for any decision that claims evidence‑based justification (CC‑G6‑9).
• Implicit crossings (“same thing, different context”). Avoid: represent crossings only via explicit crossing artefacts/pins; treat edition/plane/context changes as explicit crossing‑relevant edits and trigger RSCR (core‑owned crossing discipline).
• Smuggling legality rules into EvidenceGraph prose. Avoid: cite/pin legality surfaces (CG‑Spec and CAL artefacts); do not introduce local “mini‑CG” rules in G.6 (route via CC‑GCORE‑CN‑CG‑1).
• Unpinned editions/policies (“it’s obvious which version”). Avoid: require explicit edition/policy pins on citable paths; treat changes as typed triggers.
• Alias‑only RSCR causes (“H3: something changed”). Avoid: record canonical RSCRTriggerKindId as the cause; aliases are labels only and must dock via G.Core.TriggerAliasMap.G6.

#Consequences

Benefits. Path‑addressable provenance; crossing/plane effects are auditable by pins rather than folklore; selectors and auditors share the same object; refresh becomes localized (path‑scoped) rather than global “rerun everything”. Trade‑offs. Authors must declare (or pin) time/plane/scope and keep pins explicit; mitigated by reusing CAL EvidenceProfiles and by modularizing method‑specific telemetry as Extensions.

#Rationale

G.6 concretizes the “because‑graph” implicit in A.10 into a typed, lane‑aware DAG with stable path addresses. It relies on canonical owners for semantics:

• A.10 for anchoring discipline and carrier reality,
• B.3 for the assurance skeleton,
• G.4 for proof/evidence profile semantics,
• G.Core for universal crossing, penalty, default ownership, and typed RSCR cause discipline.

This preserves conceptual modularity: G.6 standardizes addressable provenance, not a competing legality or selection mechanism.

#SoTA‑Echoing

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

• treating provenance and versioning/pinning as first‑class audit surfaces (rather than informal “methods” prose),
• enabling selective re‑evaluation (path‑scoped refresh) rather than global reruns whenever one policy/edition changes,
• separating design‑time specifications from run‑time traces/telemetry, matching modern reproducibility and “lineage” practice in complex ML/scientific pipelines,
• keeping method‑family specifics (e.g., archive/illumination/QD pins or open‑ended telemetry pins) modular via extension wiring instead of embedding them into the universal provenance core.

#Relations

Builds on: G.Core, A.10 (evidence anchors/carriers; SCR/RSCR), B.3 (assurance skeleton), F.9 (BridgeCard/CL), G.4 (CAL EvidenceProfiles/ProofLedger), E.18/A.21 (GateCrossing/CrossingBundle checks), E.10 (lexical rules), E.5.* (notation independence), F.17 (UTS), F.15 (RSCR). Publishes to: UTS (Name Cards + PathCards), SCR/RSCR surfaces, downstream selectors/LOG by PathId citation, refresh/orchestration as typed triggers (consumed by G.11 when used). Used by: G.5 (selector explainability and admissibility justifications), G.8 (SoS‑LOG bundles), G.9 (parity harness traces), G.10 (shipping pins and audit payload), G.11 (refresh orchestration). Constrains: downstream patterns MUST cite paths when evidence is claimed; they MUST treat edits to pinned evidence/crossing/policy/edition/time bindings as refresh‑relevant causes with canonical trigger ids (routing via G.Core).

#G.6:End