E.18:7 - Conformance Checklist — Unified checklist (normative)

Conformance use. This table is a catalogue of branch tests, not a default 25-item audit. Start with the ordinary selected-structure core: one selected structure, independently grounded locus values, one internal U.Transfer relation kind, and the current position, path, path slice, or valuation only when the use needs it. Apply a row only to the Solution use named by its requirement. If that use is absent, the row—or the branch-specific clause within a mixed row—is not applicable.

Activate branches from the current use. Add crossing and gate tests only for a current GateCrossing, OperationalGate, StructuralReinterpretation, or work-entry boundary. Add launch tests only for a current LaunchGate or launch claim. Add publication tests only for a current MVPK face or publication claim. Add comparison and selection tests only for a current comparator, selector, comparison, or returned set or archive. Add cycle and refresh tests only for a current loop, freshness question, edition change, or refresh use. Add assurance, guard, decision-log, evidence-lane, or replay tests only when that claim or downstream reliance is current. A profile is chosen after these branches; it can strengthen checks inside an active branch but cannot activate another branch or require its absent objects.

The whole table remains available when a use actually combines many branches. Where one CC row contains clauses from more than one branch—for example path composition and publication functoriality, or compare and launch pins—apply only the clauses for the branches that are current.

ID	Requirement	Practical test
CC-E18-01 — Single transfer relation kind	The selected structure uses exactly one relation kind `U.Transfer`. Every change to a declared `CtxState` binding occurs only between exact source and receiving positions at one `OperationalGate(profile)`; each change states its from/to values and establishing basis, with any applicable declaration, rule, and application separate. An A.6.4 retargeting with unchanged `CtxState` follows CC-E18-06-EX and does not become a crossing.	Model lint finds no auxiliary relation kinds for locality, unit, plane, edition, or tag changes; every changed binding resolves through one declared crossing and gate, while unchanged-state retargeting remains on its limited route.
CC-E18-02 — Locus kinds bind independently identified values	Loci are structure-positioned bindings to independently defined or constrained values. The current minimal locus baseline is `{Transformation, Signature, Mechanism, WorkPlanning, Work, Check, StructuralReinterpretation}`. Domain-specific species are open-world and non-exhaustive; they bind to one of these locus kinds or require an explicit E.18 update. The baseline is not a local ontology: `Transformation -> A.3.4`, `Signature -> A.6.0`, `Mechanism -> A.6.1 and E.20`, `WorkPlanning -> A.15.2`, `Work -> A.15.1`, `Check -> A.20 or A.21`, and `StructuralReinterpretation -> A.6.4 plus E.18 and A.20` when an internal constraint is current. A `Transformation` binding requires the independent `A.3.4` actuality basis. Flow arrows, adjacency, shared work, common affected referents, selected or desired structures, methods, descriptions, plans, models, evaluation results, publications, and transfers establish neither an actual transformation nor transformation composition. A work-causes-change claim cites its exact predicate and case facts; any production-work, identity-inception, or completion claim cites a separate local `A.15.PROD` claim. A morphism expression is a mathematical-lens view when current, not the FPF kind of every locus.	Type registry shows at least the listed locus kinds; additional species map to one of them; checks are realized as `OperationalGate` when a gate or check locus is present (see CC-E18-06-EX and CC-E18-11). For each `Transformation` and adjacent `Work` or production assertion, the `A.3.4` occurrence basis and any work-to-change or `A.15.PROD` claim reference resolve; no inference rests on structure membership or proximity. Lint: registry table exposes `{species -> {locusKind, definitionOrConstraintRef}}`; a missing or mismatched definition or constraint fails.
CC-E18‑03 — Identity, composition, functorial faces	Identities exist and path composition is associative. When the E.17 morphism profile is used and a face claims compositional publication, `Emit_s(t₂∘t₁)=Emit_s(t₂)∘Emit_s(t₁)`.	Check identity and path composition under the current structure description. For the claimed compositional face, compare emission of a two-step composition with composition of its emitted faces; ordinary publication adds no such witness.
CC-E18-04 — Structure spec	Spec declares `tau_L`, `tau_Transfer`, `Gamma_time`, `CrossingRefs`, and exact transport-registry refs when transport conversion is current.	Spec file shows typed structure refs and Gamma policy; no Bridge or penalty is inferred from the tuple.
CC-E18‑05 — CtxState pins	`CtxState=⟨L,P,E⃗,D⟩` is pinned on ports and tokens; raw `U.Transfer` does not write or update it.	Along a raw transfer, ⟨L,P,E⃗,D⟩ is preserved.
CC-E18-06 — Operational gates only	Any write or update to a member of `CtxState`, including a design-to-run tag change on a prospective work-entry claim, is mediated by `OperationalGate(profile)`. When that gate makes a decision, its A.21 `GateDecisionResult` cites the exact profile application and independently identified check-application results; an optional `DecisionLog` is separate. The gate neither creates a Work occurrence nor writes values into one.	Diff CtxState across transfer relations; if any member differs, exactly one gate exists. Resolve its current decision result when a decision is made, and separately verify any later Work occurrence under A.15.1.
CC-E18-06-EX (strictly limited) — Retargeting without a structural crossing	A `StructuralReinterpretation` is recorded without `OperationalGate` only when an exact A.6.4 arrow r, affirmative bounded-use assertion q, and current-case judgement of `satisfies` are current, `CtxState` is unchanged, and the use is `PathSliceId`-local. Apply A.20 only when q also raises a current internal-constraint check. A semantic Bridge, if current, is tested separately under F.9 and its own bounded-use claim; neither a card, UTS row, optional `CL`, nor publication supplies q’s polarity or the case judgement.	Resolve r’s endpoints and identity, q’s proposition, the exact current facts and `satisfies` result, unchanged `CtxState`, and path-slice locality. Keep any optional A.20 result, operation application, Work, Bridge, evidence, reliance, or gate decision separate.
CC-E18‑07 — Independent gate-check results	Every applicable check result remains independently recoverable. An unsatisfied or incomplete A.20 input affects the A.21 aggregate under the current gate rule but does not make another applicable check inapplicable. Deferred required checks remain `notRun`.	Simulate an A.20 violation while freshness succeeds and channel fit is unknown; all three results remain visible and the aggregate follows the gate rule.
CC-E18-08 — LaunchGate discipline (when current)	When the selected structure assigns a `LaunchGate` to one prospective `workEntryClaimRef` consumed by `USM.LaunchGuard`, the gate decision concerns that attempted entry, not a future Work individual. Its exact current profile application selects the required checks and mappings. `FreshnessUpToDate`, `DesignRunTagConsistency`, and an ingress A.20 summary appear only when their own current claims and rules require them. If that profile maps a non-satisfied required ingress summary to a pre-run barrier, the result is `block`; every independently available result remains visible and every deferred required check remains `notRun`.	Resolve the prospective claim, assigned gate, current profile application, complete required set, mappings, and action consequence. Do not infer a later Work or any absent freshness, tag, ingress, crossing, or SquareLaw check.
CC-E18-09 — MVPK publication discipline	Every published locus uses MVPK. Faces carry `PublicationScopeId` and the source references, presence pins, and edition ids required by the selected face and use; compare and launch faces additionally pin `Gamma_time`. Faces add no new claims or hidden arithmetic. In the optional morphism profile, they reference signature-side Input and Output declarations rather than duplicate them. `Signature` names only an actual signature; face labels use `TechName` or `PlainName`.	Resolve the source and applicable pins, check that every displayed claim is source-backed, and apply input/output non-duplication only to the morphism profile. An actual signature citation or a source-backed mathematical expression is not a naming or publication violation.
CC-E18‑10 — Normalize→Compare (CSLC)	Any comparison cites UNM and `CG-Spec` editions and `ComparatorSetRef`; ordinal claims are compare-only; partial orders return sets; edition-aware set or archive publications pin `{DescriptorMapRef, DistanceDefRef, CharacteristicSpaceRef?}.edition` to exact versioned values and editions. Edition citation alone requires no Bridge Card or UTS row. NoHiddenScalarization: return shape is set or poset, comparator ref is edition-pinned, faces add no numeric claims, and any summary preserves the declared order.	Faces resolve the comparator and every edition-pinned value; set-return and no-scalarization checks pass.
CC-E18-11 — Structural crossings grounded	Every GateCrossing resolves its exact source and receiving positions, one per-binding account for each changed `CtxState` binding, one A.21 `OperationalGate(profile)`, and `CrossingRef`. The `GateDecisionResult`, optional `DecisionLog`, permission claim, semantic F.9 Bridge and bounded-use claim, reliance, optional card, optional `CL`, and any independent penalty policy remain separate.	Resolve each account’s binding id, from/to values, establishing facts or claims, and any applicable declaration, rule, and current application. If a required item is missing, name that item and stop; do not substitute a gate decision, permission, Bridge/card/CL, or policy publication.
CC-E18‑12 — Set‑returning selection	The selection-and-tuning locus cites the exact current selector and comparator definitions; their obtaining selection relation returns a set or archive under the declared comparator (`ParetoOnly` by default), with no covert scalarization.	The returned entity is the exact set or archive produced by that selector relation, and the selector relation plus policy id resolve; no flow-position or `output` label supplies that result.
CC-E18‑13 — Budgeted Selection↔Planning loop	The loop declares budget and max_iter. On expiry the exact selector relation returns its declared partial-optimal set or archive outcome. Any next-step tuning is carried by a separately identified `U.WorkPlan` with any declaration-local A.15.3 planned-filling rows, or by a separately identified configuration or policy that passes its own applicable rule; any publication cites the exact value and edition published, and any next `PathSlice` cites the exact planning or refresh rule used.	The selector relation, budget stop, returned set or archive, optional publication, and explicit next-slice continuation resolve; no tuning entity or independent plan-item relation is fabricated as a selector return.
CC-E18-14 — UNM before loop and freshness request planning	UNM runs before selection and states the exact missing-or-stale-measurement finding. A plain freshness request asserts no plan. When refresh planning is current, G.11 and A.15.2 separately identify `RefreshPlan@Context` as one exact `U.WorkPlan`; any A.15.3 planned-filling rows remain declaration-local content inside it. Later dated Work, measurement, calibration, and any G.11 `RefreshReport@Context` remain separate.	The UNM finding resolves; when current, the exact refresh request, plan, later Work, measurement, calibration, and report resolve separately. No request label, ticket, plan, performed-work record, refresh report, or publication is treated as another one of those objects or as the returned world-side result.
CC-E18-15 — Actual launch facts and finalization witness	A gate or plan never fills launch-value slots in Work. After one exact Work occurrence exists, actual launch values are established only by independently obtaining direct relations or exact A.6.1 bindings. A separate `FinalizeLaunchValues` episteme may designate the Work occurrence and those facts; it is a witness, not an act performed by Work and not a field bundle inside it.	Pre-run attempts to claim actual values block; the later witness cites the exact Work occurrence and every obtaining relation or binding used, and remains a separate episteme.
CC-E18-16 — Guard aggregation assignment and semantics	`USM.CompareGuard` and `USM.LaunchGuard` publish the gate assigned to aggregate guard failures; guards are events, not check applications. When the current profile application consumes a failure, the identified event, mapping, and consequence remain in the A.21 result and rationale; an optional `DecisionLog` may cite them.	Guard pins show the assigned gate; any consumed `GuardFail` resolves to its check application and mapping without becoming the check result itself.
CC-E18‑17 — Assurance ops on Transfer	On `U.Transfer` only `ConstrainTo`, `CalibrateTo`, `CiteEvidence`, and `AttributeTo`; none write or update `⟨L,P,E⃗,D⟩`.	Edge audit shows ops; CtxState unchanged across the edge.
CC-E18-17a — Assurance operation specifications (normative)	`ConstrainTo` tightens a declared region or policy; `CalibrateTo` attaches an editioned calibration ref; `CiteEvidence` cites identified evidence; `AttributeTo` cites provenance. Each preserves `CtxState`, adds no gate decision, and cites the rule, calibration, evidence relation, or provenance relation it uses. Plane, unit, edition, or locality changes are forbidden on raw transfer. Any penalty needs a current policy, evidence that it applies, the rule application, and any separately needed authority relation with its participants; it never follows from `CL`.	Operation audit resolves those values and relations and confirms unchanged `CtxState`; hidden crossing or unsupported penalty fails.
CC-E18-18 - Flow = valuation, one-TFS unity, and slice-local refresh	Each flow declares valuation `nu` over internal `U.Transfer` occurrences plus `PublicationScopeId` and `PathSliceId`. Several valuations may share this E.18 structure only when they resolve to the same TFS and structural boundary; valuation, path, slice, state, reader-facing label, or `DesignRunTag` differences do not reidentify it. Refresh stays within the addressed slice, and affected faces are re-emitted on edition change or the selected refresh rule. Independently identified TFS values and their cross-boundary relation leave this case for `E.18.NET`.	Confirm that every valuation names the same TFS and only its internal transfer occurrences. If member identities or a cross-boundary relation are required, preserve the member TFS values and cite the relation predicate and occurrence rule through `E.18.NET`; do not use `U.Transfer` as the edge.
CC-E18-18a - Position and subflow reference identity	Every `FlowPositionRef` is `<TFS ref, local position id>`. Every `SubflowRef` names one exact parent, included positions, already obtaining parent-internal transfer occurrences, and boundary positions, all resolving in that parent. Valuation, slice, tag, filling, graph, description, publication, and view stay outside both reference identities; the tuple introduces no generic containment or membership relation.	Resolve each ref back to one parent TFS. A coffee-preparation portion remains a subflow while all positions and transfers resolve there. A separately identified heating TFS plus an exact relation is not a subflow; preserve it as a separate member and apply `E.18.NET` to select the network and cite that relation.
CC-E18-19 — Γ_time on compare and launch	Every current compare or launch publication face pins `Γ_time`; no implicit latest.	Face audit shows the pin. A stale result changes the gate only through the exact applicable check and current profile mapping.
CC-E18-19a — Γ_time pin shape (normative)	The `Γ_time` pin is `snapshot(t)`, closed `interval[t1,t2]`, or `policy(Γ_timeRuleId)` resolved to one of those. An A.20 result records its evaluation window; when A.21 consumes it, the `GateDecisionResult` cites that result and the resolved gate time without widening either. A current publication or optional `DecisionLog` cites the same values.	Resolve the A.20 evaluation window and gate-time reference; reject missing, implicit, or widened time.
CC-E18‑20 — Lean publish‑mode ≠ weaken	`AssuranceLane‑Lite` changes publication faces only; required GateChecks for the active profile remain intact.	Gate in Lean or Core shows minimal pins; GateChecks list unchanged.
CC-E18-21 — Decision stability and optional equivalence witness	Recompute a gate decision when any A.21 result input changes. Require an equivalence witness only for a current reuse, cacheability, or stability claim; it covers every input whose equality that claim needs.	Change the profile application, required set, checked subject, criterion, case, source result, mapping, scope, or window. The old result is not reused; a claimed reuse without a sufficient witness fails.
CC-E18-21a — Decision join	After every required check application is present and explicitly mapped, A.21 joins the mapped values under `abstain <= pass <= degrade <= block`. Applicability, `notRun`, `unknown`, error, and source-result failure remain distinguishable before mapping. The `GateDecisionResult` carries the aggregate, rationale, and action consequence; an optional `GateDecisionExplanation` carries no decision value.	Review a gate with multiple checks: every source result and applied mapping is recoverable, the aggregate matches the order-independent join, and no missing or unrun required result disappears as `abstain`.
CC-E18-22 — Source uncertainty maps under the applied rule	Error, timeout, `unknown`, and `notRun` remain explicit source states. The exact current profile application cites the mapping rule and edition for each applicable result; profile labels provide no fixed fold.	Change the mapping rule or its edition and recompute the decision. Verify that no unknown or unrun required result becomes `pass` or neutral `abstain`.
CC-E18-23 — SquareLaw when required by the crossing rule	For a GateCrossing whose exact current rule requires the commuting-square condition, test `gate_out o transfer = transfer' o gate_in`. A `LaunchGate` does not activate this check unless it is also that governed crossing case.	Resolve the crossing rule and its application. When it requires SquareLaw, a mismatch maps under the current profile rule; otherwise no SquareLaw check or witness is added.
CC-E18‑24 — UNM declaration locus	`CG‑Spec`, `ComparatorSet`, `UNM.TransportRegistryΦ` editions are declared only at the UNM declaration locus (others ref‑only).	Declaration records show UNM as the declaration locus; others have refs only.
CC-E18-25 — Evidence lanes and optional audit records	When an AssuranceLane publishes a gate decision, it cites the `profileApplicationRef`, identified check-application result refs, edition pins, and `GateDecisionResultRef`. Add `DecisionLogRef` only for a current audit, history, replay, or reuse record. When evidence is current, carriers are pinned through `SCR` and `RSCR` and value annotations use `VALATA (VA, LA, and TA)`.	Published refs resolve to the exact A.21 result and current profile application; absent audit or evidence claims create no empty log or evidence apparatus.

