| CC‑G3‑CoreRef | G.3 is conformant only if the applicable G.Core obligations declared in G.3:4.1 are satisfied (effective expansion of profiles/sets + deltas; explicit pins; typed RSCR triggers; defaults with one governing definition). |
| CC‑G3‑01 | CHR Pack@CG‑Frame is published as a notation‑independent kit payload with the minimum exported objects listed in G.3:4.2. |
| CC-G3-02 | Every CHR.Characteristic names its exact characteristic and scale editions, its bearer as the entityOfConcern, claim scope and applicable slices, any applicable qualification and evaluation windows, ReferencePlane, method or model edition when it affects interpretation, evidence refs, intended downstream use, and a filled ObservableOf field (instrument or protocol, uncertainty model, and validity window). |
| CC‑G3‑03 | Every CHR.Characteristic declares its ScaleRef, Polarity, and UnitSet (or an explicit “unitless” declaration), plus bounds/zero semantics where applicable. |
| CC‑G3‑04 | Missingness is typed in the CHR artefacts such that downstream tri‑state handling is possible without silent coercion. (Tri‑state semantics are governed by G.Core; the typing obligation is CHR‑local.) |
| CC‑G3‑05 | CHR.Scale / CHR.Level artefacts encode the scale type and admissible transforms, and make illicit arithmetic checkable by downstream consumers. |
| CC‑G3‑06 | Any published CHR.Coordinate includes a CoordinatePolicy that states preserved invariants and explicit non‑entitlements; coordinates do not silently upgrade measurement structure. |
| CC‑G3‑07 | CHR.LegalityMatrix and CHR.Guards exist and are referenced by downstream operator authoring; semantics are governed by cited definitions (MM‑CHR and G.Core), not duplicated locally. |
| CC‑G3‑08 | CHR.AggregationSpecs are typed and legality‑constrained; where Γ‑fold is required and no explicit override is pinned, cite DefaultId.GammaFoldForR_eff through G.Core.DefaultGoverningDefinitionIndex. |
| CC‑G3‑09 | If any characteristic is intended for promotion into CG‑Spec, the linkage is explicit and edition‑pinned (no shadow ids). (Governing definition: G.0; wiring via G.3:Ext.CGSpecPromotionWiring.) |
| CC‑G3‑10 | UTS Name Cards exist for public ids minted or evolved by the CHR pack (twin labels plus public-id continuity notes). (Delegation target: CC‑GCORE‑UTS‑1 via CC‑G3‑CoreRef.) |
| CC‑G3‑11 | Worked examples and RSCR tests exist and cite PathId/PathSliceId; they cover illegal‑op refusal, unit and scale constraints, polarity invariants, and coordinate non‑entitlements. |
| CC‑G3‑12 | Thresholds/guard‑bands are not embedded in CHR artefacts; they remain governed by CAL acceptance clauses (G.4). |
| CC‑G3‑13 | When method‑role declarations are present (via RoleDecls and/or QD.Role alias), each declaration is docked to its governing pattern via a corresponding G.3:Ext.* module, and the edition and policy pins required by the governing pattern are surfaced to make downstream interpretation reproducible. (QD/OEE governing patterns: C.18 and C.19; wiring via G.3:Ext.QD_OEE_Wiring.) |
| CC‑G3‑14 | Evidence wired. Each CHR.Characteristic links to R‑anchors via PathId/PathSliceId (and, where applicable, A.10 anchor/carrier refs), so downstream evidence discipline (G.6) can audit legality and guard claims. |
| CC‑G3‑15 | An Archetypal Grounding section exists with at least two domain‑distinct examples that demonstrate lawful CHR typing/legality and the CHR↔CAL separation (notably: no thresholds in CHR). |
| CC‑G3‑16 | If EvidenceLanes are used, lane tags are declared with a citation to their governing pattern taxonomy (B.3), and any lane‑dependent tolerances/proof requirements are explicitly pinned (policy‑id / edition refs). Cross‑lane comparison/aggregation is illegal by default unless an explicit governing-pattern policy makes it lawful (typically G.4), and it must be auditable via evidence paths (G.6). |
| CC‑G3‑17 | If the CHR outputs are bound into the planned baseline / suite seam, the binding uses CHRMechanismSuiteSlotFillingsPlanItem as defined in A.19.CHR + A.15.3 (no local baseline variants; wiring via G.3:Ext.SuiteBoundaryLinkage). |
| CC‑G3‑18 | Freshness is explicit. Each CHR.Characteristic declares a validity window and either (i) an explicit NonDecayingDecl or (ii) a freshness/half‑life statement that is pinned to the governing pattern (B.3.4) when policy‑bound (G.3:Ext.DecayWiring). Changes in decay windows/policies participate in RSCR via canonical trigger kinds declared in G.3:4.1. |