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

Preface node heading:g-core-7-conformance-checklist-normative-cc-gcore:76383

What this page is

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

Methodology

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

Content

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

ConformanceIdStatement
CC‑GCORE‑DEL‑1A conforming G.Core SHALL be delegation-first: if a norm is already governed by A.6.7, A.15.3, A.19, G.0, A.19.CHR, or a relevant Part E pattern, G.Core cites that governing definition rather than duplicating semantics.
CC‑GCORE‑CN‑CG‑1Any pattern in Part G that builds on G.Core SHALL cite CN‑Spec and CG‑Spec as the only spec-legality surfaces and SHALL NOT introduce shadow specs (incl. complying with SuiteObligations.transport_declarative_only and SuiteObligations.cg_spec_cite_required_for_numeric_ops).
CC‑GCORE‑OBL‑1A conforming G.Core SHALL treat the obligation vocabulary in A.6.7:4.2 as the canonical naming surface for Part‑G‑wide obligations and SHALL NOT introduce competing obligation names for the same norms.
CC‑GCORE‑CROSS‑1A Part‑G pattern that introduces or consumes crossings SHALL enforce SuiteObligations.bridge_only_crossings and SuiteObligations.crossing_visibility_required (CrossingBundle per E.18); SHALL prohibit implicit crossings; SHALL treat edition_key changes on crossing‑relevant artefacts (Bridge/CL/CrossingBundle registries and UTS rows for crossing artefacts) as RSCRTriggerKindId.CrossingBundleEdit (and, when an edition pin is involved, also RSCRTriggerKindId.EditionPinChange per multi‑cause discipline); and SHALL cite SuiteObligations.two_bridge_rule_for_described_entity_change through its canonical governing definition.
CC‑GCORE‑GUARD‑1A Part‑G pattern SHALL treat `GuardDecision := {pass
CC‑GCORE‑PEN‑1A Part‑G pattern SHALL route penalties/assurance loss to the R lane (R_eff) only (SuiteObligations.penalties_route_to_r_eff_only) and SHALL preserve F/G invariants under penalties (penalties do not alter legality/invariant lanes).
CC‑GCORE‑SET‑1A Part‑G pattern SHALL preserve set-return semantics for partial orders and SHALL prohibit silent scalarization/totalization (SuiteObligations.no_silent_scalarisation_of_partial_orders, SuiteObligations.no_silent_totalisation); any scalar summary SHALL be report-only unless declared as a admissible comparator surface.
CC‑GCORE‑SKP‑1A Part‑G pattern SHALL preserve the suite/kit/pack distinction (A.19.CHR) and SHALL keep shipping concerns governed by their canonical governing patterns (e.g., G.10) rather than embedding shipping semantics into unrelated kits or core invariants.
CC‑GCORE‑P2W‑1A Part‑G pattern that uses planned baselines SHALL anchor them via SlotFillingsPlanItem in WorkPlanning (SuiteObligations.planned_slot_filling_in_work_planning_only) and SHALL finalize launch values only in WorkEnactment (SuiteObligations.finalize_launch_values_in_work_enactment_only); gate decisions remain separated per SuiteObligations.gate_decision_separation.
CC‑GCORE‑LINK‑1Every conforming G.x SHALL satisfy G.Core:4.2 by providing a G.x:<n> - G.Core linkage (normative) section containing a GCoreLinkageManifest (incl. either CoreConformanceProfileIds or CoreConformanceIds, either RSCRTriggerSetIds or RSCRTriggerKindIds, and either CorePinSetIds or CorePinsRequired (or both)). Nil‑elision is permitted for fields.
CC‑GCORE‑LINK‑2Every conforming G.x SHALL include CC‑Gx‑CoreRef as the first checklist item; it SHALL make mandatory the effective CoreConformanceIds (including expansions of any CoreConformanceProfileIds) declared in the linkage manifest.
CC‑GCORE‑UTS‑1If a Part‑G pattern mints, deprecates, or evolves any public identifier, it SHALL publish/update the corresponding UTS entries and cite them via UTSRowId pins, delegating UTS semantics (twin labels, alias/deprecation discipline, edition pins) to its canonical governing definition F.17 (UTS).
CC‑GCORE‑ID‑1When deduplicating, existing public CC ids in G.x SHALL NOT be deleted/renamed; they SHALL become delegation items to relevant CC‑GCORE‑… items.
CC‑GCORE‑ID‑2Public id continuity applies beyond CC item ids: UTSRowId rows, RSCRTriggerAliasId tokens (e.g., T0…T7), deprecation notices, and edition bumps SHALL preserve prior ids and express drift via alias/deprecation/edition evolution (never by reusing/redefining an old id). When downstream behaviour can change, the change SHALL emit a canonical RSCRTriggerKindId (e.g., TokenizationOrNameChange, EditionPinChange).
CC‑GCORE‑TRIG‑1A conforming G.Core SHALL define the canonical RSCRTriggerKindId catalogue and SHALL be its single writer.
CC‑GCORE‑TRIG‑2Any G.x that uses local trigger tokens SHALL provide (or cite) a TriggerAliasMap mapping each alias to canonical RSCRTriggerKindId.
CC‑GCORE‑TRIG‑3Any artefact that records RSCR/SCR/refresh reasons SHALL record canonical RSCRTriggerKindId (aliases may be recorded as labels only).
CC‑GCORE‑TRIG‑4A conforming G.Core SHALL keep TriggerAliasMap.* consistent with the governing patterns’ deprecated trigger alias catalogues (e.g., G.11:T*). Any change to an alias mapping SHALL be treated as refresh‑sensitive; at minimum it SHALL be recorded/emitted as RSCRTriggerKindId.TokenizationOrNameChange (and, if the mapped trigger kinds change, the corresponding canonical kinds apply as well).
CC‑GCORE‑DEF‑1A conforming G.Core SHALL maintain a Default Governing Definition Index for Part‑G defaults, ensuring each DefaultId.* names exactly one governing definition (a CC item or a policy id). All other patterns SHALL cite the governing definition and SHALL NOT state competing defaults. Any governing-definition change MUST be recorded as RSCRTriggerKindId.DefaultGoverningDefinitionChange.

Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)