Part G - Discipline SoTA Patterns Kit

G.Core - Discipline SoTA Kit Invariants, Defaults and Refresh Triggers (Part G)

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

Normativity. Normative unless explicitly marked informative

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

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

G.Core:1 - Problem frame

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

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

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

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

G.Core:2 - Problem

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

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

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

G.Core:3 - Forces

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

G.Core:4 - Solution

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

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

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

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

Delegation table (normative index; no semantic duplication).

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

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

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

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

• Relations: Builds on: G.Core.

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

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

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

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

G.Core:4.2.1 - GCoreLinkageManifest (canonical shape)

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

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

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

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

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

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

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

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

CrossingVisibilityPins activation. Recover the relation and receiving use before expanding its applicable pins:

When more than one channel is used, retain every channel’s independently required basis. A no-crossing use has no crossing pins; a same-kind new entity or changed source edition alone creates no Bridge. The conditional marks permit omission only for an inactive condition, not omission of a reference required by a real calibration, assurance or gate claim.

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

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

G.Core:4.3.1 - Definitions

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

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

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

• RSCRTrigger Minimal conceptual form (notation-independent):

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

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

G.Core:4.3.2 - Governing-definition model

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

G.Core:4.3.3 - Authoring rules

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

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

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

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

G.Core:4.3.4 - Canonical trigger catalogue

Use these canonical kinds to classify refresh causes and to interpret the deprecated G.6:H3 and G.11:T0…T7 aliases used across G.0…G.13:

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

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

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

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

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

G.Core:4.3.5 - Initial alias maps

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

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

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

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

TriggerAliasMap.G6 EvidenceGraph H3 example causes → canonical kinds:

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

G.Core:4.4 - Default Governing Definition Index

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

G.Core:4.4.1 - Definitions

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

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

G.Core:4.4.2 - Rules

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

G.Core:4.4.3 - Default governing definitions

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

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

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

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

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

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

G.Core:4.6 - Explicit non-goals

G.Core does not:

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

G.Core:5 - Archetypal grounding

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

G.Core:9 - Consequences

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

G.Core:10 - Rationale

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

G.Core:11 - SoTA alignment (informative)

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

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

G.Core:12 - Relations

• Builds on:

  • E.8 pattern template and section discipline
  • E.10 lexical/ontological rules (strict distinction; twin naming; kind‑suffix discipline)
  • E.18 CrossingBundle (crossing visibility bundle)
  • E.19 conformance discipline
  • A.6.7 SuiteObligations + suite protocol pins (delegation support)
  • A.15.2 WorkPlan content for the edition/reference baseline; A.15.3 only for applicable typed planned fillings
  • A.19.CN 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 static and regression conformance checks for unification slices

• Used by:

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

• Constrains:

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

G.Core:End

G.0 - Define Admissible Comparison and Aggregation for a Frame (CG-Spec)

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

G.0:1 - Problem frame

A team defines or evolves a CG‑Frame (e.g., a frame for creativity measurement, decision quality, architecture trade‑offs, or selected-set publication). Downstream comparison, aggregation, and publication of CHR‑typed observations (G.1–G.5 and beyond) must be:

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

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

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

G.0:2 - 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.

G.0:3 - Forces

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

G.0:4 - Solution — CG‑Spec as the design-time legality gate

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

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

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

G.0:4.1 - G.Core linkage (normative)

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

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

Effective obligations/pins/triggers are computed by union expansion of the referenced ids (per G.Core:4.2). Profiles/sets + explicit deltas; Nil‑elision applies.

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

G.0:4.2 - CG‑Spec object model (normative)

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

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

G.0:4.3 - CG‑Spec conceptual model (normative)

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

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

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

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

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

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

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

  Γ‑fold := ⟨GammaFoldId, ΓFoldRef.edition?,   // pin the actual model/policy when a numerical fold is used
             defaultRef := DefaultId.GammaFoldForR_eff,
             override? := ⟨overrideRef, proof_refs, boundary_notes⟩
           ⟩,

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

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

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

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

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

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

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

G.0:4.4 - Interfaces (normative)

G.0:4.5 - CG‑Spec authoring chassis (informative)

1. Charter the frame. Declare Context, Scope, entityOfConcern, boundary examples/non-examples, and ReferenceMap.
2. Draft ComparatorSet and SCP. Enumerate permitted comparator forms and bind each to CHR characteristics and legality constraints (scale/unit/polarity discipline). Attach guard bindings as explicit references/pins.
3. Bind Characteristics. For every comparison, identify the CHR characteristics of the quantities being compared and cite them by 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 the support-composition basis. Cite DefaultId.GammaFoldForR_eff for the model-qualified rule. A numerical fold or loss pins its actual receiving model, compatible inputs, dependency assumptions, and justification refs; monotonicity and boundedness alone are insufficient. When no common aggregate is justified, the referenced rule retains separate support and a bounded synthesis. Publish any actually used Φ/CL policy ids; keep acceptance thresholds in G.4.
6. Publish and register regression tests. Publish CG‑Spec@UTS with edition-pinned segments; register RSCR tests for the frame’s legality surfaces and evidence minima.
7. Public-id continuity and refresh readiness. Declare refresh cadence and deprecations with lexical continuity notes; ensure RSCR trigger kinds are emitted as canonical ids.

G.0:4.6 - Extensions (pattern-scoped; non-core)

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

GPatternExtension: SpecRefSurfaces

• PatternScopeId: G.0:Ext.SpecRefSurfaces

• GPatternExtensionId: SpecRefSurfaces

• GPatternExtensionKind: InteropSpecific

• GoverningPatternId: A.19.CN

• Uses: {A.19.CN}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

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

GPatternExtension: BridgeAndCLWiring

• PatternScopeId: G.0:Ext.BridgeAndCLWiring

• GPatternExtensionId: BridgeAndCLWiring

• GPatternExtensionKind: InteropSpecific

• GoverningPatternId: F.9

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

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

GPatternExtension: SoTAPaletteInputs

• PatternScopeId: G.0:Ext.SoTAPaletteInputs

• GPatternExtensionId: SoTAPaletteInputs

• GPatternExtensionKind: DisciplineSpecific

• GoverningPatternId: G.2

• Uses: {G.2}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

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

GPatternExtension: QDAndExplorationHooks

• PatternScopeId: G.0:Ext.QDAndExplorationHooks

• GPatternExtensionId: QDAndExplorationHooks

• GPatternExtensionKind: MethodSpecific

• GoverningPatternId: C.18

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

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

G.0:5 - Archetypal Grounding — Tell–Show–Show; System / Episteme

G.0:5.1 - Archetype 1: System comparability under mixed evidence and unit constraints

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

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

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

• pins the lawful comparator(s) (e.g., unit-aligned ratio comparisons only; ordinal comparisons are order-only),
• declares MinimalEvidence lanes/carriers and freshness windows per characteristic,
• declares explicit failure behavior wiring (tri-state semantics delegated to G.Core),
• exposes Bridge and bounded-use pins when reuse projects between different local meanings under A.19.CN/F.9; unit conversion within the declared comparison basis follows CN-Spec and SCP,
• publishes the pinned editions so parity/refresh can detect drift.

G.0:5.2 - Archetype 2: Epistemic comparability for selected-set publication across traditions

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

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

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

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

G.0:6 - Bias-Annotation

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

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

G.0:7 - Conformance Checklist (normative)

G.0:8 - 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.

G.0:9 - 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.

G.0:10 - Rationale

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

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

G.0:11 - SoTA‑Echoing

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

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

G.0:12 - Relations

Builds on: G.Core, A.19.CN (CN‑Spec), A.10 (evidence-provenance account), 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

G.1 - Author a Reusable CG-Frame Generator and Selector Kit

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

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

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

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

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

G.1:1 - Problem frame

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

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

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

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

G.1:2 - 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.

G.1:3 - 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.

G.1:4 - Solution

G.1:4.1 - G.Core linkage (normative)

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

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

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

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

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

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

    // For a planned baseline, identify the A.15.2 WorkPlan and local locator; add declaration ref, member designator and plan-local filling-row locator when A.15.3 applies.
    WorkPlanRef[]?
  },

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

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

G.1:4.2 - Six‑module generator chassis (normative)

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

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

G.1:4.2.1 - M1 — CG‑FrameContext Card (scope anchor)

Governs (kit surface):

• CG‑FrameContext and its binding pins:

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

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