Coupling note. CC-E18‑07 preserves the independent source results that CC-E18‑21a maps and joins. Evaluation order may save work, but it cannot change applicability or erase a deferred required check. Scope note (E.18 vs neighboring pattern contributions): Use the definitions, constraints, and tests named in this pattern’s Relations for mechanism-specific checks and publication obligations. E.18 fixes only selected-structure obligations: single U.Transfer relation kind, gate crossings, valuation, publication pins, separation between internal constraint results and profile-fit results, and slice-local refresh.

Glossary (additions)

Open-world species - non-exhaustive domain-scoped locus specializations that map to the minimal locus baseline and name the pattern content that defines or constrains them.
Signature locus - structure-positioned use of A.6.0 U.Signature (universal block). It is an independently defined value bound into the selected structure, not a local kind and not a C.3.2 KindSignature.
KindSignature (C.3.2) - definition of a U.Kind by intent, extent, and formality; unrelated to E.18 locus kinds; never a genus.
Species (domain-scoped) — typed specialisations speciesOf(kind=...) that declare KindDefinition=<pattern id for the current definition> (e.g., kind=Mechanism; KindDefinition=A.6.1).
Semantic Bridge boundary — F.9 defines and tests an obtaining semantic relation between two exact F.17 cells. A structural crossing or A.6.4 retargeting does not imply that relation; a Bridge Card and CL are optional episteme/evidence apparatus.
Eulerian interpretation - operational stance where a flow is treated as a valuation over U.Transfer and transfer relations perform assurance-only operations (no token-passing semantics).
GateCheckKind boundary. GateCheckKind is a recognition label within one identified A.21 check application, not a structure locus kind and not enough to identify or merge results. No such label becomes an E.18 Check locus unless an OperationalGate(profile) locus is actually present.
GateCheckRef boundary. Where a publication face over a selected structure carries a GateCheckRef, that value refers to one exact A.21 GateCheckApplicationResult. It must resolve the checked subject, criterion and edition, applicable rule application, case, scope, and window; the old {aspect, kind, edition, scope} projection is insufficient.
GateDecision, GateDecisionRationale, and GateDecisionExplanation (terminology).
- GateDecision - the lattice value inside one A.21 GateDecisionResult, derived from one exact profile application and its complete required set of identified check-application results.
- GateDecisionRationale - the structured rationale inside that result: retained source outcomes, explicit mappings, aggregate, and action consequence. A current publication or optional DecisionLog may cite it; neither supplies the rationale or decision.
- GateDecisionExplanation — an optional human-readable narrative derived from the rationale; it carries no decision value. It may explain any retained result and mapping, including why an A.20 input prevented passage; absence of a narrative does not make a check inapplicable.

