E.20:7 - Conformance Checklist (normative)

Conformance use. This checklist tests the governing-definition assignment guidance already stated in the Solution. It is not the first entry text for ordinary use or a mandatory full-corpus check; an item is applied only when its corresponding trigger triage, manifest, declaration target, suite, planning, wiring, lexical, RSCR, PQG, or deprecation move is present. Before applying any item, name the Solution guidance it tests; if no such reader use is present, treat the item as orientation-only or not applicable rather than expanding the applied assurance material.

Conformance groups. Ordinary E.20 use starts with trigger triage and stops at the current governing locus when no denotation or mechanism-meaning change is present. Manifest-core items apply only when a MIP-run is actually triggered. Publication and assurance items apply only when citeability, reference-reservation stubs, alias docking, RSCR, PQG, or deprecation continuity is part of the current claim. Crossing, launch, and work-enactment checks are not governed by E.20; if those claims become present, use the gate, planning, or work loci and keep E.20 to governing-definition assignment.

ID	Requirement	Purpose
CC-E20-0 (MIP trigger triage).	Every proposed mechanism, suite, planned-baseline, wiring, governing-definition, or citeable-token edit is classified as `MIP not triggered`, `local wording or alias-docking only`, or `MIP-run manifest required` before E.20 is cited to start a MIP-run.	Prevents pure currentness cleanup from becoming a false runtime gate or expanded authoring event.
CC-E20-1 (Governing-definition assignment declared).	Every MIP-run SHALL provide a MIP-run manifest that lists each changed item, exactly one governing definition, and the canonical location; each changed item SHALL be written in that canonical location.	Prevents “floating commitments” and semantic placement errors.
CC-E20-2 (Resolvable mechanism target).	Every `MechanismDefinitionRef` resolves either to an explicitly non-mechanism reservation stub or to an introduced A.6.1 `U.Mechanism` episteme. Only the latter fills admitted mechanism positions.	Eliminates dangling references and card-form semio-bias.
CC‑E20‑3 (Suite discipline preserved).	If a suite is edited, it SHALL preserve: membership set semantics, protocol closure, no hidden tails, no gate decisions/logs, no publication records.	Prevents suite-as-gate and suite-as-mechanism drift.
CC-E20-4 (Shared operation-member vocabulary preserves declaration locality).	If a suite or family claims shared operation, argument, or result vocabulary, one citeable shared locus SHALL name its exact member declarations, and every member SHALL still define its own A.6.1 operation members and binding semantics. Equal spelling or a shared-term citation imports no declaration member or actual binding.	Prevents vocabulary drift without collapsing declaration-local semantics into a suite lexicon.
CC-E20-5 (P2W planning-to-work boundary preserved).	If a planned baseline is edited, its rows SHALL remain declaration-local content inside one exact `U.WorkPlan` (only pins and references), SHALL target exactly one Description-scoped slot-bearing description via `target_slot_bearing_description_ref` (and SHALL NOT target a `MechanismDefinitionRef`), and SHALL NOT contain enactment witnesses, launch values, or gate decisions. No row has an independent identity or edition.	Keeps planning and enactment distinct and replayable.
CC‑E20‑6 (Kernel stability handled).	If a kernel suite would gain a new required stage, the change SHOULD be expressed as a suite variant; if mutation occurs, it SHALL include continuity measures (alias docking and explicit delta).	Minimizes E.15 impact radius of kernel edits.
CC‑E20‑7 (SoTA wiring, not kernel semantics).	Method/comparator choices SHALL be represented via SoTA packs and wiring modules; if a SoTA update changes mechanism semantics, that change SHALL be made in the mechanism-subject pattern and not by wiring.	Prevents silent semantic shifts.
CC‑E20‑8 (Terminology continuity).	Any rename changing citeable tokens SHALL use alias docking and register updates; silent rewrites are non‑conformant.	Preserves reference stability.
CC‑E20‑9 (RSCR triggers + regressions).	A triggered MIP-run that changes semantics or citeable references SHALL emit RSCR triggers and extend the regression envelope over its affected reference, suite, guard/gate, or planned-baseline uses under E.20:4.10.	Makes changed loci and regression obligations explicit and testable.
CC‑E20‑10 (PQG coverage).	Every MIP-run SHALL be reviewed under PQG (E.19) with PCP‑BASE and the triggered profiles implied by the change.	Normalizes review and refresh.
CC‑E20‑11 (Deprecation preserves citeability).	Any deprecation, supersession, or retirement action SHALL preserve citeability of the deprecated token. Affected mechanism epistemes, reservation stubs, suite descriptions, WorkPlan editions, wiring modules, and public locators or aliases remain independently resolvable where applicable and state the direct successor relation or its absence under E.20:4.9.1. A planned-filling row has no independent resolvability, edition, or successor obligation; its local-content locator resolves only through the exact WorkPlan edition.	Prevents broken citations and orphaned semantics without reifying WorkPlan-local content.