Notes: any spec-legality content is cited via A.19.CN (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”.

G.1:4.2.2 - M2 — SoTA_Set@CG‑Frame (harvester output card)

Governs (kit surface):

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

Governing pattern: harvesting discipline and SoTA-pack payload are governed by G.2. In G.1, M2 is a card in the chassis and a wiring surface; it does not redefine the harvesting method. A relied-on coverage result cites G.2’s CoverageJudgementRef with its HarvestPolicy basis, counted units and receiving question. M2 supplies no alternative family count.

G.1:4.2.3 - M3 — VariantPool (candidate inventory + emitter trace)

Governs (kit surface):

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

Guardrails (via G.Core):

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

Governing pattern for method payload: method‑specific emitter semantics remain in their governing definitions, cited through Extensions (e.g., the relevant C.17, C.18, and C.19 definitions). M3 MUST remain method‑agnostic in its core definition: it is an inventory surface, not an algorithm spec.

G.1:4.2.4 - M4 — Shortlist (selector output)

Governs (kit surface):

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

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

G.1:4.2.5 - M5 — CG‑FrameLibrary (published bindings index)

Governs (kit surface):

• CGFrameLibraryId bound to CG‑FrameContext

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

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

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

G.1:4.2.6 - M6 — RefreshReadiness Card (telemetry hooks + wiring)

Governs (kit surface):

• RefreshReadinessCardId bound to CGFrameLibraryId (and thus to CG‑FrameContext)
• CGKitId (the versioned kit manifest) binding M1…M6 into a single reusable unit; it MUST enumerate the card ids and MAY carry references to deprecations/edition bumps minted by the canonical governing definitions
• declared telemetry hooks (what signals are observed, with what pins)
• declared RSCR wiring: which RSCRTriggerKindId are relevant (canonical ids), with minimal required payload pins. For a planned baseline, include the A.15.2 WorkPlan reference and its local baseline locator; filling an independently declared position under A.15.3 also requires the governing declaration reference, member designator and plan-local filling-row locator.

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

G.1:4.3 - Minimal I/O surface (normative)

G.1:4.4 - 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.

G.1:4.4.1 - GPatternExtension — G.1:Ext.HarvesterWiring

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

• SoTAPaletteDescriptionId
• SoTA_SetId
• CoverageJudgementRef and its HarvestPolicyRef when coverage is consumed
• 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.

G.1:4.4.2 - GPatternExtension — G.1:Ext.ShortlistWiring

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

RequiredPins/EditionPins/PolicyPins (minimum):

• ShortlistId
• SCRId (selector audit reference under G.5; its record carries assurance only when an actual named assurance claim is current under B.3)
• DRRId? (when a decision‑rationale artefact is minted; otherwise omitted)
• TaskSignatureRef? (if selection is task‑templated; otherwise omitted)
• AcceptanceClauseId[] (as referenced from G.4 outputs)
• any explicit selector policy pins (policy‑id/ref; defined by the governing pattern) when not defaulted (the omitted default cites its governing definition through G.Core.DefaultGoverningDefinitionIndex)

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

G.1:4.4.3 - GPatternExtension — G.1:Ext.CreativityCHR

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

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

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

G.1:4.4.4 - GPatternExtension — G.1:Ext.NQD

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

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

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

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

G.1:4.4.5 - GPatternExtension — G.1:Ext.OpenEndedFamilyWiring

PatternScopeId: G.1:Ext.OpenEndedFamilyWiring GPatternExtensionId: OpenEndedFamilyWiring GPatternExtensionKind: GeneratorSpecific GoverningPatternId: G.2 (family semantics are governed by SoTA cards; this block only wires pins; selector-side wiring is governed by G.5.) Uses: {G.2, G.5, C.19, C.23} ⊑/⊑⁺: ∅ RequiredPins/EditionPins/PolicyPins (minimum):

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

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

Notes (wiring‑only): this block enables declared sets of {Environment, MethodFamily} pairs without redefining generator semantics in G.1; it should cite/align with the selector‑side wiring in G.5:Ext.OpenEndedFamilyWiring.

G.1:4.4.6 - GPatternExtension — G.1:Ext.RefreshWiring

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

• RefreshReadinessCardId
• RSCRTestId[]
• canonical RSCRTriggerKindId[] emitted/recorded (aliases only as labels, if any)

RSCRTriggerSetIds: {GCoreTriggerSetId.RefreshOrchestration} Notes (wiring‑only): M6 declares readiness and wiring; orchestration semantics (queueing, prioritisation, cadence) are governed by G.11.

G.1:4.4.7 - GPatternExtension — G.1:Ext.ShippingWiring

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

• CGFrameLibraryId
• SoTAPaletteDescriptionId, SoTA_SetId
• CHRPackId?, CALPackId?, SoS‑LOGBundleId?, ParityReportId? (as present in the library index)
• EvidenceGraphId?, BridgeMatrixId?, BridgeCalibrationTableId? (when cited by the shipped artefacts)
• UTSRowId[]? (when any public ids are minted/published)
• WorkPlanRef[]? with local baseline locators (when a planned baseline is cited by the shipment surface under A.15.2); include the governing declaration reference, member designator and plan-local filling-row locator when A.15.3 applies

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.

G.1:5 - Archetypal Grounding — Tell–Show–Show (informative)

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

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

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

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

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

G.1:6 - Bias‑Annotation (informative)

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

G.1:7 - Conformance Checklist (normative)

G.1:8 - Common Anti‑Patterns and How to Avoid Them (informative)

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

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

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

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

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

G.1:9 - 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-wiring changes localise to Extensions; core invariants remain stable under their governing definitions.

G.1:10 - Rationale (informative)

• Why six cards? It matches the minimal decomposition needed to keep scope, harvesting, generation, selection, publication, and refresh explicitly separable (and thus auditable and evolvable).
• Why “kit/index” rather than “pack”? A CG‑Frame authoring effort must stay modular; shipping is a separate governing boundary (G.10).
• Why put method-specific wiring into Extensions? It prevents conflating (i) universal invariants, (ii) frame‑specific kit surfaces, and (iii) method/generator families.
• 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.

G.1:11 - SoTA‑Echoing (informative)

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

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

G.1:12 - Relations

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

G.1:End

G.2 - Harvest and Synthesize SoTA for a CG-Frame

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.

Start here. Write the question the receiving CHR, CAL or selector work must answer. Before counting coverage, fix the source population and what counts as the same family. Distill the first source claims with their editions, evidence and limits, keeping competing lineages separate. The first useful result is a claim set that can answer part of that question and expose what is still missing. Use the manifest below when developing it into a conforming synthesis pack; a single-source fact lookup can return its source directly without creating such a pack. The primary output is a SoTA Synthesis Pack@CG‑Frame that feeds:

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

Scope note. This pattern governs the harvesting + synthesis generator in Part G. Use G.10 to ship the pack and G.11 to orchestrate refresh.

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.

G.2:1 - Problem frame

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

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

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

G.2:2 - Problem

How can we systematically assemble a SoTA view that is:

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

G.2:3 - 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 governs authoring; use the applicable Work and decision patterns for operational runs and decisions.

G.2:4 - Solution

G.2:4.1 - G.Core linkage (normative)

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

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

GCoreLinkageManifest := ⟨
  CoreConformanceProfileIds := {
    GCoreConformanceProfileId.PartG.AuthoringBase,
    GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted
  },
  RSCRTriggerSetIds := {GCoreTriggerSetId.SoTAHarvestSynthesis},
  CorePinSetIds := {GCorePinSetId.PartG.CrossingVisibilityPins}, // expands only for actual channel/receiving-use conditions under G.Core:4.2.3; no crossing means no crossing pins

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

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

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

    // Edition / policy pins (only when used)
    HarvestPolicyRef?, // required when a coverage judgement is made
    CoverageJudgementRef?, // the pack judgement, required for a relied-on coverage result
    DistanceDefRef.edition?,
    InclusionCriteriaId?,
    ScreeningRubricId?
  },

  DefaultsConsumed := ∅,
  TriggerAliasMapRef := ∅
⟩

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

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

FamilyCoverageFloorK := 3 (unless explicitly overridden by HarvestPolicyRef and recorded in FlowRecord). This threshold supplies no counted population or same-family rule; those must be explicit before a coverage judgement. An undefined basis is unassessable, not a measured failure. Whenever coverage is judged, HarvestPolicyRef is required even when k uses this fallback; its applicability, receiving question, counted population/scope, grouping and same-family equivalence must be fixed before counting. An override changes k, not the unit or the independent pluralism duties.

Counted-family basis. The HarvestPolicy defines which candidates enter the counted population and when two entries represent the same family for this receiving question. Count equivalence classes under that rule. Repeated cards, aliases and source references for one family add zero. A combined method/generator population needs one receiving purpose and an overlap rule: a generator that is also a method is not counted twice unless the policy deliberately defines separate role-qualified units and justifies that interpretation. Freeze this basis before inspecting the count; changing it to turn a failure into three is not a repair of coverage.

The pack’s coverage judgement carries the policy/edition, counted units, deduplication basis, count, k and pass/fail result, or the exact missing basis when unassessable. Give this existing pack component a local CoverageJudgementRef for citation. Evaluate lineage and materially distinct entry plurality separately. Cards and downstream consumers cite this same judgement instead of choosing their own unit. Compare counts across packs only when their bases match, or after an explicitly justified common-basis recount.

G.2:4.2 - Kit: SoTA Synthesis Pack@CG‑Frame (surface governed by this pattern)

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

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

0. SoTA_Set@CG‑Frame (export view; “M2 output” consumed downstream) A read‑optimised view over the harvested candidate set that downstream generator/selector work treats as the “harvester output set”. Constraint (normative): SoTA_Set@CG‑Frame MUST be reconstructible from pack components by id (no “hidden extra set”). Its coverage result cites the pack’s CoverageJudgementRef, including its fixed HarvestPolicy basis; the export view does not redefine family membership.

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

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

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

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

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

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

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

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

8. G.2h PRISMA Flow Record A screening/eligibility trail for how sources entered the pack (method‑profile is allowed; see Extensions). (Name is historical; the artefact remains notation‑independent.) The pack coverage judgement and its policy basis are recoverable here, separately from the lineage and material-entry pluralism results.

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

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

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

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

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

• the SoTA_Set@CG‑Frame view,
• ClaimSheetId[], OperatorAndObjectInventory, BridgeMatrixId?,
• SoSIndicatorFamilies (with variant/branch structure),
• MethodFamilyCards / GeneratorFamilyCards?,
• MicroExamples, UTSProposals,
• and the entityOfConcern Map for citation and later CHR/CAL authoring.

Note (normative intent): this is the primary “consumable surface” for G.3/G.4/G.5; it prevents downstream patterns from scraping free prose.

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

G.2:4.3 - Harvester loop (conceptual choreography; pattern-governed)

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

1. Declare scope and plurality. Identify the exact CG-frame (the declared framing episteme), the initial Tradition set, each intended claim region and EntityOfConcern, the comparison basis, and the receiving use. Record the cited CG-frame and source editions and evidence anchors in the pack pins rather than hiding them in a generic context field. Before counting, fix the HarvestPolicy’s receiving question, counted population, grouping and same-family equivalence, including overlap handling for a combined population.

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

   • adding 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, record the obtaining correspondence and its exact basis in BridgeMatrix: F.9 for sense correspondence, C.3.3 for kind correspondence, or the direct rule for a plane relation, as actually used. State preserved distinctions and losses for the receiving question. Consolidation requires explicit alignment proof. Add bundle or gate anchors only for an independently applicable E.18 flow crossing or A.21 gate, under CC‑GCORE‑CROSS‑1.

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

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

8. Apply gates and record repairs. Apply that fixed HarvestPolicy basis and count its distinct units before comparing coverage with FamilyCoverageFloorK (and apply any optional diversity-by-distance gate under its own basis). Missing count semantics returns an unassessable result and the exact missing basis, not an instruction to search more. If a defined 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. Each relied-on coverage result carries the same CoverageJudgementRef and its policy basis; a downstream method-selection use cannot treat a combined method/generator count as a method-only count. The pack MUST also export SoTA_Set@CG‑Frame and SoTAPaletteDescription as the default downstream consumption surfaces (ids pinned).

G.2:4.4 - Interfaces (minimal I/O Standard)

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

G.2:4.5 - Extensions (pattern‑scoped; non‑core)

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

G.2:4.5.1 - GPatternExtension: GammaEpistSynthesis

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

• GammaEpistSynthId[] (pack‑local ids of synthesis records; emitted iff fusion/substitution is asserted)
• EvidenceAnchorRef[] (provenance union; evidence carriers cited by A.10 evidence-provenance paths)
• BridgeMatrixId and BridgeCardId[] (explicit object alignment references when crossing is involved)
• CL/CL^plane and Φ/Ψ/Φ_plane policy-ids when required by the cited crossing or actually used loss model (semantics and penalties → R_eff remain governed by the cited definitions)
• 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):

• The auditable synthesis record identified by GammaEpistSynthId binds: (i) provenance union, (ii) explicit object alignment refs, (iii) assurance tuple refs (via their governing definitions) for each asserted fusion/substitution. A B.1.3 Γ_epist^synth application and its returned episteme remain separate from this record.
• This extension cites the Γ‑fold, Φ, and penalty rules through G.Core and exposes the pins needed for replay. When B.3/C.2.2 supplies no justified common numerical score or loss calculation, retain the separate support, actual mapping limitations and bounded assurance conclusion; a synthesis record does not supply the missing model.

G.2:4.5.2 - GPatternExtension: HarvestProtocols

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

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

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

Notes (extension discipline):

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

G.2:4.5.3 - GPatternExtension: DHCAlignmentHooks

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

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

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

Notes (extension discipline):

• If DHC alignment summaries are emitted, this extension ensures the DHC method edition and the cited evidence paths are visible.
• AlignmentDensity uses C.21’s Unit obtaining_relations/100_compared_cells: fix the exact compared F.17 cell set and count the exact obtaining directed F.9 relations, retaining each relation’s orientation and admitted-use qualifier. Keep observed loss in its evidence account. A CL calibration label does not include or exclude a relation by itself. Any independently justified receiving-use filter must name its own policy and resulting population; it is not a C.21 CL threshold.
• For example, three obtaining directed relations in a fixed set of 100 compared cells give a density of 3 in that Unit. Changing a CL label while relation truth, population and admitted-use qualifier remain fixed leaves the density 3. A fourth calibration row labelled CL=2 with no obtaining relation adds nothing. If a use condition actually changes which relations qualify, restate that changed population before comparing densities.

G.2:4.5.4 - GPatternExtension: NQDAnnex

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

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

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

Notes (extension discipline):

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

G.2:4.5.5 - GPatternExtension: InteropForms

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

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

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

Notes (extension discipline):

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

G.2:4.6 - Palette first

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

G.2:4.7 - Optional atlas interpretation of a declared palette

Use TraditionAtlasView only when the reader needs several derived views or interpretive qualifiers together to understand a grouping, omission risk or comparison boundary. Otherwise use the palette and its declared front, archive or shortlist, or the thinner DeclaredSubstrateInterpretiveView. A naming-only question belongs to F.18.

TraditionAtlasView specializes DeclaredSubstrateAtlasView under A.19.DECLARED-SUBSTRATE-INTERPRETIVE-VIEW and retains that declaration by value: the base palette, active source set or result, TypedSetViews when several declared views are combined, the space/map references and interpretive qualifiers actually used, and the reason the thinner view is insufficient. Cite SearchSpaceRef or OutcomeSpaceRef for the corresponding declared spaces. Add SpaceMetricRef, TransitionRelationRef and BridgeDistortionNote only for the comparison, reachability, transition or cross-scale claim that needs them. An OutcomeMapRef identifies a mapping from the stated result into an outcome/effect space; it does not turn the palette or result into that space. Their formal claims retain their own governing definitions.