Clarity note. GateDecision ≠ GateDecisionExplanation; narratives are optional and derivative of GateDecisionRationale.

GateFit (aspect, not an entity). GateFit names the aspect of checks that evaluate profile‑fit; there is no separate GateFit entity. “Gate decision under GateFit” means “the gate’s decision computed from GateChecks with aspect=GateFit”.

This shape is publication-only; it introduces no new execution steps and no arithmetic on faces. (Couples to A.20 or A.21 without duplicating their check catalogs.)
VALATA (VA, LA, and TA) — value-annotation scheme used on AssuranceLane; carriers are referenced via SCR and RSCR; detailed evidence obligations use the definitions and tests in A.10 and the named evidence, publication, or crossing pattern for the current case. Included here so evidence pins are self-describing in Part E texts.
Transfer vs Transport - Transfer = the sole relation kind U.Transfer in the selected structure. Transport = conversions defined by Phi policies and registries (TransportRegistry^Phi) referenced by UNM; “reuse via Transport” refers to the latter.
GateCrossing - an E.18 structure-local transition between exact source and receiving position/state bindings at one exact gate whose profile and decision test come from A.21; it is not a semantic Bridge or gate decision.
Admissible path - a typed path obeying the GateCrossing discipline: no hidden crossings, every witness required by an exact current crossing rule is present, compare and launch publication faces are Gamma-pinned when present, and T^D<->T^R occurs only at LaunchGate; see S2.