#G.Core - Part G Core Invariants

Preface node heading:g-core-part-g-core-invariants:54273

#Content

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

Status. Draft (Phase‑2 deliverable)
Placement. Part G → immediately after G.0 (without renumbering G.0…G.13)
Normativity. Normative unless explicitly marked informative

Purpose. Provide a single owner for Part‑G‑wide invariants (delegation‑first routing), plus a typed RSCR trigger kind catalogue and a Default Ownership Index, so Part G can be refactored without semantic drift or public‑ID breakage.

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

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

#G.Core:1 - Problem frame

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

Part‑G‑wide invariants reside in G.Core as a single-owner pattern so every G.x can:

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

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

#G.Core:2 - Problem

Without a single owner for Part‑G‑wide invariants, Part G drifts in at least six recurring ways:

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

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

#G.Core:3 - Forces

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

#G.Core:4 - Solution

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

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

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

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

Routing table (normative index; no semantic duplication).

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

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

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

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

• Relations: Builds on: G.Core.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#G.Core:4.3.1 - Definitions

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

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

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

• RSCRTrigger Minimal conceptual form (notation-independent):

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

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

#G.Core:4.3.2 - Owner model

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

#G.Core:4.3.3 - Authoring rules

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

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

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

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

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

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

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

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

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

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

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

#G.Core:4.3.5 - Initial alias maps

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

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

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

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

TriggerAliasMap.G6 EvidenceGraph H3 example causes → canonical kinds:

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

#G.Core:4.4 - Default Ownership Index

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

#G.Core:4.4.1 - Definitions

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

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

#G.Core:4.4.2 - Rules

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

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

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

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

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

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

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

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

#G.Core:4.6 - Explicit non-goals

G.Core does not:

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

---

#G.Core:5 - Archetypal grounding

Tell. In Phase‑2 refactoring, G.Core is the hub that allows each G.x to become structurally predictable: (a) a short, normative “Core linkage” slice, and (b) pattern‑scoped Extensions. Universal obligations are routed to canonical owners (A.6.7 / A.15.3 / A.19 / G.0 / A.19.CHR), while RSCR causes and default ownership become typed and single-owned.

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

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

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

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

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

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

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

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

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

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

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

• Anti-pattern: Competing defaults scattered across multiple patterns.
  Avoid: Default Ownership Index; delegate duplicate statements to the single owner.

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

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

#G.Core:9 - Consequences

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

#G.Core:10 - Rationale

Universalization of Part G requires a stable “gravity center” for invariants, otherwise each pattern becomes a competing source of truth. Delegation-first routing prevents duplication and makes ownership explicit, while typed triggers and default ownership turn historically prose-driven drift into checkable, id-based structure.

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

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

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

#G.Core:12 - Relations

• Builds on:

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

• E.18 CrossingBundle (crossing visibility bundle)

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

• Used by:

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

• Constrains:

  • Part‑G authoring: no shadow specs, no silent scalarization, tri‑state guards, penalties routing, typed RSCR causes, single-owner defaults, and ID‑continuity refactors.

#G.Core:End