If the interpretation changes the base source-to-outcome relation or its distortion, reopen the substrate declaration. Different atlas views may use different spaces, metrics, relations or mathematical traditions; one view does not settle those choices for every other view.

G.2:5 - Archetypal Grounding (System / Episteme)

G.2:5.1 - Count one pack under a declared basis

Consider this illustrative control-stack pack, extending the System case above. These are stipulated source entries for a counting example, not a finding that a real corpus has adequate breadth.

For the question “which control-method families can be selected?”, policy P-method counts method families only and equates entries exactly when they name the same declared method-family unit. The classes are {e1,e2} and {e3}: count 2, below k=3. Additional cards for e1 or citations for M-R leave the count at 2.

For the different question “which method and scenario-generator families can support building and evaluating this control stack?”, policy P-combined includes the three declared units M-R, M-L and G-S. Its overlap rule merges repeated references to one unit; these three units are stipulated distinct and G-S is not also M-R or M-L. Count 3 meets k=3 for that receiving purpose. This is not a passing method-only judgement and cannot be substituted after P-method fails. If one generator also qualified as a counted method, the overlap rule would have to resolve it before the count.

Four claim regions remain four material entries. The example independently has three lineages, so its two-lineage and three-material-entry pluralism duties pass under the stated facts in both policies. With no counted-family basis, family coverage is unassessable even though that pluralism result remains available. A justified k=2 override for P-method changes its threshold result while leaving its count at 2 and those independent duties unchanged.

G.1 M2 and the G.3–G.5 consumers cite the chosen pack judgement with its purpose and policy; they do not reconstruct a more convenient count from the cards.

G.2:6 - Bias-Annotation (informative)

Bias lenses: Gov, Arch, Onto/Epist, Prag, Did. Scope: harvesting and synthesis for a CG‑Frame.

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

G.2:7 - Conformance Checklist (normative) — CC‑G2

G.2:8 - Common Anti‑Patterns and How to Avoid Them

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

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

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

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

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

G.2:9 - 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”.

G.2:10 - 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.

G.2:11 - SoTA-Echoing — keep a reusable synthesis current without restarting it

Practice question. How should several downstream authors reuse a synthesis when new sources can change a consequential, unsettled comparison? The selected line keeps a question-bound source ledger, separable claims and explicit update causes; a living protocol is chosen when continuing evidence surveillance is worth its cost. A serious alternative is a well-reported static review with an explicit search date and a separately commissioned update. That alternative is sufficient for a stable question or a one-time decision and avoids maintaining a continuing review service.

The Cochrane Handbook, Chapter 22, §§22.2.3–4 supplies the conditional living-review line and its resource trade-off: priority, uncertainty and likely new evidence can justify frequent updates, while additional searching needs resources. Adapt this conditional choice in HarvestProtocols; declare the search/update policy rather than treating every G.2 pack as perpetually living. The clinical-review guidance does not establish coverage or evidence adequacy for an arbitrary engineering CG-frame.

The PRISMA 2020 reporting guidance supplies the substantive static-review comparator and a shared reporting basis. Its explanation of study selection distinguishes records, reports and included studies. Adapt the distinction to CorpusLedger, FlowRecord and the declared family units in §4.3: multiple source entries can concern one counted family. Reject treating a publication count or a completed flow diagram as proof of adequate family coverage. G.2’s k threshold, lineage duties and FPF alignment rules remain local decisions, not PRISMA requirements.

The 2024 PRISMA-LSR extension supplies the more specific reporting line for an actually selected living protocol: justify that mode, identify the version’s trigger and changes, and plan when to retire it. Adapt that distinction to the policy pins, change causes and downstream handoffs in §4.3 and G.2-2 Extend; G.11 governs refresh orchestration. Source reporting guidance does not supply an automatic update schedule or establish that a newly added claim is sound.

The control-stack case in §5.1 makes the improvement concrete. If e1’s operating-envelope claim is revised, the existing ledger identifies M-R and its consumers; re-examine that claim and the comparisons that depend on it. The new report does not add a family. The method-only count remains 2 until a distinct admitted method-family unit is found. A static review can also be updated correctly, but each separate consumer must recover the changed basis unless a shared update is published. For the same new source and receiving question, the selected pack reuses existing screening and claim relations; its added maintenance burden is justified only while repeated shared use and consequential change make that work useful.

Reopen the choice of protocol when the evidence rate, decision importance, uncertainty or maintenance resources change; retire living surveillance when its reason no longer holds. Reopen an individual synthesis when a new source changes a relied-on claim, coverage judgement or alignment. A source with a new date but no relevant content change does not by itself warrant reconstructing every downstream conclusion.

G.2:12 - Relations

• Builds on:

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

• Used by:

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

• Relates to:

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

G.2:End

G.3 - CHR Authoring for a CG‑Frame: Characteristics, Scales, Levels, Coordinates

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

G.3:1 - 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 an admissibility-ready CHR publication that makes downstream work possible without hidden semantic drift:

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

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

G.3:2 - Problem

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

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

G.3:3 - Forces

G.3:4 - Solution — CHR authoring kit and publication surface

G.3:4.1 - G.Core linkage (normative)

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

GCoreLinkageManifest (normative; size‑controlled).

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

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

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

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

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

G.3:4.2 - Output surface: CHR Pack@CG‑Frame (normative)

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

Minimum exported objects (kit surface):

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

Mandatory provenance pins (conceptual, notation‑independent):

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

G.3:4.3 - CHR authoring chassis (S1–S8)

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

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

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

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

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

Polarity gives the preferred direction for IntendedDownstreamUse: ↑ means higher-is-better, ↓ lower-is-better, and ⊥ no preferred direction assigned. Use ⊥ for a descriptive measurement. A target, range or other preference that has no single direction uses the applicable evaluation predicate and its Method; the Scale retains its measurement meaning under A.17/A.18.

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

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

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

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

Typical distinctions that must be representable:

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

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

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

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

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

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

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

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

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

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

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

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

G.3:4.4 - Interfaces (normative)

G.3:4.5 - Extensions (pattern‑scoped; non‑core)

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

GPatternExtension: SuiteBoundaryLinkage

• PatternScopeId: G.3:Ext.SuiteBoundaryLinkage

• GPatternExtensionId: SuiteBoundaryLinkage

• GPatternExtensionKind: InteropSpecific

• GoverningPatternId: A.19.CHR

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • CHRMechanismSuiteDescriptionRef.edition? (when the suite description is cited as a reproducibility baseline)
  • WorkPlanRef and local baseline locator (when a planned baseline binds CHR artefacts into WorkPlanning under A.15.2)
  • CHRMechanismSuiteSlotFillingsPlanItem in that WorkPlan (when the plan fills an independently declared operation argument or relation position under A.15.3; cite the governing declaration and member designator, and locate the filling row within the plan)

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

• Notes (wiring-only): A.19.CHR governs suite semantics and membership; A.19.CHR:4.1.2 distinguishes ordinary planned baselines from typed filling.

GPatternExtension: SoTAPackInputs

• PatternScopeId: G.3:Ext.SoTAPackInputs

• GPatternExtensionId: SoTAPackInputs

• GPatternExtensionKind: DisciplineSpecific

• GoverningPatternId: G.2

• Uses: {G.2}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

• Notes (wiring‑only): SoTA pluralism inputs are governed by G.2; this module only specifies which synthesis artefacts are cited while authoring CHR. When CHR authoring relies on pack coverage, cite the same CoverageJudgementRef and HarvestPolicy basis, retaining the counted population and receiving question. CHR terms or cards do not redefine the counted family unit; lineage plurality remains a separate result.

GPatternExtension: CGSpecPromotionWiring

• PatternScopeId: G.3:Ext.CGSpecPromotionWiring

• GPatternExtensionId: CGSpecPromotionWiring

• GPatternExtensionKind: InteropSpecific

• GoverningPatternId: G.0

• Uses: {G.0}

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

• Notes (wiring‑only): G.0 governs promotion semantics and the legality gate; CHR only pins and cites.

GPatternExtension: MMCHRLegalityWiring

• PatternScopeId: G.3:Ext.MMCHRLegalityWiring

• GPatternExtensionId: MMCHRLegalityWiring

• GPatternExtensionKind: DisciplineSpecific

• GoverningPatternId: A.18

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

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

GPatternExtension: DecayWiring

• PatternScopeId: G.3:Ext.DecayWiring

• GPatternExtensionId: DecayWiring

• GPatternExtensionKind: DisciplineSpecific

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

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

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

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

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

GPatternExtension: QD_OEE_Wiring

• PatternScopeId: G.3:Ext.QD_OEE_Wiring

• GPatternExtensionId: QD_OEE_Wiring

• GPatternExtensionKind: MethodSpecific

• GoverningPatternId: C.18

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

• ⊑/⊑⁺: ∅

• RequiredPins/EditionPins/PolicyPins (minimum):

  • DescriptorMapRef.edition (if any Characteristic declares descriptor roles)
  • DistanceDefRef.edition (if any Characteristic declares distance roles)
  • DHCMethodRef.edition? (when a C.21 discipline-health measurement definition is actually used; a Q / QD-score role alone does not select it)
  • InsertionPolicyRef? (when archive insertion semantics are declared for reproducibility)

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

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

G.3:5 - 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, with deployment population and sampling regime recorded separately as scope and protocol conditions,
• ObservableOf (audit protocol + uncertainty model + window),
• interval scale (bounded; zero semantics explicit),
• missingness semantics (cohort sparsity and label noise are typed),
• legality surfaces and guard surfaces that forbid illicit cohort mixing and require explicit proof hooks for aggregation across cohorts.

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

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

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

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

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

G.3:6 - 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 change in the sampling regime or protocol can change the interpretation or validity of a reported characteristic value, or change the characteristic’s meaning when that regime or protocol is part of its definition. Mitigation: explicit validity windows and freshness/decay expectations; edition pins for protocol definitions; RSCR triggers on freshness/decay events and evidence surface edits.
• Ordinal misuse bias: ordinal ratings treated as interval/ratio by convenience. Mitigation: publish scale type + admissible transforms; legality matrix + guard macros; reject coordinate upgrades without proof hooks.
• Cross-tradition meaning bias: an imported expression erases its source-local meaning or makes a changed bearer, scope, window, reference plane, evidence basis, or intended use disappear. Mitigation: name those values, cite exact F.17 cells and an F.9 relation only when it obtains, and keep any downstream bounded-use claim explicit under C.2.1 and F.9, with evidence-bearing reliance governed by A.10 and any applicable B.3 assurance requirement. Loss remains visible through the applicable G.Core penalty rule rather than silently altering Part F or Part G semantics.
• Metric gaming bias (QD and evaluation): changing descriptors/distances changes what “diverse” means. Mitigation: edition‑pin metric definitions and make role declarations explicit (wiring via C.18 and C.19).

G.3:7 - Conformance Checklist (normative)

G.3:8 - Common Anti‑Patterns and How to Avoid Them

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

G.3:9 - 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.

G.3:10 - Rationale

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

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

G.3:11 - SoTA‑Echoing

This pattern aligns with post‑2015 best practice by:

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

G.3:12 - Relations

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

G.3:End

G.4 - CAL Authoring for a CG-Frame: Operators, Acceptance Clauses, Evidence Wiring

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

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

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

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

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

G.4:1 - Problem frame

CAL authoring starts from:

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

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

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

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

G.4:2 - Problem

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

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

G.4:3 - Forces

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

G.4:4 - Solution — author the smallest lawful CAL pack

G.4:4.0 - Practitioner authoring path C1–C9

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

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

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

G.4:4.1 - G.Core linkage (normative)

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

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

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

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

CorePinsRequired := {
UTSRowId[],                 // CAL artefacts are public ids (Name Cards plus public-id continuity notes)
ΓFoldRef.edition?            // pin an actual numerical composition model/policy when used; otherwise cite the governing rule
},

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

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

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

Notes (normative intent, delegated semantics):

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

