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 (including WorkPlan refs and their local planned-filling row designators when the chassis is bound into WorkPlanning)

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