G.4:4.2 - CAL Pack@CG-Frame surface (kit governed by this pattern)

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

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

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

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

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

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

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

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

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

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

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

• CAL.EvidenceProfiles — evidence wiring surface:

  • lane tags (F/G/R) / provenance anchors / policy pins needed for SCR and audit surfaces,
  • explicit freshness/decay hooks (freshness window + decay/Γ_time selectors) as pinned policies/refs (not prose).
  • explicit ReferencePlane and any used penalty-policy refs (Φ(CL), Ψ(CL^k), Φ_plane); the ProofLedger supplies the receiving quantity, scale, input meanings, assumptions, and derivation or calibration. Monotonicity and boundedness alone do not justify a numerical loss.

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

  • descriptor/distance/insertion artifacts are pinned by ids/editions,
  • semantics are governed by method‑specific governing definitions (e.g., C.18, C.19) and not redefined by CAL. A CAL clause that consumes G.7 calibration states its exact receiving use and premises. A locally justified CL threshold is an additional policy condition; the ProofLedger and named authority must support that condition. It does not replace the bounded-use claim, target classification or reliance result. A policy waiver changes only the authorized policy condition.

• CAL.ProofLedger — a proof/justification ledger:

  • links operator/flow/clause ids to their needed legality and soundness results; a numerical support fold includes the B.3/C.2.2 receiving model, compatible scales and inputs, dependence assumptions, and boundary behavior.

• Publication artifacts:

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

Boundary discipline (normative):

• No shadow specs: CAL artefacts cite CN‑Spec/CG‑Spec and do not introduce competing “local specs” (delegated; see CC‑GCORE‑CN‑CG‑1 via CC‑G4‑CoreRef).
• Shipping boundary: G.10 governs shipping; see CC-GCORE-SKP-1 via CC-G4-CoreRef.
• Refresh boundary: CAL publishes pins/payload for refresh; G.11 governs refresh orchestration.

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

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

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

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

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

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

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

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

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

When CAL authoring relies on SoTA coverage, consume G.2’s pack CoverageJudgementRef with its HarvestPolicy basis and receiving question. Preserve the distinction between family coverage and lineage/material-entry plurality. A CAL clause does not turn a combined method/generator count into method-only coverage.

G.4:4.4 - Interfaces (minimal I/O surface)

G.4:4.4a - Declaration-to-runtime evaluation boundary (normative)

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

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

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

G.4:4.5 - Extensions (pattern‑scoped; non‑core)

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

GPatternExtension block: G.4:Ext.EvidenceGraphWiring

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

GPatternExtension block: G.4:Ext.NQD

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

GPatternExtension block: G.4:Ext.EELog

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

GPatternExtension block: G.4:Ext.SoSLogBranches

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

G.4:5 - Archetypal Grounding

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

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

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

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

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

Show 3 (one performed acceptance evaluation).

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

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

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

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

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

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

Show 4 (a support model and its separate acceptance threshold).

For the pump-triage use in G.5 §0.5, consider a separately declared gated variant. AC_InputConditionGate-E1 accepts a declared probability of at least 0.85 that both the measurement series is valid (event A) and its time alignment is valid (event B) for the same 24-hour input. Its scope, evaluation window, result-input declaration, and unknown behavior belong to this G.4 clause, not to the default composition rule. PumpInputEvidence-E1 supplies the receiving model and provenance for those event meanings and probabilities. An applicable TaskMapRef binds that clause, profile, and the matching C.22 task signature.

Suppose the application inputs establish P(A)=0.9 and P(B)=0.9 and the profile’s model establishes independence. The model gives P(A ∩ B)=0.81, so the clause returns fail. Minimum 0.9 would incorrectly pass. If independence or a justified conditional alternative is unavailable, the missing joint probability yields the clause’s unknown result, with the declared downstream degrade/abstain behavior; a high F or formal line tag cannot replace it.

For a different receiving question that asks only for a qualified comparison on existing heterogeneous support, the profile retains the proof, empirical contributions, shared-bias limitations, and contrary evidence under B.1.3/C.2.2. It does not invent a probability or apply AC_InputConditionGate-E1 to that different question. The ordinary G.5 shortlist remains available without an additional assurance calculation.

G.4:6 - Bias-Annotation

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

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

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

G.4:7 - Conformance Checklist (normative)

G.4:8 - Common Anti-Patterns and How to Avoid Them

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

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

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

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

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

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

G.4:9 - Consequences

• CAL operator/acceptance semantics become stable, citable CAL Pack content rather than 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.

G.4:10 - Rationale

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

The design separates concerns:

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

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

G.4:11 - SoTA-Echoing

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

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

G.4:11.1 - CAL architecture and publication inventory

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

G.4:12 - Relations

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

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

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

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

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

G.4:End

G.5 - Method-Family Registry, Dispatch and Selected-Set Result Declaration

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

Intent. Help an engineer use a dispatcher and registry for rival method families and state selector-facing set outcomes. The outcome distinction covers retained alternatives and members jointly included for one named use without collapsing plurality into one hidden scalar winner.

Primary working reader and object. An engineer or framework author who already has a set of identified candidates or members and must state the selector-facing result—outcome kind, members, ordering, named use when required, and basis pins—for a named downstream use, without also claiming a choice, Work, or publication occurrence that has not happened.

G.5:0 - Use this when

When loop-engineering work retains several already identified candidates for downstream use—for example, loop candidates, harness variants, method families, workflow-store entries, or DPF framework candidates—or when several already identified values are all included for one named use, use G.5 only when the live claim is the selector-facing declaration of that set result. The declared result states the outcome kind, members or keyed member entries, ordering status, named use when applicable, and basis pins. It does not prove that any member improved, that work occurred, that a local choice has been made, or that the result is available to an audience.

Use Shortlist or RankedShortlist for alternatives retained for later choice. Use JointUseSet only when every named member is included for one bounded use. This joint-use branch consumes exact member identities under their own rules; it does not require MethodRef, a method-family registry row, or Method classification for framework editions or other non-Method values.

When an earlier choice or other current inclusion basis has already fixed the exact members, use G.5-6 DeclareSetResult with those member refs, the named use, inclusion conditions, ordering, and sufficient basis pins. This branch declares selector-facing result content without running method-family registration or G.5-3 Select; non-Method members never enter those method-family operations.

For ordinary method-family dispatch, open G.5 when two or more already admitted Methods are live under grounded selector rows for the same declared task and the current question is the selector-facing set result: which candidates remain admissible, whether the emitted result may truthfully order them, or whether it must be a shortlist, narrowed handoff, abstain, or escalation. If the live question is still one local choice among available options, first constitute the exact C.11 choice assertion under its predicate. Reuse already grounded method-family rows when they exist; do not rebuild a registry on every run. Create a new reusable row only when the grouping itself must recur, carry family-level policy, be versioned, or be published. Crossing, evidence/reliance, assurance, stable public identity, and actual publication are conditional branches, not an entry fee.

For Method dispatch, resolve each exact A.3.1 Method and the row’s independent grouping basis under S1 (§4.2). An unresolved member or grouping basis blocks that row. If the claim concerns actual selection, use S3’s application and Work-admission conditions; a result declaration alone supplies no such occurrence. S5 governs any separately needed result episteme, public identity and publication claim.

Typical selector situations include:

• Methods or generators from several families are admissible for the same declared task family or work target
• you need one selector to return a Shortlist, RankedShortlist, JointUseSet, one SpecialistHandoff, one other narrowed handoff plan, or one abstain outcome without pretending that there is always one scalar winner or that all set results are alternatives
• the declared result must carry enough basis pins for its named downstream use—for example, later comparison, handoff, or escalation—without changing its declared outcome kind or any applicable public selected-set label

G.5:0.1 - What goes wrong if missed

• rival families are compared under silent comparator drift, hidden baseline changes, or unspoken crossing costs
• the selector hides one dogmatic winner even when only a partial order is admissible
• selector-facing result content stays hidden inside C.11, C.19, or C.24, so the G.5 result no longer states which upstream choice, pool treatment, or enactment result it consumes and what set result it declares
• exploration, open-ended, or specialization pressure leaks in as one architecture convenience rather than one explicit policy-bound choice

G.5:0.2 - What this buys

• one registry that keeps rival method families disjoint but dispatchable
• one selector result form that uses the closed SelectorOutcomeKind rules in §4.4b and the closed SetResultFamily set when the result is set-shaped
• one trace addressable by DRR and SCR records with explicit basis pins instead of one hidden selector rationale
• one explicit selected-set result that states the outcome kind, applicable public label, retained members or keyed joint-use entries, ordering, named use where required, handoff content, and basis pins instead of leaving them implicit upstream

Registry and dispatch remain the primary selector question here; the explicit selected-set result closes that question without replacing registry or dispatch.

G.5:0.3 - First-minute questions

• Which exact members and grouping or inclusion basis are already established?
• Are they alternatives for later choice or members all included for one named use?
• Does the declared comparison justify ordering them?
• Which eligibility, evidence or other receiving-use conditions actually apply?
• What result can be handed over, and what prevents a complete result?
• Does the current question additionally claim actual selection, composition, a relation between meanings, public identity or publication? Open only the applicable branch in §4.2.

G.5:0.4 - First output

State one SelectorOutcome under §4.4b: its kind, applicable members or keyed entries, ordering, named use and inclusion conditions where required, handoff or blocking content, and sufficient basis pins. Use the quick card in §4.4c. For an ordinary result over grounded rows, direct refs to the grouping, eligibility and comparison basis plus the S3 audit refs suffice; the same compact record can carry them.

A prior C.11 choice, C.19 pool-policy result, C.24 next action or another governed inclusion basis can supply the inputs. G.5 states the resulting membership or handoff. Exact framework editions retain their own identities and use G.5-6 DeclareSetResult; E.4.PFR governs their dependency or compatibility claims. Add a stable public identity only when needed. For audience availability, use E.17’s source-backed face and E.24.PUB’s publication conditions through S5.

G.5:0.5 - Minimum ordinary slice and bounded non-use

Situation. A pump-maintenance team has two already admitted A.3.1 Methods, ThresholdTrendReviewMethod-E2 and SpectralResidualReviewMethod-E1, behind the exact project-local selector rows <ThresholdTrendReview-local, R3> and <SpectralResidualReview-local, R2>. These are MethodFamilyRowRef values: each fixes its row edition, exact MethodRef[], and declared grouping basis PumpTriageCandidateGrouping-E1. The same TaskSignatureRef=PumpVibrationTriage-T1 and effective reference scheme apply to both. The task signature requires a 24-hour series input and a 30-minute review budget, and both declared Method interfaces meet those constraints. No G.4 CAL gate is current in this ordinary case, so TaskMapRef is absent. No admitted comparator justifies ordering one above the other. The live G.5 question is now how to surface that admissible set, not which pump action a decision-maker should choose.

The minimum truthful result is:

GroundedCandidateRows = [
  { methodFamilyRowRef = <ThresholdTrendReview-local, R3>,
    MethodRef = [ThresholdTrendReviewMethod-E2],
    groupingBasis = PumpTriageCandidateGrouping-E1 },
  { methodFamilyRowRef = <SpectralResidualReview-local, R2>,
    MethodRef = [SpectralResidualReviewMethod-E1],
    groupingBasis = PumpTriageCandidateGrouping-E1 }
]

SelectorOutcome(

  selectorOutcomeKind = SetResultOutcome,
  setResultFamily = Shortlist,
  members = [<ThresholdTrendReview-local, R3>, <SpectralResidualReview-local, R2>],
  ordering = unordered,
  basisPins = [<ThresholdTrendReview-local, R3>,
               <SpectralResidualReview-local, R2>,
               PumpTriageEligibility-E1],
  auditRefs = [DRR-PumpTriage-01, SCR-PumpTriage-01],

  nextUse = maintenance_method_handoff

)

What changes in practice. The team stops leaving the retained pair implicit in a comparison note and stops saying “the spectral method is best.” It emits one unordered Shortlist that another receiver can cite, with the exact survivors and basis visible, while making no local-choice, actual-use, or winning-method claim. A later receiver can request one missing comparator, use the bounded handoff, or open its separately governed decision question without rewriting either Method or inventing a winner.

Near misses and non-use. Do not use G.5 merely because several names appear in one list.

• If the Method-dispatch candidates are only labels, descriptions, cards, or unresolved references, require A.3.1 and C.2.1 before dispatch.
• If the current question is one local choice among already available options, use C.11; if it is the policy for retaining or retiring live candidate lines, use C.19; if it is enactment planning after choice, use C.24 for the plan and the applicable A.15/A.6 patterns for actual Work and operation applications.
• If the current object is only a composition sketch, keep the S4 template; use B.1.5 only for a qualified composite Method and A.22 only for an independently selected Structure.
• If no rival candidate set, selector result, narrowed handoff, abstain, or escalation is current, do not open G.5.
• Open F.9, A.10, B.3, stable registry or UTS identity, and E.24.PUB only for an actual crossing, relied-on evidence, assurance claim, reusable identity, or audience-availability claim respectively; their absence does not invalidate the smaller same-scheme selector result.

G.5:0.6 - Reuse a local grouping, then register it publicly when needed

The pump team in §0.5 already dispatches through R3 and R2. That unordered shortlist requires no new row. If the grouping of both Methods must recur across triage runs, the team can define:

MethodFamilyRowRef = <PumpReviewCandidates-local, R1>
MethodRef[] = [ThresholdTrendReviewMethod-E2, SpectralResidualReviewMethod-E1]
GroupingBasis = PumpTriageCandidateGrouping-E1
EligibilityBasis = PumpTriageEligibility-E1
TaskSignatureRef = PumpVibrationTriage-T1
ComparisonBasis = no admitted ordering; retain admissible alternatives unordered

The grouping criterion is “these admitted review Methods are candidates for pump vibration triage using the stated 24-hour input and 30-minute budget.” This project-local row fixes those exact members and basis; changed membership or an action-changing policy makes R2. It requires neither a UTS row nor an AssuranceProfile when this ordinary use has no assurance gate. A later real gate still consumes its required evidence and follows its unknown/fail behavior.

If the team instead intends a stable public registry entry, its proposed public continuation can be <PumpReviewCandidates, P1>, linked by an explicit naming/continuity mapping to the local R1 grouping. P1 retains the same exact Method refs and grouping criterion, adds the typed EligibilityStandardRef for the pump task and an AssuranceProfileRef stating expectations for its declared uses, and satisfies UTS naming/publication requirements under S1 and CC-G5.6. Registration is complete only when those public-contract obligations are met. For this P1 example, PumpTriageEligibilityStandard-E1 states the two Methods’ required 24-hour series and 30-minute budget, with unknown when a required input cannot be determined. PumpTriageAssuranceProfile-E1 names the evidence expectations and failure behavior for the declared triage uses; UTS-PumpReviewCandidates-P1 supplies the public name and continuity mapping to R1. P1 registration consumes these completed declarations and that UTS entry alongside the unchanged exact member/grouping basis. A missing one leaves public registration incomplete. The assurance profile supplies no B.3 result.

R1 itself completes through RegisterFamily with the six values shown above: neither AuthoringBase nor AuthoringMinimal is activated because this local grouping has no CG-Frame use. P1 adds the three public references just described and activates UTSWhenPublicIdsMinted. Now suppose a later G.5-3 Select use is governed by PumpTriage-CG-E1, whose MinimalEvidence clause requires a valid sensor calibration for the cited vibration series. Its CN/CG editions and frame pins are required. If the calibration input is missing, the evidence predicate is unknown and this example’s gate rule returns abstain; neither successful local R1 registration nor completed public P1 registration makes that selection pass.

Making local R1 available to the project audience may itself be an E.24.PUB publication occurrence when that pattern’s conditions obtain. Conversely, the intention or declaration of P1 establishes no availability. Neither branch creates a Method or an ontic family relation. Non-Method joint-use members continue through DeclareSetResult with their existing identities and inclusion basis.

G.5:1 - Problem frame

The exact CG‑Frame card from G.1 and SoTA Synthesis Pack@CG‑Frame from G.2 name the frame, EntityOfConcernRef, ReferencePlane, source rows, and rival internally coherent method families (and sometimes generator families) that may address the same declared task. If their breadth is used as a premise, cite G.2’s pack CoverageJudgementRef and its HarvestPolicy basis. Registration does not recount cards as families; a combined method/generator coverage result does not establish method-only coverage for dispatch.

At the same time, the scale and coordinate definitions from G.3 and the typed operator-argument and result declarations from G.4 make admissible calculi and acceptance clauses explicit - enough to formulate eligibility, assurance, and admissibility constraints, but not enough to pick “the method” without collapsing plurality.

You need a notation‑independent way to:

1. register method families and generator families as auditable, versioned entries,
2. select, compose, or fall back among them at run time for a concrete task instance,
3. declare stable selected-set results, including retained-alternative and all-member results, and publish stable identities to UTS when required, and
4. emit RSCR‑relevant triggers and pins without inventing new “shadow specs”.

G.5:2 - Problem

How to design a general, auditable dispatcher that:

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

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

• when expressions carry distinct F.17 source-local meanings, requires the complete crossing path—exact local senses, an obtaining F.9 Bridge, a separate bounded-use proposition, and the appropriate reliance or assurance branch—while treating pins as audit references rather than as the crossing facts;

• produces set-valued outcomes when only partial orders are admissible or when every named member is included for one bounded use, without confusing those meanings; when exact non-Method members already have a current inclusion basis, it declares that result without routing them through method-family selection;

• cleanly separates:

  • selector object set and components (registry, selector boundary, and result-declaration records),
  • universal Part‑G invariants (carried by G.Core),
  • method-specific and generator-specific semantics (carried only through Extensions blocks).

G.5:3 - Forces

• Pluralism vs. forced totalisation. Many selection regimes are inherently partial-order; forcing a scalar winner often creates inadmissible semantics.

• Evidence realism vs. hard gates. Eligibility and acceptance frequently depend on incomplete evidence; selection must remain auditable under tri-state unknowns.

• Reuse vs. leakage. Reuse across distinct source-local meanings remains valuable, but it starts from exact F.17 cells and an obtaining F.9 Bridge, then keeps the proposed use, direction, rule, tolerated loss, reliance or assurance, and actual selector use separate. Bridge, CL, loss, registry, bundle, or policy pins cannot silently re-ground semantics.

• Exploration vs. exploitation. Dispatch sometimes must probe alternatives under explicit policy envelopes and risk envelopes, but probing must not become an implicit fourth status.

• Evolvability vs. churn. Registries evolve (new families, deprecations, edition bumps); continuity must not be broken by “rename by meaning”.

G.5:4 - Solution

G.5:4.1 - G.Core linkage (normative)

Builds on: G.Core (Part‑G core invariants; Default Governing Definition Index citation)

GCoreLinkageManifest (normative; size-controlled via profiles and sets). For the operation in use, expand the applicable profile and set ids by union with its explicit deltas (per G.Core:4.2.1). The activation conditions below select those ids before expansion; Nil‑elision does not waive an activated obligation. Select retains its exact task, row editions and DRR/SCR-addressable audit result. DeclareSetResult instead consumes its exact result family, identified members, inclusion basis, ordering and named use where required; it acquires no TaskSignature, Method or registry row merely by declaring that set.

Select profile activation before expanding the G.Core sets. RegisterFamily always retains S1’s immutable row edition, exact admitted members, grouping criterion and applicable eligibility/comparison basis. A project-local row without a CG-Frame activates neither AuthoringBase nor AuthoringMinimal; it still satisfies those S1 obligations. Intentional public registration adds EligibilityStandardRef, AssuranceProfileRef and UTS obligations even when no CG gate is in use. When a real CG-Frame registry or Select use is current, both authoring sets apply in full; omitting their required CN/CG pins is a failure, not nil-elision.

For crossing-aware selection, CorePinsRequired below lists the crossing pins individually. Each conditional pin is mandatory when its stated condition holds. When consuming G.7 calibration records or a named B.3 assurance account, retain all pins, editions, and evidence required by that account, including CC‑G7‑SCRLinkage‑1 for cited calibration evidence.

• CoreConformanceProfileIds :=

  • GCoreConformanceProfileId.PartG.AuthoringBase (when the current operation authors a registry in an actually selected CG-Frame or performs G.5-3 Select within that frame)
  • GCoreConformanceProfileId.PartG.TriStateGuard (when evaluating eligibility or acceptance predicates)
  • GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted (when public identities are minted or evolved, including intentional public registration under S1/S1′ and CC-G5.6; a reusable project-local row alone does not activate this profile)
  • GCoreConformanceProfileId.PartG.ShippingBoundary (when an output is shipped)

• CorePinSetIds :=

  • GCorePinSetId.PartG.AuthoringMinimal (for the same actual CG-Frame registry-authoring or G.5-3 Select use; local registration or a set declaration alone does not activate it)

• CorePinsRequired := (delta over PinSets; pins and refs are id-only; prefer strengthening optional-to-required over restating pins already covered by PinSets)

  • TaskSignatureRef (the C.22 TaskSignature edition for Select; see G.5:4.2, S2)

  • TaskMapRef? (exact G.4 map edition, only when this selection uses G.4 CAL gates)

  • MethodFamilyRowRef[] (exact <MethodFamilyId, rowEdition> values when method-family rows are consumed or registered)

  • MethodRef[] (exact A.3.1 Methods resolved from every method-bearing registry row consumed or registered)

  • SelectedStructureRef[]? (exact independently selected A.22 Structures consumed only when their organization changes this selector use)

  • GeneratorFamilyRowRef[]? (exact <GeneratorFamilyId, rowEdition> values when generator families are in scope)

  • PathId[]?, PathSliceId[]? (when audit or evidence citations use a G.6 graph, or an independently applicable gate or shipping contract requires those citations)

  • UTSRowId[]? (when the operation mints, evolves or consumes a public identity; intentional public registration activates S1/S1′ and CC-G5.6 obligations)

  • FailureBehaviorPolicyId? (only when degrade or abstain behavior is explicitly policy‑bound)

  • SoSLogBranchId? (only when degrade or abstain behavior is explicitly policy‑bound)

  • BridgeId/BridgeCardId? (the obtaining Bridge actually used by this selection; a Bridge Card is cited only when that Card is relied on)

  • BridgeMatrixId? (when this selection uses a BridgeMatrix)

  • CL/CL^k/CL^plane? (the applicable values when cited or required by the consumed calibration or named assurance account)

  • Φ/Ψ/Φ_plane policy-ids? (the applicable policy ids and editions when required by the consumed calibration or named assurance account, or when crossing or plane penalties are applied)

  • CrossingBundleId? (when the selector cites a CrossingBundle or its named downstream use requires one under E.18 or CC‑G5.27)

• DefaultsConsumed :=

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

• RSCRTriggerSetIds :=

  • GCoreTriggerSetId.RefreshOrchestration (payload: exact changed source and affected-use scope; SCRId, DRRId; TaskSignatureRef, MethodFamilyRowRef[], CGSpecRef.edition and CNSpecRef.edition for a Select result; and the actually applicable TaskMapRef?, GeneratorFamilyRowRef[]?, AcceptanceClauseId[]?, SoSLogBranchId?, FailureBehaviorPolicyId?, DescriptorMapRef.edition?, DistanceDefRef.edition?, TransferRulesRef.edition?, InsertionPolicyRef?, PathId[]?, PathSliceId[]?, RSCRTestId[]?. Nongraph scope uses the existing G.Core PatternScopeId branch.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

G.5:4.3 - Selector head and narrower selector families

Selection and dispatch stay one generic selector head. Narrower selector families may refine it, but they do not redefine the universal invariants pinned through G.Core, do not add new mandatory inputs to inherited Select, and do not mutate inherited SlotKinds. Required policy and edition refs use the declared input meanings.

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

G.5:4.4 - Selector Relation Fields

RegisterFamily produces only the local or public registry row selected under S1. It does not produce any A.3.1 Method or independently governed membership fact. Select may address candidates through those rows only after their exact Methods and grouping bases resolve; its returned candidate or selected-set value does not retroactively ground a row member.

Compose produces only the pinned template named in its output column. It neither qualifies one composite Method under B.1.5 nor selects one A.22 Structure. When a later selector use consumes either governed object, the exact Method or Structure reference is an independently grounded input rather than a result inferred from this template.

DeclareSetResult begins only after its exact members and inclusion or selection basis are current. An upstream C.11 ChoiceResult, C.19 pool treatment, accepted decision, or another governed basis may appear among basisPins; the G.5 branch does not repeat or perform that decision. It declares the selector-facing set-result content and stops. It creates no member identity or relation, method-family row, Select application, dated selection Work, persisted C.2.1 result episteme, assurance or authority claim, or E.24.PUB availability occurrence.

G.5:4.4a - Worked selector slice

• A catalyst-search team is choosing among three method families for the same declared TaskSignature and C.22.1 adaptation signature.

• The shared profile pins one work-measure threshold target, one freshness window, one prior-exposure declaration, and one adaptation budget. One family reaches threshold quickly but carries high downside on adjacent tasks. One family is slower but transfers cleanly. One family never clears MinimalEvidence and must receive an abstain verdict.

• The G.5 result in this slice therefore declares one unordered Shortlist retaining the first two families, with DRR and SCR records citing why the third family was excluded and why the first two remain non-dominated. The selector does not invent one scalar winner and does not hide the specialization profile in auxiliary side notes.

• If the project also claims that this selection actually occurred, A.13 first recovers CatalystSelectorSystem-17 : U.System for exact action CatalystFamilySelectionAction-17. CatalystSelectorBoundary-17 contains the deployed selector runtime, its effective policy state, and its registry/evidence interfaces; it excludes the method-family rows, TaskMap, result records, assignment, and containing team System. The action applies the effective selector to the three candidate families and returns the retained set. Its scope is CatalystFamilySelectionClaimScope-17, its working situation is CatalystSearchSelectionSituation-17, and its window is 2026-07-30T10:00:00Z through 2026-07-30T10:08:00Z. CatalystSelectionAdmissibilityNorm-17 directs the selector to exclude candidates that fail MinimalEvidence, preserve admissible non-dominated alternatives, and abstain rather than manufacture a scalar winner. Relevant conditions include the exact CatalystTaskSignature-17, current row and map editions, eligibility evidence, comparison policy, and adaptation-signature values.

• A.2 declares local agential kind CatalystMethodSelectorSystemRole. Its membership criterion requires the stable work-facing contribution of method-family selection and goal-directed, condition-sensitive regulation under CatalystSelectionAdmissibilityNorm-17: the holder must apply the current gates, preserve the admissible set-return semantics, and abstain or escalate when no candidate qualifies. CatalystSelectorDecisionTrace-17 shows CatalystSelectorSystem-17 excluding the third family for failed MinimalEvidence, retaining the first two as non-dominated, and emitting no scalar winner. The trace and boundary/runtime records support the criterion facts under A.2’s membership rule; A.10 makes that source-to-use account recoverable. The case independently classifies CatalystSelectorSystem-17 under CatalystMethodSelectorSystemRole; neither the assignment nor the candidate Work supplies the classification. No Grade, autonomy result, characteristic profile, or stronger assurance claim is consumed.

• The same A.13 core uses CatalystSelectorAssignment, a directly declared species under U.SystemRoleAssignment. The species declares holder, assigned-kind, and task-signature participant meanings and the assignment predicate. CatalystSelectorAssignment-17 obtains with CatalystSelectorSystem-17, CatalystMethodSelectorSystemRole, and CatalystTaskSignature-17 as its exact participant values; its maximal uninterrupted predicate-true interval covers the stated scope, situation, and window.

• Only after that core is established does A.15.1 independently admit CatalystSelectionWork-17 : U.Work from the exact selection-action history, enacted CatalystFamilySelectionMethod, temporal extent, and obtaining containing-System relation to independently admitted CatalystSearchTeamSystem. Actual application CatalystSelectApplication-17 separately carries its effective candidate, criteria, and A.19 SelectionSlot bindings. Neither the assignment nor F.6 is an A.15.1 admission premise.

• Because this account explicitly attributes the Work under CatalystSelectorAssignment-17, F.6 afterward establishes performedUnderAssignment(CatalystSelectionWork-17, CatalystSelectorAssignment-17) through that same obtaining A.13 assignment. The direct case fact links the exact pair, holder equality holds, and the assignment interval covers the Work. A different overlapping assignment held by the same System would not establish this attribution. A short result may omit the assignment identifier only after every fact consumed by the attribution remains recoverable.

• A persisted shortlist assertion is a separate C.2.1 episteme; its DRR or SCR references do not by themselves prove the exclusion facts, warrant the result, authorize downstream action, or make that episteme available to an audience.

• When one upstream C.19 pass has already narrowed the live pool to one internal retained subset over registered families, G.5-6 DeclareSetResult may declare that result as one Shortlist with one ShortlistId and explicit basis pins only when selector-facing result declaration is now the question. Until that declaration occurs, the internal retained subset is not yet one G.5 shortlist result.

• When one upstream C.11 pass has already fixed one local choice over one declared source set, C.19 has fixed one retained pool treatment, an accepted decision has fixed all-member inclusion, or C.24 has produced one enactment-facing narrowed handoff, use G.5-6 DeclareSetResult when selector-facing set-result content is now the question. Until that declaration occurs, the ChoiceResult, PoolPolicyResult, accepted inclusion basis, CallPlan, or CheckpointReturn is not itself that G.5 result. Non-Method members do not pass through RegisterFamily or G.5-3 Select.

G.5:4.4b - Declared selected-set result and closure rule

When the current question is selector-facing result declaration, state one explicit selected-set result rather than leave it implicit in a selector trace, comparison note, or local choice.

For method dispatch, that result closes selector work over grounded rows. For a JointUseSet, it records already identified members that are all included for one named use. It does not replace registry maintenance, comparison rules, the upstream choice or inclusion basis, or the patterns that identify the members and their relations.

The admissible selector outcome families here are:

• SelectorOutcomeKind = SetResultOutcome, whose closed SetResultFamily value set is Shortlist when alternatives are retained for later choice and the result does not order them, RankedShortlist when the result orders those retained alternatives, and JointUseSet when every named member is included for one named use;
• SelectorOutcomeKind = HandoffOutcome, with HandoffKind = SpecialistHandoff or one other narrowed handoff plan when heterogeneity is the truthful downstream result;
• SelectorOutcomeKind = AbstainOutcome when no admissible candidate exists and the truthful result is one abstain; and
• SelectorOutcomeKind = EscalationOutcome when no admissible candidate exists and the truthful result is one escalation.

G.5-3 Select may emit one of these outcome kinds only over the exact Method candidates admitted through its kernel; G.5-6 DeclareSetResult emits SetResultOutcome from exact already identified members and a current inclusion basis. Neither branch performs an upstream choice, makes a member relation obtain, or proves actual selection Work.

A JointUseSet uses this bounded representation:

• namedUse states the one joint use;
• memberEntries contains one keyed entry per included member;
• every entry has one exact memberRef; the membership result adds no per-member contribution or basis field;
• each exact memberRef occurs at most once, and entry order has no semantic effect;
• if a serialization also emits top-level members, it is only the unique set projection of memberRef values from memberEntries, never a second maintained list;
• ordering, inclusion conditions, and sufficient top-level basisPins remain explicit; and
• candidate-pool membership and excluded candidates stay separate from emitted joint-use membership.

Exact content, claims about a member’s use or contribution, and direct relations keep their own governed records. When one supports the membership result, cite that existing record among basisPins; memberEntries creates neither the cited content nor a new contribution relation.

For framework use, memberRef may name an exact already identified edition under its existing identity rules. Do not populate MethodRef, create a registry row, or classify that edition as a Method merely to emit the result.

Every outcome still states its SelectorOutcomeKind, public result kind when applicable, members, keyed entries, handoff content, or blocking condition, ordering, and sufficient basis pins. A handoff also states its next downstream use boundary.

A compact retained-alternative result may look like:

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

A compact joint-use result may look like:

SelectorOutcome(
  selectorOutcomeKind = SetResultOutcome,
  setResultFamily = JointUseSet,
  namedUse = cohort_review,
  memberEntries = [
    { memberRef = FPF@C },
    { memberRef = Domain@D },
    { memberRef = Local@L }
  ],
  ordering = unordered,
  inclusionConditions = [all_three_editions_required_for_cohort_review],
  basisPins = [choice_result_12, edition_basis_7]
)

Close with Shortlist or RankedShortlist when the result retains alternatives. Close with JointUseSet only when every member is included for the named use and its keyed membership can be stated truthfully. Close with a handoff, abstain, or escalation outcome when that is the actual result. If the result omits its result family, members or member entries, ordering, named use where required, or basis pins, it is not a complete G.5 result.

G.5:4.4bb - Public labels over archive, front, and style source sets

When a selector consumes a declared ExplorationArchive, Archive, Front, or Q-front, keep that object as a source-set family or source-set reference; it is not the emitted G.5 outcome. The emitted result states one admitted SelectorOutcomeKind and, for a set result, one admitted SetResultFamily. StyleShortlist and TraditionShortlist may be public domain labels over an admitted set-result family after their term bridges and cultural meaning are clear; they do not extend either closed set.

SelectedSetResultLabelLine@Context:
  selectorOutcomeKind:
  setResultFamily?:
  sourceSetFamily:
  publicSelectedSetLabel?:
  namedUse?:
  memberEntries?:
  membersOrHandoff?:
  derivedViewKind?:
  basePaletteOrArchiveRef?:
  ordering:
  basisPins:
  nextUse:

Earlier records may keep membersOrHandoff. Read it as members for Shortlist or RankedShortlist and as handoffContent for a HandoffOutcome. It cannot replace keyed memberEntries in a JointUseSet; if it also lists joint-use members for compatibility, that list is only the unique set projection of the entry keys.

sourceSetFamily may name a declared Front, Q-front, ExplorationArchive, Archive, current pool subset, or derived tradition view. For retained alternatives, publicSelectedSetLabel normally names Shortlist or RankedShortlist and may use a domain label such as StyleShortlist or TraditionShortlist only when the term bridge is already clear. JointUseSet is not a shortlist label: it names an all-member result and therefore uses namedUse plus keyed memberEntries. G.5 does not create the archive, compute the comparison, govern the pool policy, decide the cultural-evolution case, establish member identity or relations, or repair the term bridge. Use C.18 for archive formation, A.19.CPM for comparison, C.19 for pool policy, C.36 for cultural-evolution claims, each member’s own identity and relation patterns for those facts, and F.17/F.18/F.9 for local meanings, naming settlement, and any obtaining term Bridge.

G.5:4.4c - Result-declaration quick card

Use the outcome definitions in §4.4b and fill only the applicable fields:

The pump result in §0.5 and the joint-use declaration in §4.4b show complete filled forms. A missing required value leaves the result incomplete.

G.5:4.4ca - Derived tradition-view result stays derived over one declared palette

When the source is TraditionFront or TraditionArchive, keep its base SoTAPaletteDescription recoverable. State SourceSetFamily; add DerivedViewKind when it changes interpretation or later publication and SourceSetComposition only when several source-set families were actually composed. Cite the derivation’s declared Q, reachability or coverage rule among the DRR/SCR or equivalent basis pins. The view qualifies the source; §4.4b still defines the emitted outcome.

G.5:4.4d - Worked result-declaration closure slice

The following extensions apply only when their corresponding mode is active. Their declared Uses and pins cite the governing semantics.

GPatternExtension block: G.5:Ext.EELog

• PatternScopeId: G.5:Ext.EELog

• GPatternExtensionId: EELog

• GPatternExtensionKind: MethodSpecific

• GoverningPatternId: C.19

• Uses: {C.19}

• ⊑ and ⊑⁺: ∅

• Required pins, edition pins, and policy pins (minimum):

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

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

• Notes (extension discipline; semantics cited):

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

GPatternExtension block: G.5:Ext.SoSLOG

• PatternScopeId: G.5:Ext.SoSLOG

• GPatternExtensionId: SoSLOG

• GPatternExtensionKind: MethodSpecific

• GoverningPatternId: C.23

• Uses: {C.23}

• ⊑ and ⊑⁺: ∅

• Required pins, edition pins, and policy pins (minimum):

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

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

• Notes (extension discipline; semantics cited):

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

GPatternExtension block: G.5:Ext.NQD

• PatternScopeId: G.5:Ext.NQD

• GPatternExtensionId: NQD

• GPatternExtensionKind: MethodSpecific

• GoverningPatternId: C.18

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

• ⊑ and ⊑⁺: ∅

• Required pins, edition pins, and policy pins (minimum):

  • DescriptorMapRef.edition
  • DistanceDefRef.edition
  • InsertionPolicyRef
  • TaskSignatureRef (when QD is enabled via TaskSignature flags or traits)
  • active fields from C.21’s DHC replay basis (only when this telemetry consumes a C.21 DHC coordinate; carry exactly the fields that coordinate used)

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

• Notes (extension discipline; semantics cited):

  • G.5 core remains QD‑agnostic; QD semantics are governed by C.18.
  • Post-2015 families that typically use this extension declaration: MAP-Elites-class QD including later archive-centric refinements, CMA-ME-class hybrids, modern illumination and coverage telemetry regimes where admissibility and edition pinning matter.

GPatternExtension block: G.5:Ext.OpenEndedFamilyWiring

• PatternScopeId: G.5:Ext.OpenEndedFamilyWiring

• GPatternExtensionId: OpenEndedFamilyWiring

• GPatternExtensionKind: GeneratorSpecific

• GoverningPatternId: G.2

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

• ⊑ and ⊑⁺: ∅

• Required pins, edition pins, and policy pins (minimum):

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

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

• Notes (extension discipline; semantics cited):

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

G.5:4.4e - Source sets, operating modes and comparison policy

Use §4.4b for the emitted outcome and §4.4bb–ca for its source and public-label interpretation. An actual SelectionSlot binding carries the by-value selected candidate set; it is separate from G.5’s declared SelectorOutcome. ChoiceSet remains an ordinary mathematical set gloss, not an additional public result kind.

Use controlled tokens, cited ids or already declared head labels for these fields. CostToProbe, ValueOfInformation, ValueOfComputation, explore_share, graduation conditions and sequencing pressure belong to the surrounding choice doctrine when they affect the decision; a result field does not establish them. All-member membership and candidate/exclusion records retain the separation in §4.4b.

G.5:4.6a - Causal method dispatch declarations

When method dispatch compares causal uses, each compared Method declares its causal question/rung and whether it is being used as an observational predictor, intervention optimizer, counterfactual strategy, causal fairness estimator, causal-RL policy, or simulation-only Method.

MethodFamily.causalUseDispatchSpec?:
  causalUseQuestionRef?: CausalUseQuestionRef
  targetCausalityLadderRung: CausalityLadderRung
  causalUseClaimKind: CausalUseClaimKind
  causalActionPolicyClass?: CausalActionPolicyClass
  causalSupportComponentRefs?: CausalSupportComponentRefs
  causalUseSupportResultRef?: CausalUseSupportResultRef
  causalMethodUseClassification:
    observationalPredictor |
    interventionOptimizer |
    counterfactualStrategy |
    causalFairnessEstimator |
    causalRLPolicy |
    simulationOnlyMethod
  supportedUse
  unsupportedUse

CausalUseQuestionRef identifies the question content used by C.28; it is not a durable root U-kind. causalMethodUseClassification describes the Method’s proposed selector-facing use and supplies no system-role assignment, responsibility, authority, or causal certification.

A simulation-only Method cites simulationResultRef inside its support components and states bounded model use plus unsupported realized/interventional use. G.5 declares the dispatch result; C.28 supplies the causal-support result. A selector may still abstain even when a C.28 result is supported.

G.5:5 - Archetypal Grounding

Tell (archetype). The selector-bearing System must choose among rival families without lying about measurement admissibility, crossings, or evidence. The result Episteme keeps the comparison basis, audit pins, and refresh conditions recoverable. When the current result instead includes several already identified members together, the same result-content boundary must not disguise that all-member meaning as retained alternatives.

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

Show 2 (specialist handoff; ranked result). A bounded-specialization comparison keeps two method families live under a pinned admissible comparator that orders them, and downstream handoff needs that ordering. Declare one RankedShortlist with that ordering and comparator among its basis pins, ShortlistId when public identity is needed, and handoff-facing nextUse. If no admissible comparator supplies an order, retain an unordered Shortlist; the request for a ranked handoff does not establish one.

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

Show 4 (complementary framework editions; unordered joint use). A training cohort needs FPF@C, Domain@D, and Local@L together. The editions are already identified under their own edition rules; they are not Method candidates or registry rows. An accepted cohort decision supplies the exact members and basis. G.5-6 DeclareSetResult emits one unordered JointUseSet with one keyed entry per edition, the named cohort-review use, inclusion conditions, and sufficient top-level basis pins. Direct dependencies and pairwise compatibility claims remain with E.4.PFR; publication and access remain with E.17/E.24.PUB and the applicable access-carrier pattern. The G.5 result declares membership but does not perform the choice, make those neighboring claims obtain, or create a contribution relation.

Show 5 (support-sensitive Method eligibility).

Keep the exact admitted Methods, row editions, and grouping basis from §0.5. In a gated variant, the matching G.4 task map makes AC_InputConditionGate-E1 from G.4 §5 applicable to ThresholdTrendReviewMethod-E2. Consume that clause’s value and threshold rather than define either in G.5. For the two-condition case there, the returned fail excludes that row from the assurance-gated set. Replacing its joint probability with minimum would wrongly retain it. An otherwise admissible row stays in the set under its own declared eligibility basis; if none survives, return the existing abstain or escalation outcome.

If the dependence model is missing, use the clause’s unknown branch rather than pass by a high F. In the ordinary, non-assurance question of §0.5, both grounded rows still form the unordered Shortlist. A formal proof, a limited complementary study, and an overlapping contrary result can remain separate support with their limitations; neither weak additional evidence nor the absence of an unjustified common score automatically removes a Method. A defeated necessary premise still changes the eligibility that actually relies on it.

Show 6 (one calibrated correspondence, two receiving uses).

Use G.7 §4.5’s VehicleTransportOrder row from C.3.3 to select among independently admitted Methods for a transport review. The task’s applicability comparison uses only the preserved transport/passenger order and explicitly ignores propulsion. When receiving admissibility, fresh target classification of the subject vehicles, the bounded comparison conditions and matching reliance pass, that row can support Method eligibility under the task’s other rules. Keep those premises with the result.

For a second task that requires battery-health evidence, the same CL^k=2 row loses the necessary EV distinction and cannot support that criterion. Return the missing battery premise through the existing unknown/abstain or evidence-request branch. Raising a scalar summary or citing a waiver does not restore that distinction. G.7 reports the correspondence; the exact TaskSignature and receiving rules decide each selection use.

G.5:6 - Bias-Annotation

Potential biases and failure modes this pattern explicitly guards against:

• Monoculture bias (single Tradition dominance by default). Mitigation: rows retain an explicit eligibility basis and conditional assurance expectations; public registration adds its stronger records; selection is set‑returning under partial orders; method‑specific policies stay explicit pins rather than hard-coded defaults.

• Hidden scalarisation bias. Mitigation: set-return semantics is pinned through G.Core; dominance regimes are explicit and each default cites one declared governing definition.

• “Tool equals method” bias. Mitigation: notation independence and prohibition of tool keywords in core registry and eligibility fields; tool choices are outside the core.

• Cross-sense leakage bias. Mitigation: when expressions have distinct source-local meanings, require exact F.17 endpoint senses, an obtaining F.9 Bridge, a separate C.2.1 bounded-use proposition, and the matching A.10 or B.3 reliance branch; keep loss and CL visible where material. Crossing pins and bundles remain audit or publication references and cannot make an implicit crossing admissible.

• Survivorship bias in refresh. Mitigation: RSCR triggers are typed and id-based; freshness, decay, and telemetry deltas are first‑class causes with canonical ids.

G.5:7 - Conformance Checklist (normative)

G.5:8 - Common Anti-Patterns and How to Avoid Them

• Anti‑pattern: “Selector as a shadow spec.” Symptom: local acceptance or admissibility rules appear in selector prose or code, diverging from CN, CG, and CAL. Avoid: govern constraint semantics through CNSpecRef and CGSpecRef plus pinned CAL records; keep G.5 core as a boundary.

• Anti‑pattern: “Implicit crossings.” Symptom: reuse across distinct source-local meanings is claimed from a shared label, Bridge or CL pin, registry row, policy, DRR or SCR line, GateCrossing, or CrossingBundle without the required relation, use, and reliance facts. Avoid: resolve the exact F.17 endpoint senses; establish the F.9 Bridge; state the separate C.2.1 <u,d,r,t,polarity> claim; require the matching A.10 disposition or B.3 assurance branch; and keep authorization and actual selector use separate. Materialize or cite a bundle only when its named downstream use requires that durable package.

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

• Anti‑pattern: “Method specifics in the selector head.” Symptom: QD, OEE, or 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: a continuing family id silently resolves different members, grouping basis, or selection pins after a row changes. Avoid: keep the lineage id only for the continuing declared grouping, publish a new immutable row edition, and carry its exact row ref through selection, result basis, refresh, and deprecation notices.

• Anti‑pattern: “Result declaration hidden in upstream reasoning.” Symptom: the retained alternatives or all-member result exist only as one implication inside C.11, C.19, or C.24, while G.5 never names the declared result kind. Avoid: declare the selected-set result directly, with its result kind, applicable members or keyed entries, ordering, named use where required, and basis pins instead of leaving it implicit upstream.

• Anti-pattern: “Shortlist used for complementary members.” Symptom: every named member is needed for one use, but the result calls them alternatives in a Shortlist. Avoid: use JointUseSet, name the joint use, and key one entry per exact member; keep direct member relations and actual selection separate.

• Anti‑pattern: “Declared result missing required content.” Symptom: a Shortlist, JointUseSet, narrowed handoff, or abstain result is named, but the emitted result still omits its members or keyed member entries, ordering, named use where required, or basis pins. Avoid: state the result kind, retained members or keyed joint-use entries, ordering, named use where required, abstain or escalation condition, and basis pins directly in G.5.

G.5:9 - Consequences

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

G.5:10 - Rationale

• Why registries? Reusable method-family dispatch requires stable, auditable row editions with explicit eligibility and assurance records, so later uses can recover the grouping and its dispatch basis.
• Why separation via Extensions? QD, OEE, preference-learning, and similar families are fast-moving and method-specific; making them part of the selector head would force a universal semantics and violate strict distinction.
• Why set-return? Partial orders are common and often the only admissible representation under heterogeneous scales; set-return preserves semantics and makes tie criteria explicit.
• Why explicit defaults with one declared source? Defaults are unavoidable; single-source indexing prevents competing defaults from silently diverging across patterns.
• Why selected-set result declaration here? Once the current question is to state retained alternatives or an all-member result for downstream use, the selector should declare that result directly instead of leaving it implicit in local choice, pool-policy, or enactment notes written for other purposes.
• Why JointUseSet? A shortlist preserves alternatives for later choice; an all-member result says that removing one member changes the result for the named use. G.5 mints JointUseSet only as a local SetResultFamily value and reuses the existing outcome schema and member identities. G.5-3 Select may emit it only over exact Method candidates admitted through that kernel; G.5-6 DeclareSetResult covers exact already grounded members without retyping them as Methods. Neither branch mints a new U-kind, Method kind, relation kind, or registry kind. CoUseSet is less plain, ComplementarySet would imply a relation among the members, and Bundle would misname a package form.

G.5:11 - SoTA-Echoing — return what the receiving use can actually select

Practice question. What should a dispatcher hand over when several candidates remain useful but the declared comparison does not justify one winner? The selected line returns the admissible alternatives with their ordering status and basis. A serious default chooses one best candidate under a declared objective and returns it ready for use. That default is efficient when the objective settles the choice; it loses a needed alternative when an undeclared scalar objective is substituted for an unresolved trade-off.

The scikit-learn GridSearchCV documentation, refit and best_estimator_, supplies the concrete default. It can choose one estimator by a scorer or a custom rule over the evaluation results; multi-metric evaluation still needs a specified refit choice. Adopt that explicit-choice requirement when G.5 emits an ordered result. Reject reading a single best-estimator interface as a warrant to invent the missing comparator. The library supports custom choices and exposes other candidate results; it does not require G.5 to discard them.

PS-AAS, Kostovska et al. (2023) supplies a substantive alternative-selection line: form a complementary portfolio for later algorithm selection, balancing coverage with the cost of a larger choice problem. Its experiments concern specified CMA-ES variants and BBOB tasks, not arbitrary Methods. Adapt the distinction between forming an eligible pool and selecting a member to Shortlist and RankedShortlist in §4.4b, S3 and the pump case in §0.5. The selected line here is this result discipline, not a claim that PS-AAS is the best portfolio algorithm for every task.

A different receiving use combines members. Split-Ensemble, Chen et al. (2024) supplies a concrete counterexample to treating every retained set as alternatives: its submodels serve complementary subtasks in one ensemble. Adapt that use distinction to JointUseSet and G.5-6 DeclareSetResult. G.5 states all-member inclusion; the paper’s trained ensemble does not establish compatibility or effective combined use for an arbitrary set of framework editions. Show 4 therefore keeps those claims with their own patterns.

In §0.5 both grounded pump Methods meet the task constraints, but no admitted comparator orders them. With the same candidate evidence, returning the pair as an unordered Shortlist preserves the receiving choice at the cost of one further decision. Naming the spectral Method “best” would require an additional criterion and its supporting comparison. If that criterion is supplied and actually orders the candidates, a ranked result is available. If the receiving use includes every exact member, declare that different membership meaning; a ranking does not establish it. These distinctions govern the outcome declarations and the positive, ranked, no-survivor and joint-use cases in §5.

Reopen when new evidence changes eligibility, a comparator supplies or defeats an ordering, the downstream use changes from alternatives to joint inclusion, or keeping the retained set costs more than the receiving decision can bear. A bounded handoff or abstain outcome remains available. None of these sources establishes actual selection Work, a Method’s identity, public availability or assurance merely from the emitted result.

G.5:12 - Relations

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

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

• Specification refs required by this result: A.19.CN (CN‑Spec), G.0 (CG‑Spec). Use A.2.6 only when a U.ClaimScope or selected U.ContextSlice changes selection, applicability, or a receiver’s justified reliance; validity and evaluation windows and intended-use restrictions follow the same conditional boundary.

• Method identity and family grouping: A.3.1 for every exact selectable U.Method; A.3.2 only for the same C.2.1 episteme that substantively describes one already admitted Method; and C.2.1 or the defining declaration or pattern for the family relation cited by a registry row. G.5 creates none of those source facts.

• Method composition and selected organization: B.1.5 for the complete composite-Method qualification, A.22 for an independently selected organization that does not constitute one Method, and C.29 for algebraic, graph, matrix, embedding, neural, or other representation-lens use. G.5 consumes exact resulting references and does not construct them.

• Upstream object sets: G.1 (CG‑Frame Card), G.2 (SoTA Pack), G.3 (CHR Pack), and G.4 (CAL Pack). C.22 alone constitutes the TaskSignature. When G.4 CAL gates are current, G.5 additionally consumes the exact TaskMapRef that relates that same TaskSignatureRef to one exact charter and the cited CAL declarations; otherwise the map is absent.

• Evidence and crossings: G.6 for EvidenceGraph citations; F.17 for exact local senses; F.9 for the direct Bridge; C.2.1 for the separate bounded-use proposition; and A.10 or B.3 for reliance or assurance. Add a CrossingBundle under E.18 or a GateCheck under A.21 only when that named downstream use requires one. A G.7 calibration artifact remains a cited policy or evidence input; it does not define the Bridge, bounded use, reliance, or selector actuality.

• Planning and enactment boundary: A.15.2 identifies the U.WorkPlan used as plannedBaselineRef; A.15.3 defines any planned-filling rows kept inside that WorkPlan. G.5 does not redefine them.

• Actual selector use and result availability: A.19.SelectorMechanism and A.6.1 for the actual Select application and bindings; A.13 for every precise performer’s local-kind criterion, classification, same obtaining assignment, scope, situation, window, and evidence; A.15.1 for independent Work admission; A.2.1 for the assignment species and occurrence; and F.6 only for a current exact assignment-bound attribution. When asserted by the account or consumed by its receiving use, A.2.4 governs evidence use, A.10 governs reliance and provenance, G.11 governs currentness, C.2.1 governs a persisted result episteme, B.3 governs assurance, the direct authority pattern governs authorization, and E.24.PUB governs publication. Upstream CPM applications retain their local bindings without requiring separately admitted comparison Work unless that Work is asserted. A root-family assignment reference, temporal overlap, or omission from short wording supplies no attribution and removes no world-side fact. G.5 declarations and records create none of those neighboring facts.

• Joint-use members outside Method dispatch: the direct identity pattern identifies every memberRef; C.11 supplies a local choice result when one is current; another accepted decision or governed inclusion basis may establish all-member inclusion; E.4.PFR states framework-edition dependency or pairwise compatibility separately; G.11 supplies currentness; and E.17/E.24.PUB plus the applicable access-carrier pattern supply exposure and source return. G.5-6 DeclareSetResult consumes the exact members and sufficient basis pins and emits only the selector-facing membership result.

• Causal-use method dispatch: C.28 when method selection involves causal effect, counterfactual comparison, causal fairness, causal policy, causal RL, or simulation-only causal-use claims.

• Optional Method or generator extensions through G.5:Ext.*: C.18, C.19, C.23, plus extension-bearing patterns whose exact Part G admission relation is established when they add extra selector pins.

• Mathematical-lens use: apply C.29 when a selector input depends on a mathematical object or mapping whose use is not yet recoverable—for example, a comparator, distance, descriptor geometry, embedding, normalization, surrogate model, learned representation, QD archive descriptor, model-family label, or model-selection basis. For claim-bearing lens use, recover that object’s mapping mode, preserved or lost structure, and stop condition. A LensCandidateNote may instead retain the recognition and next-action account while CandidateMathObject? remains unresolved. The recorded result is a C.29 lens-use result; non-exhaustive examples include no lens use, a lens-candidate note, a one-line note, a mini-card, a full card, or a note naming the applicable pattern for the stated selector use. That result does not declare a selector result or its supporting records, such as the selected set, selector policy, registry row, shortlist, ranked shortlist, or selector evidence pins; use G.5 for those objects and cite the exact references used.

Provides to: downstream uses such as G.6 audit citations, RSCR emission records with typed triggers and payload pins, and packs shipped through G.10. When a named use needs stable public identity, publish the required family ids, selector policy records, or selected-set identities—such as ShortlistId—to UTS under the applicable identity rule.

Coordinates with: C.11 for local choice results; E.4.PFR for direct framework-edition dependency and pairwise compatibility claims; G.11 for edition currentness; E.17 for a source-backed publication face and return to source; E.24.PUB for a publication occurrence and audience availability; C.19 for pool-policy records; C.32.P2S when a selected-set result declaration feeds architecture problem-to-structure carry-through; C.35 when a generated or discovered structure-bearing output is not yet a selector-facing result; C.24 for enactment-facing next-action records; and C.18 when a Front or Q-front is the source set for a G.5 use.

A Q-front stays a C.18 source set; it is not the emitted G.5 outcome or a SetResultFamily. The G.5 result states one admitted SelectorOutcomeKind; a set result also states Shortlist, RankedShortlist, or JointUseSet, and any public selected-set label resolves to that family.

Architecture discovery boundary: when a generated or discovered structure-bearing output is only a representation or carrier—for example, a description, query result, graph, cluster, or search trace—use C.35 before G.5. Use G.5 only when the live claim is declaration of selected-set result content with selector-policy and selected-set identity; stable public identity and actual publication remain conditional neighboring branches.

G.5:End

G.6 - Evidence Graph and Provenance Ledger: Citable Evidence-Provenance Paths

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

G.6:1 - Problem Frame

Use this pattern when a later user must cite, replay, audit, or refresh a path through several already established objects and relations rather than repeat their complete source account.

Use it when the working question is:

• which admitted dated Work occurrences and A.13-qualified actual performer Systems must remain addressable, together with already-established F.6 attribution refs only when the selected path expressly consumes precise assignment-bound attribution, and any local system-role kind or assignment identifier that the path separately uses;
• which direct participation or binding facts, produced entities, domain results, result epistemes, outcomes, source publications, carriers, and provenance relations must remain addressable;
• which exact direct relations connect those objects, which pattern defines or constrains each relation, and whether each relation is already established as obtaining;
• which bounded context, reference plane, time window, bridge, edition, policy, source-currentness result, or reliance boundary limits the cited path;
• which downstream work and exact use relation may cite the path; and
• what stronger conclusion, assurance, permission, acceptance, gate passage, or decision the path does not carry.

Primary EntityOfConcern. The primary EntityOfConcern is an addressable provenance representation: one EvidenceGraph, its PathId or PathSliceId, and any ledger entry that makes the path replayable. G.6 governs path identity, slicing, citation, and local refresh. It does not create the represented work, participation, production, result, episteme, outcome, source, currentness, reliance, or representation correspondence.

First useful move. Name the relied-on claim or bounded use, then list the exact object refs and direct relation refs needed to replay it. For every relation record its direct governor and obtaining claim. Only then draw the path. Keep an unresolved relation as a gap; do not turn it into a graph edge asserted as obtaining.

What goes wrong if missed. A tidy graph makes an unperformed method look like Work, a co-listed System or entity look like a participant or Work performer, a carrier look like a produced result, a measurement or verdict look like generic evidence, or a provenance edge look like the world-side relation itself.

What this buys. Downstream work can cite one stable path while a reviewer can still recover the exact work, participants, products, subject results, result epistemes, sources, direct relations, currentness, and bounded use that the path represents.

Not this pattern when. Use A.2.4 for the first evidence-use or status-use classification, A.10 for source recovery and bounded reliance, A.15.1 and F.6 for performed Work and its attribution, A.2.1 only when an assignment occurrence itself is current, A.6.1 for actual operation bindings, A.15.PROD when production or inception is current, the exact domain pattern for its local result, C.2.1 for the result episteme, G.11 for currentness, C.29 for representation correspondence, and B.3 for assurance. If only one local source-to-use statement is needed, stay in A.10.

Here path means a path in a descriptive provenance graph. It is not an action route, method, workflow, transformation flow, universal evidence relation, or generic work-result relation.

G.6:2 - Problem

Large projects often need to cite a chain that crosses measurement, evaluation, aggregation, production, publication, and later use. The chain becomes unsafe when the graph is allowed to supply facts missing from the governed objects.

The common failures are:

1. Edge-to-fact inversion. A drawn edge is treated as proof that work, participation, production, measurement, evaluation, or use occurred.
2. Generic relation fallback. Labels such as verifiedBy, validatedBy, measuredBy, producedByWork, or evidences replace the exact direct relation and its governor.
3. Result collapse. Subject result, result episteme, carrier, outcome, assurance, and later decision become one generic result node.
4. Declaration-to-runtime collapse. A MethodDescription, operation signature, policy, clause, or plan is read as an actual run and its bindings.
5. Hidden crossing. A path silently crosses context, reference plane, edition, source order, or currentness window.
6. Refresh fanout. One changed source or relation forces a global rerun because the smallest affected path slice cannot be found.

G.6:3 - Forces

G.6:4 - Solution — cite independently governed objects and relations

Create an EvidenceGraph only after the relied-on claim or bounded use and its supporting objects have been recovered. The graph is a declarative, addressable representation. Each node record cites one independently governed object; each asserted edge record cites one independently established direct relation. PathId, PathSliceId, and the provenance ledger add citation and refresh locality, not world-side facts.

G.6:4.1 - Subject-pattern map