#U.Flow.ConstraintValidity — Eulerian

A.20 · Stable · Architectural (A) · Normative for flow valuations used by E.18 TransformationFlowStructure under the Eulerian operational interpretation. · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Architectural (A) Status: Stable Normativity: Normative for flow valuations used by E.18 TransformationFlowStructure under the Eulerian operational interpretation.

Tech-name. U.Flow.ConstraintValidity (U.Flow genus) Plain-name. Flow constraint validity (Eulerian interpretation)

One‑liner Defines cross-cutting ConstraintValidity rules for flow valuations used by E.18 TransformationFlowStructure. Transformation-flow loci may refine CV class specializations for locus-specific semantics (species-binding only; genus rules remain unchanged). The CV core is locus-kind-agnostic and assumes an open-world catalogue of locus species; the enumeration of locus kinds in E.18 is a minimum locus baseline.

#Keywords

• flow
• ConstraintValidity
• Eulerian
• TransformationFlowStructure
• GateFit
• MVPK
• SquareLaw
• Sentinel
• PathSlice.

#Relations

#Content

#Intention

One‑liner Defines cross-cutting ConstraintValidity rules for flow valuations used by E.18 TransformationFlowStructure. Transformation-flow loci may refine CV class specializations for locus-specific semantics (species-binding only; genus rules remain unchanged). The CV core is locus-kind-agnostic and assumes an open-world catalogue of locus species; the enumeration of locus kinds in E.18 is a minimum locus baseline.

Operational interpretation. Eulerian interpretation: flow = valuation over U.Transfer; CV is attached to transformations (steps) and evaluated before any GateFit; edges carry assurance‑only operations; no token‑passing semantics are assumed.

Use this when. Use A.20 when the question under repair is whether one transformation step internally satisfies its declared constraints before any GateProfile fit is evaluated. First useful move. Name the step, the CV class being checked, the CV.Status, and the witness or missing witness. Stop there unless a gate, comparator, bridge, freshness, or work-boundary question is actually being made.

Smallest sufficient CV guidance. Use the lightest CV guidance that preserves the next practitioner move made available by the local CV result. Add publication lexemes, witnesses, DecisionLog detail, CrossingBundle, PQG, RSCR, or MIP-run material only when the CV claim being made would otherwise become false, unsafe, non-replayable, or lack a named governing-definition locus.

Minimum sufficient next move. For ordinary CV, step + CV class + CV.Status + witness or refusal is enough. Per-check publication lexemes are needed only when the CV result is carried into a publication face, gate relation, or assurance material.

Do not escalate when. Do not create GateDecision, GateDecisionExplanation, GateFit narrative, comparator law, bridge law, freshness claim, release-confidence claim, or work-boundary authority from CV.Status. Use the neighboring pattern relation only when its own claim is present.

Conformance-marker overread note. Use this note when a conformance label, CV.Status=pass, release-screen status, dashboard cue, or CV-looking publication is being interpreted as gate passage, release confidence, safety acceptance, assurance, work occurrence, work authorization, or performed work. The first A.20 move is to return to the local step, CV class, CV.Status, witness or refusal, and window governed here; then state the attempted stronger use without a governing relation and name the governing neighboring relation only if that relation is being claimed: A.21 for gate decision, B.3 for assurance, A.10 for evidence or currentness, A.15 for work, or the neighboring pattern governing that claim. Write CV.Status=pass when CV is meant; do not write plain pass near gate, release, safety, or work use. Plain wording remains ordinary unless it changes bounded CV use, source relation, evidence, gate, assurance, work, decision, or neighboring-pattern relation.

Common wrong interpretation. CV.Status=pass means release, safety acceptance, or gate passage. First honest entry: CV.Status is local step constraint validity with witness or refusal; release, safety, gate, assurance, or work use belongs to its governing pattern only when that claim is present.

Repaired anti-case: a manufacturing conformance label near release may carry only the local CV or conformance relation it actually records. If release permission, safety acceptance, or work authorization is attempted, state the attempted stronger use without a governing relation and name and use the governing relation for that attempted claim rather than treating the label as release authority.

Same problem, different question under repair. For a transformation-flow-looking problem, use E.18 for graph value, flow valuation, or crossing relation, A.20 for internal step validity, A.21 for gate-decision publication, and E.20 for mechanism-meaning placement; do not apply the other three until their own claim is present.

Semantic repair return. When A.20 blocks a misleading word, face, alias, or source label, the repair must return to the enabled CV action: name CV.Status, the applicable CV class, and the witness or refusal available for the local CV use. Do not stop at a classification of vocabulary or publication faces.

Locus and relation separation. Keep the graph value and graph path or crossing relation (E.18), MVPK publication faces (E.17), internal CV status and witness (A.20), gate decision and DecisionLog (A.21), evidence or provenance relation (A.10 or G.6), work plan or work occurrence (A.15), and mechanism-governing definition assignment (E.20) distinct. An MVPK face, DecisionLog, evidence value, MIP manifest, or work witness does not carry another pattern's project-side value unless that governing pattern consumes it for that relation.

Smallest affected locus. Localize the change to the smallest locus for the claim being made: PathSlice or crossing in E.18, CV step in A.20, GateDecision equivalence class in A.21, or mechanism-governing definition in E.20. Do not widen to a whole flow or unrelated flow, PathSlice, CV, gate, or mechanism-definition locus when the smaller locus is enough.

Ordinary success. For ordinary A.20 use, success is that the applicable CV class, CV.Status, and witness or refusal are placed for the step without implying gate passage, comparator-use claim, freshness, or launch readiness. A full conformance review is needed only when the consuming neighboring claim uses expanded assurance or conformance material.

Locality asymmetry. E.18 is graph-local, A.20 is step-local, A.21 is gate-local, and E.20 is trigger-local. Do not normalize the four patterns into one assurance regime.

Do not merge these pairs. Keep CV.Status distinct from GateDecision, E.18 Check locus distinct from GateCheckKind, MIP manifest distinct from DecisionLog, ViewpointMap distinct from graph semantics, PathSlice distinct from a work run, and GateProfile=Lite distinct from PublishMode=Lite.

Field applicability. Always core for A.20: step, applicable CV class, CV.Status, and witness or refusal. Conditional fields: GateCheckRef(aspect=ConstraintValidity), MVPK face pins, bridge and UTS refs, comparator or set-return refs, refresh refs, and SquareLaw or retargeting witnesses; include them only when the corresponding publication, gate, bridge, comparator, refresh, or StructuralReinterpretation claim is being made.

Retrieval trap guard. When excerpted alone, A.20 must not be interpreted as requiring every CV class or a Lipschitz certificate for every step. CV classes are applicability-triggered, and CV.Status does not create gate passage, launch readiness, comparator-use claim, or a reusable GateDecision.

Anti-Goodhart guard. CV completeness is not a substitute for the governed step result: the step must still satisfy the applicable internal constraint, and CV conformance does not create gate fit, freshness, comparator-use claim, or launch readiness.

Generative side. A.20 preserves open-ended action by letting internally valid steps, set publications, and archives remain usable without premature gate, ranking, or launch claims; CV supplies a local applicability relation plus CV.Status for later neighboring claims, not only an assurance stop.

What goes wrong if missed. A practitioner may treat internal constraint satisfaction as gate passage, launch readiness, freshness, comparator-use claim, or decision reuse. That collapses CV into GateFit and hides the A.21 gate decision relation.

What this buys. A.20 lets a practitioner keep the step-local mechanism constraint and CV.Status local to the step and use A.21 only when gate fit or gate decision aggregation is really the question under repair.

Not this pattern when. If the question is GateProfile fit, gate decision, gate-decision reuse, gate explanation, or pass or fail gate publication, use A.21. If the question is graph crossing or flow valuation, use E.18. If the question is comparator use, set-return, archive, or refresh policy, use the current neighboring loci named in Relations.

#Problem frame

In E.18, transformation-flow loci are graph-positioned loci for atomic U.Transformation values and transformation-adjacent governed slot fillers, and the graph uses a single edge kind (U.Transfer). A locus relation may be expressed as a morphism only when the mathematical lens is current; that lens is not the locus kind. GateFit checks aggregate only in OperationalGate(profile) with the activation predicate CV => GF: until aggregated CV.Status=pass, all GateFit checks return abstain. Equivalently, while CV.Status != pass, any GateFit-oriented explanation does not apply. To keep flows comparable and auditable, this pattern delimits internal step constraints (CV) from external gate fit (GF), preventing any second process order beside the graph.

#Problem

Without a clear CV core:

• internal step laws (declared domains and ranges, invariants, units coherence, and Lipschitz-bound or stability claims) are mistaken for GateProfile fit;
• plane or comparator declarations sneak into mechanisms;
• freshness and DesignRunTag concerns appear inside mechanisms;
• reproducibility suffers because transfers start carrying hidden semantics beyond ⟨L,P,E⃗,D⟩.

Under this pattern, CV is evaluated inside transformations. If a check declares planes, units, or comparators or depends on a declared GateProfile, then it is treated as GateFit at gates and the CV explanation does not apply.

#Forces

• Separation of concerns. Internal mechanism laws are distinct from external GateProfile fit.
• Auditability. MVPK faces include pins and references only; no new numeric claims; editions and Γ are pinned where applicable.
• Graph discipline. One edge kind; all crossings mediated by gates; SquareLaw on every crossing.
• Reproducible valuation. Flow = valuation over U.Transfer, with slice‑local refresh bounded by sentinels.
• LEX hygiene. ASCII Tech labels, twin Tech and Plain registers, registered tokens.

#Solution

#Intent and scope

Method and mechanism slot guard. In A.20, mechanism names the law-governed operation structure for the step: signature, operation algebra, law set, applicability, guards, transport, audit, and realization relation. method appears only when a method-position claim is being made or when a bound-derivation technique or method description is being cited. A shared source label, project-side name, or recognizable change concern may require linked method and mechanism typed values, but CV records the step-local mechanism constraint, CV.Status, and witness or refusal; A.3.1 and A.3.2 govern the method claim or method-description claim.

Intent. Establish the ConstraintValidity core for the U.Flow genus: the normative set of internal step constraints and how their status and witnesses are carried and aggregated, independent of GateProfile fit (publication follows MVPK without adding new numeric claims). Where CV refers to mechanism AdmissibilityConditions, phrase criteria counterfactually: “If the admissibility conditions hold, then the CV explanation applies; otherwise this explanation does not apply.” Avoid duty verbs unless stating the normative CC minima.

Scope (genus). CV covers intra-step properties checkable from the transformation step signature and, when the step has mechanism-governed semantics, its mechanism-governing definition. The canonical CV classes are genus-scoped and non-exhaustive: MechanismUnitsCoherence, LawSetInvariants, AdmissibilityConditionsSatisfaction, LipschitzBounds, TypeDomainRange, and—only for StructuralReinterpretation—ReinterpretationEquivalence (correspondence and reversibility witness).

Species binding (E.18 transformation-flow family). The above classes bind to the E.18 locus baseline {Transformation, Signature, Mechanism, WorkPlanning, Work, Check, StructuralReinterpretation} with OperationalGate = Check locus; no additional CV classes are introduced here. Species-specific examples and broader flow specializations stay outside this CV core; StructuralReinterpretation semantics are received through E.18, A.6.4, and this pattern when the CV claim is present.

Out-of-scope (CV): declaring or translating ReferencePlane, Units, or ComparatorSet; CSLC comparability beyond internal step preservation; Freshness; Role and Channel; Regulated-X; DesignRunTagConsistency. These leave CV and use E.18, A.21, or the named comparator, selector, archive, refresh, evidence, work, safety, or temporal locus when that relation is being claimed.

#Primary EntityOfConcern and CV classes

Genus. U.Flow leaves step-kinds abstract; CV and GateFit separation applies to any declared instantiation. Species (E.18 transformation-flow family). E.18 loci bind to {Transformation, Signature, Mechanism, WorkPlanning, Work, Check, StructuralReinterpretation}; this set is a minimum locus baseline defined in E.18. The species space (e.g., UNM declaration and use, SelectionAndTuning, WorkPlanning, EvaluatingAndRefreshing, …) is open-world and non-exhaustive. OperationalGate is the Check locus. StructuralReinterpretation is projection-preserving (no mutation of ⟨L,P,E⃗,D⟩) and may retarget EntityOfConcernRef under CC-TFS-06-EX; see E.18 and A.6.4.

AdmissibilityConditionsSatisfaction — If the declared admissibility conditions hold on the step’s inputs and context, then the CV explanation applies; otherwise this explanation does not apply. LipschitzBounds — If inputs vary within the stated domain (X) and perturbations or noise (≤ ε), then the step’s estimate remains within δ of the reference; otherwise this explanation does not apply. MechanismUnitsCoherence and TypeDomainRange — If units, types, and domains match the mechanism’s signature and closed-world assumptions for the step, then the CV explanation applies; otherwise this explanation does not apply.

Terminology & bindings (normative)

• Status and witness lexicon (E.10 discipline). In CV scope, publications use Status and Witness terminology; GateDecision… lexemes belong to GateFit (A.21) and do not apply to CV.
• EntityOfConcernRef = KindBridge. Any CV mention of selected-entity retargeting is interpreted through KindBridge (CL^k) on UTS under F.9, F.17, E.17, E.18, and C.3.3 when the retargeting or bridge claim is present. CV does not declare or translate planes, units, or comparators.
• Retargeting witness binding. For an E.18 StructuralReinterpretation locus, the CV class ReinterpretationEquivalence SHALL carry CV.WitnessRef := ReinterpWitness over the addressed PathSliceId; the UTS SquareLaw-retargeting witness is referenced from MVPK and UTS material and linked from the CV witness without duplication.
• ReinterpWitness record shape. The record shape is defined once in A.20:4.7.

#MVPK Faces (PlainView - TechCard - InteropCard - AssuranceLane)

Minimum pins on faces that carry CV outcomes (Lean publication under the selected MVPK profile, without weakening checks):

• CtxState pins. ⟨L,P,E⃗,D⟩ on ports and tokens; raw U.Transfer preserves them.
• Path pins. PathId and PathSliceId appear where slice-local refresh or reinterpretation witnesses are relevant; valuation semantics are carried by E.18 plus A.20, with G.11 when refresh wiring is present.
• CV pins. CV.Status ∈ {abstain, pass, degrade, block}, CV.WitnessRef? (refs only).
• Edition pins. If a face cites CG-Spec, ComparatorSet, or UNM.TransportRegistryPhi, the face includes the compatibility reference (BridgeCard + UTS row, with CL and CL^plane) under F.9, F.17, E.17, and E.18 for later use. A.20 references this requirement; it does not introduce or modify Bridge and UTS formats.
• Face scope. Each face includes PublicationScopeId with an MVPK profile value of Min, Lite, SetReady, or Max — no new publication-face kinds.
• Register discipline. Tech names ASCII; twin labels; required LEX tokens follow E.10 (e.g., SentinelId, PathSliceId, SliceRefresh).

No new numeric claims. MVPK faces carry refs, CV.Status, and witness or refusal references only; they do not introduce fresh computed scalars beyond what the mechanism already entails (MVPK functoriality).

CV reference names. In ordinary A.20 prose, an unpublished CV record may be called CVRef or CVCheckRef as a plain local convenience. When the record is carried on an A.21 or E.18 publication face, use the publication lexeme: GateCheckRef := { aspect=ConstraintValidity, kind, edition, scope } with scope ∈ {lane, locus, subflow, profile}. This adds no work-occurrence steps and introduces no numeric claims on faces; it records what CV classes were considered and under which editions. GateCheckRef(aspect=ConstraintValidity) is a publication lexeme only; it does not make CV a gate. A.20 retains CV class meaning; A.21 consumes only referenced CV results when a gate relation is being claimed.

#GateChecks (table) — CV only

Activation predicate (in E.18 transformation-flow structures). Until aggregated CV.Status=pass, all GateFit checks return abstain (CV=>GF). Role and channel fit guard (GateFit scope). GateFit checks that involve roles SHALL use Kernel U.Role tokens (domain = U.System) and SHALL NOT consume TypicalEnactorRoleName strings from alias tables.

#SWP matrix (declaration-locus discipline)

• Writes (faces). CV.Status (and optional CV.WitnessRef) only.
• Referenced editions (ref-only). Any CG‑Spec, ComparatorSet, or TransportRegistryΦ editions (when referenced); their declarations remain governed by the UNM declaration locus per CC-TFS‑24.

#CtxState and GateCrossing

• Crossings only at OperationalGate(profile) (plane, unit, or context) with a strict exception for StructuralReinterpretation: a projection‑only retargeting MAY occur without a gate iff ⟨L,P,E⃗,D⟩ is preserved, KindBridge (CL^k) and a SquareLaw‑retargeting witness are present on MVPK and UTS material, and the retargeting is PathSlice‑local (PathSliceId pinned).
• Projection and EntityOfConcernRef retargeting loci. For StructuralReinterpretation, A.20 may state the CV witness needed for the step, but it does not define a second semantics of projection, published view, EntityOfConcernRef, or retargeting. Interpret those terms through A.6.4, C.2.1, C.2.P, and the relevant UTS KindBridge (CL^k) rows under F.9, F.17, E.17, E.18, and C.3.3 when the retargeting or bridge claim is present.
• Projection and EntityOfConcernRef retargeting normalization (CV use only). In that imported interpretation, projection is a change of published view coordinates only, and EntityOfConcernRef is a Kind-channel change under CL^k. A “no unit or plane change” test SHALL verify that ReferencePlane(src)=ReferencePlane(tgt) and CL^plane is absent (or = ⊤), otherwise the step is a gated crossing.
• Assurance operations on edges. ConstrainTo, CalibrateTo, CiteEvidence, and AttributeTo reside on U.Transfer and do not alter ⟨L,P,E⃗,D⟩; plane or unit changes occur only at gates; Φ and CL^plane penalties appear in R-lane. EntityOfConcernRef retargeting through the kind channel is recorded as KindBridge (CL^k) on UTS under F.9, F.17, E.17, E.18, and C.3.3; under CC-TFS-06-EX this may appear without a gate only when it is projection-preserving and PathSlice-local.

Terminology for this crossing slice is defined in A.20:4.2, and ReinterpWitness shape is defined in A.20:4.7; A.20:4.6 only applies those bindings to CtxState and GateCrossing.

#SquareLaw

For any gate‑mediated crossing adjacent to CV‑checked steps: gate_out ∘ transfer = transfer' ∘ gate_in. Inconsistencies lead to degrade or block per applicable GateProfile (GateFit decision).

retargeting witness shape (normative, UTS-scoped). A SquareLaw‑retargeting witness is a witness record that demonstrates commutativity of a published‑projection retargeting over the addressed PathSliceId:

1. identifies PathSliceId and PublicationScopeId;
2. presents a bidirectional view mapping between projections either as an iso or as a profunctor optic (get : A→B, put : (B×A)→A) satisfying Put‑Get and Get‑Put laws;
3. enumerates the commuting squares for the cut‑set edges considered (ids of transfers before and after the retargeting);
4. declares properties (invertible?, idempotent?) and the definedness area;
5. cites the UTS.RowId and links the DecisionLog entries that rely on this witness. Realizations via profunctor optics (post‑2017) are permitted; the optic laws, including lens laws when the selected optic is a lens, serve as the proof template of commutativity.

CV witness for reinterpretation (normative, CV-scoped). CV.ReinterpretationEquivalence SHALL carry a ReinterpretationEquivalenceWitness distinct from the UTS retargeting witness and scoped to the mechanism state over the same PathSliceId: — PathSliceId, PublicationScopeId, and definedness region (domain constraints); — a pair of internal transformations (or an optic) with Put‑Get and Get‑Put obligations over mechanism state (not faces); — a list of commuting squares for the adjacent raw transfers (before and after reinterpretation) showing SquareLaw at CV boundary; — an explicit NoHiddenScalarization assertion (see §4.9) for any comparable return shape; — edition neutrality: no new editions are declared; only refs and pins appear. This CV witness links to the UTS SquareLaw‑retargeting witness when present, but does not duplicate UTS fields.

CV witness binding (normative). For the CV class ReinterpretationEquivalence, the witness SHALL be a ReinterpWitness record: ReinterpWitness := { PathSliceId, PublicationScopeId, mapping: {kind ∈ {iso, optic}, laws: [PutGet, GetPut]}, commutingSquares: [TransferId], definedOn: PathSliceId, properties: {invertible?: bool, idempotent?: bool}, UTS.RowId, NoHiddenScalarization: true }. The record is PathSlice‑local and does not declare or translate planes, units, or comparators.

#Sentinel and PathSlice (PathSlice-local refresh)

• Flows are valuations over U.Transfer, re-emitting slice-locally under explicit refresh rules or edition bumps carried through E.18, A.20, and G.11 when refresh wiring is present. CV contributes to the prepare and refresh conditions but does not expand scope beyond the addressed PathSliceId.

• Delimitation and planning (normative). A PathSlice closes on: (i) any pinned edition change, (ii) Γ‑window boundary relevant to the face, (iii) GateProfile change along the addressed PathSlice, or (iv) an explicit sentinel rule. Concurrency: at most one active recompute per {PathSliceId}; parallel recomputes are permitted across distinct PathSliceIds.

• CV‑triggered refresh (minimum list). Re‑emit the addressed PathSliceId when any holds: (a) CV.Status changes across the lattice; (b) ReinterpWitness is added, updated, or withdrawn; (c) AdmissibilityDecl.edition or LipschitzBoundRef.edition changes; (d) updates arrive from F.9, F.17, E.17, or E.18 bridge and UTS loci, or from A.19.SelectorMechanism, C.18, C.19, G.5, or G.11 comparator and refresh loci; (e) error or timeout transitions to CV.Status=pass for a previously abstain or degrade CV class.

• CV‑to‑refresh triggers (normative). A SliceRefresh(PathSliceId) SHALL be scheduled when any of the following occurs: (CVRefreshTrigger.StatusFlip) a CV status flip on the slice (pass↔degrade, pass↔block, or an error or timeout transition to degrade or block under GateProfile rules); (CVRefreshTrigger.ReinterpretationWitness) arrival of a new ReinterpretationEquivalenceWitness or a change in its definedness region; (CVRefreshTrigger.AdjacentFactUpdate) updates to adjacent UTS or Bridge facts for the slice (e.g., CL^k, BridgeId, Φ and Ψ policy ids) under F.9, F.17, E.17, or E.18; (CVRefreshTrigger.ReferencedEditionChange) edition changes referenced by comparator or selection loci on the slice (A.19.SelectorMechanism, C.18, C.19, G.5, or G.11 when the comparator or selection claim is present) (ComparatorSetRef.edition, DescriptorMapRef.edition, DistanceDefRef.edition, …); (CVRefreshTrigger.FreshnessTicketChange) FreshnessTicket or freshness or currentness relation changes that alter the slice window under A.21, B.3, or G.11 when the freshness or currentness claim is present;

  (CVRefreshTrigger.SentinelRule) sentinel rules explicitly attached to the PathSliceId. Scheduling is slice‑local; recompute does not fan‑out beyond the addressed PathSliceId.

  Id‑scheme: PathSliceId := PathId × Γ_time selector × ReferencePlane × SentinelFingerprint × IterationCounter. Locking for replay: within a recompute, the effective E⃗ is frozen; outputs carry a replay fingerprint resolvable via DecisionLog.

#ReturnShape and CSLC (comparability discipline)

When a comparable, set-valued, archive, or partially ordered return shape is declared for the step, CV checks that the step did not internally destroy that return shape; no hidden scalarization. If no declared return shape is being claimed, do not create a ReturnShape or NoHiddenScalarization check. Any comparator citation is ref-only and, if editions are cited, SHALL include Bridge+UTS through the current bridge and terminology loci (F.9, F.17, E.17, E.18). Comparator use, ranking, selection, archive semantics, and refresh remain with A.19.SelectorMechanism, C.18, C.19, G.5, G.11, or GateFit (A.21) when those claims are present. CV only checks preservation of the already-declared return shape inside the current step.

Under StructuralReinterpretation, projection changes MUST NOT introduce hidden scalarization; set‑return semantics remain intact; comparator cites stay ref‑only with UTS discipline.

Detectable indicators of hidden scalarization (normative checklist). A face SHALL be flagged when any holds: (H1) introduction of a new scalar not entailed by the mechanism, or any cardinality‑reducing fold of a set return (e.g., argmax or best‑of) without a cited ComparatorSetRef; (H2) omission of a required ComparatorSetRef or its edition pins where comparison is implied; (H3) presence of an order-imposing coordinate without a CoordinatePolicy and declared scale policy, units, or invalid-operation notes; (H4) cross‑plane or cross‑unit numeric combination without a Bridge+UTS row; (H5) for StructuralReinterpretation, any change of return plane or units (violates “projection‑only”). Failing (H1–H5) degrades or blocks per GateProfile (§4.4 and CC-TFS‑21a).

#Γ‑windows and freshness

• No implicit latest. Any face expected to be consumed at compare or launch pins Γ_time; freshness checks occur at gates; CV neither issues Freshness tickets nor evaluates staleness. Use A.21, B.3, C.27, or G.11 when a freshness, temporal-claim, or refresh relation is present.
• Granularity of Γ (normative). Γ SHALL be one of: snapshot (effective_at=t) or interval ([t₀,t₁) with a named folding policy). Faces SHALL carry the selector used.
• CV time‑stamping. Each CV computation records t_cv and the Γ selector it assumed; replay binds t_cv to PathSliceId.
• Temporal policy types (binding). Γ‑pins refer to the canonical selectors of §22 (effective_at, latest_effective_before, windowed(W, policy)) and to folding policies that are IDEM, MONO, and WLNK‑safe. Units and time scales SHALL be explicit. Overrides of the default weakest‑link fold SHALL cite CAL proofs of monotonicity and boundary behavior.

#Unknown, timeout, and error policy

Each CV class yields one CV.Status value: abstain, pass, degrade, or block. Errors and timeouts at CV stage imply CV.Status != pass; therefore GateFit abstains by the global activation predicate and any GateFit‑oriented explanation does not apply. The aggregated CV.Status uses the join on abstain <= pass <= degrade <= block (neutral = abstain; absorbing = block). Minimal default (GateProfile-bound, normative): Lean and Core ⇒ error or timeout maps to degrade, SafetyCritical and RegulatedX ⇒ error or timeout maps to block; unknown folds per GateCheck policy (safety‑default: degrade). (Consistent with CC-TFS‑22.)

#Idempotency and congruence discipline

Any publication consumed by an A.21 gate decision uses the A.21 decision-stability witness for input equivalence and idempotency; use G.6 or G.11 when an A.10 evidence path visibility or refresh-implication claim is present. A.20 does not introduce keys, hashes, or cache policies.

Minimal lexeme set for CV‑adjacent equivalence (normative). Where an A.21 gate decision consumes CV outcomes, the equivalence witness SHALL identify at least: {PathSliceId, GateProfileId, Γ selector (+window bounds if interval), E⃗ editions vector for cited registries, ReturnShape kind (if comparable), CV class and kind set considered}. Changing any of these breaks equivalence and triggers re-aggregation.

#Archetypal Grounding (Tell–Show–Show) ✱

Tell (internal step, not gate passage). CV answers whether a transformation step satisfies its own declared constraints: units, laws, admissibility conditions, stability bounds, type, domain, and range, and, for StructuralReinterpretation, reinterpretation equivalence. If CV.Status != pass, GateFit does not get to rescue the step; if CV.Status=pass, ranking, acceptance, launch, and GateProfile fit still belong outside CV.

Show‑0 (CV.Status=pass, no gate relation). A normalization step has declared units, domain and range, and invariant refs; the CV check returns CV.Status=pass with a CV.WitnessRef. No comparison, launch, crossing, freshness, or GateProfile-fit claim is present, so no GateDecision, GateFit narrative, or DecisionLog is created. The only A.20 result is: this step is internally valid under its declared constraints.

Show‑1 (compiler build → run).

A typed module M exposes f : State_d → BuildOutput_d under a declared LawSet (e.g., determinism under fixed toolchain) and TypeDomainRange. CV checks: (i) MechanismUnitsCoherence (toolchain and flags units coherent), (ii) LawSetInvariants (reproducible outputs under same E⃗), (iii) Admissibility (inputs well-typed), and (iv) optional Lipschitz or stability surrogate (bounded perturbation in sandbox). CtxState is preserved along raw transfers. Entering U.Work(run) uses LaunchGate with FreshnessUpToDate and DesignRunTagConsistency - GateFit, not CV.

Show‑2 (selection archive in QD and AutoML). A mechanism emits a set (Front, Archive, or another declared set publication). CV checks only: valid descriptor ranges, declared continuity bounds over named metric spaces, and archive invariants (idempotent insert). No ranking or acceptance thresholds are introduced at CV; comparators and acceptance policies bind at gates via A.21 plus the current comparator and set-publication loci (A.19.SelectorMechanism, C.18, C.19, G.5, or G.11) when those claims are present. Edition-aware pins on faces carry DescriptorMapRef.edition only with Bridge+UTS.

Practice references. Algebraic effects and handlers separate signatures from handlers (Koka and Effekt, 2015+); reproducible pipelines isolate mechanism constraints from release or deployment criteria (Bazel and Nix); optics, profunctors, and open hypergraph categories motivate composition on open graphs without adding facts on faces; QD, MAP-Elites, CMA-ME, and DQD motivate set-return and declared order relations (2015-2022).

#Bias‑Annotation

The pattern constrains how CV status and witnesses are carried; it does not encode GateProfile-bound thresholds or role and channel fit — those sit in GateFit. This separation keeps GateFit criteria out of mechanism semantics.

#Conformance Checklist ✱

Conformance use. This checklist is evidence for the internal-step CV guidance already stated in the Solution. It is not the first entry text for ordinary use and not a full audit regime by default; a checklist row is applied only when its corresponding CV class, witness, publication face, or neighboring relation is present. Before applying any row, name the Solution move it tests; if no such Solution move is present, treat the row as orientation-only or not applicable rather than expanding the applied assurance or conformance material.

Conformance groups. Ordinary CV use starts with step, applicable CV class, CV.Status, and witness or refusal. Crossing and launch rows apply only when a CV-checked step is adjacent to a present gate, crossing, or launch boundary. Publication and assurance rows apply only when the CV result is carried on MVPK faces or consumed by replay or audit. Extension and change rows apply only when species binding, valuation, refresh, or neighboring selector and comparator loci are being changed or consumed.

Static lint (graph and faces)

• CC-TFS‑01: only U.Transfer edges; crossings appear only on gates.
• CC-TFS‑05: ⟨L,P,E⃗,D⟩ unchanged across raw transfers.
• CC-TFS‑09: MVPK faces present; edition & Γ pins where expected; no new numeric claims on faces (E.17).

CV discipline

• Required CV classes here: {UnitsCoherence, LawSetInvariants, Admissibility, LipschitzBounds, TypeDomainRange}; plus ReinterpretationEquivalence when the locus kind is StructuralReinterpretation. None declare or translate planes or comparators.
• Open‑world species. Any locus species binds to one of the minimal kinds; adding a new locus kind is out of scope for A.20 and belongs in an E.18 locus-baseline update.
• Aggregated CV.Status computed; errors or timeouts imply CV.Status != pass.
• Any wider use beyond the local step names the governing neighboring relation. CV.Status is not gate passage, release confidence, assurance, safety acceptance, work occurrence, or work authorization.

Gate coupling

• CC-TFS‑07: when CV.Status != pass, all GateFit checks report abstain.
• CC-TFS‑23: SquareLaw witnesses present on crossings adjacent to CV‑checked steps.
• Any edition citation on faces includes Bridge+UTS through F.9, F.17, E.17, and E.18; comparator or set-return implications use A.19.SelectorMechanism, C.18, C.19, G.5, or G.11 when those claims are present.

UNM declaration locus

• CC-TFS‑24: CG‑Spec, ComparatorSet, and TransportRegistryΦ declarations are governed by UNM; CV is ref‑only.

Valuation & refresh

• CC-TFS‑18 and CC-TFS‑19: Flow publishes valuation with PublicationScopeId and PathSliceId; Γ pinned at compare and launch faces; sentinel triggers slice‑local refresh.

#Consequences

Benefits. Clarity & composability. Mechanism descriptions remain limited to internal laws; gates are the sole policy junction.

Replayability. With valuation plus MVPK pins, re-runs under fixed E⃗ are comparable and slice-scoped through E.18, A.20, and G.11 when refresh wiring is present. Didactic hygiene. Readers can see what is step-local mechanism constraint plus CV.Status vs. gate policy.

Trade‑offs.

• Two places to look (CV vs. GF) impose placement discipline; mitigated by the activation predicate and MVPK links.

#Rationale

E.18 transformation-flow structure coordinates A.20 and A.21 as orthogonal neighboring cores: CV inside transformations; GF at gates with join‑aggregation and DecisionLog. This mirrors effects and handlers (signature vs. handler), and reproducible build vs. release or deployment criteria separation.

#SoTA-Echoing (post-2015)

A.20 result in local-constraint and reproducible-pipeline practice: CV.Status, conformance labels, validation checklists, and CV-looking publications do not become gate passage, launch readiness, release confidence, safety acceptance, assurance, work occurrence, work authorization, comparator-use claim, or refresh authority. The local A.20 result is step, CV class, CV.Status, witness or refusal, attempted stronger use without a governing relation, and the named governing neighboring relation when a gate, release, assurance, work, comparator, or refresh claim is present. Reopen the local result when the CV status, witness, governing definition, assumption, edition, window, PathSlice, or consuming neighboring relation changes.

#Relations

• Governed by E.18 transformation-flow structure. Loci are graph-positioned positions for atomic transformations and adjacent governed values; only U.Transfer edges; open-world species over a minimum locus baseline; CV=>GF activation; MVPK faces; SquareLaw on crossings; CC-TFS-06-EX for StructuralReinterpretation.
• A.21 (GateProfilization). Sole point for GateFit checks and GateProfile-bound folds.
• E.18 (flow valuation and PathSlice currentness). Declares the graph and valuation semantics used by this flow family.
• F.9, F.17, E.17, and E.18 (Bridge+UTS loci). Boundary-publication requirement whenever faces cite editions.
• A.19.SelectorMechanism, C.18, C.19, G.5, and G.11. Comparability, set-return, archive, and refresh discipline; CV does not compare; it only checks internal readiness for declared comparison.
• A.21, G.6, and G.11. Gate decision stability, equivalence witness references, A.10 evidence path visibility, and refresh implications when gate decisions consume CV-adjacent publications.
• E.10 (LEX). Token classes and ASCII Tech names; twin labels and aliasing for Γ, CL, and Φ as per LEX‑BUNDLE.

#A.20:Appendix A — CV Class Gloss (normative)

• MechanismUnitsCoherence. Internal unit and scale coherence within the step when quantities, scales, units, or reference planes are actually used; no declarations or translations of units or planes occur in CV.
• LawSetInvariants. Mechanism-declared invariants hold (e.g., mass or energy balance in a model, determinism under fixed editions).
• AdmissibilityConditionsSatisfaction. Inputs lie within the windows and guards declared by the mechanism's AdmissibilityConditions; failure yields degrade or abstain per class policy. Minimum declaration (normative): AdmissibilityDecl := { domains: [{name, structureKind ∈ {set, poset}}]+, guards: [predicate_id]*, windows: {Γ_time ∈ {snapshot, interval, policy}}, observables: [signal_id]*, edition: EditionId }. The declaration is published on MVPK as references only; it introduces no arithmetic on faces. Minimal declaration template (normative): AdmissibilityConditions := { Domains[]{var, type, range, units, plane}, Guards[]{predicate, editionRefs}, ObservationWindows[]{Γ selector, freshness window}, ObservableSigns[]{name, detection rule}, Editions{...} } — No unit or plane declaration or translation here; only references. Γ selectors SHALL be explicit.
• LipschitzBounds for stability claims. Bounded sensitivity under a declared metric, used only when a perturbation, sensitivity, robustness, continuity, safety-envelope, or stability claim changes the CV use. Publication ref shape (normative): LipschitzBoundRef := { boundDerivation ∈ {spectral_norm, CROWN, IBP, rand_smoothing, other}, metric_space: {X: norm_id, Y: norm_id}, bound: value or interval, unitRef?: UnitRef, referencePlaneRef?: ReferencePlaneRef, effective_window: Γ_time(selector), edition: EditionId, certificateRef?: LipschitzCertificateId }. Referenced evidence or certificate value (normative): LipschitzCertificate := { metricId (with units and plane), bound L, boundDerivationId, boundDerivationRef (e.g., spectral estimate or certified robustness bound), validity region (inputs and state), proof sketch or reference }. The bound-derivation technique or its method description MUST be cited; unit reference and plane reference of the metric MUST be explicit; proofs and witness records are referenced; bounds are ref-only at CV; any acceptance action remains GateFit. If the technique itself is relied on as a reusable U.Method, use A.3.1 and A.3.2; A.20 only records the CV-bound reference.
• TypeDomainRange. Well-typedness and type, domain, and range consistency for the transformation signature; refs point to the governing definitions.
• ReinterpretationEquivalence (StructuralReinterpretation only). Existence of a correspondence and reversibility witness between source and retarget projections; preservation of ⟨L,P,E⃗,D⟩; no comparator, plane, or unit declaration or translation at CV. Witness (normative): ReinterpWitness or ReinterpretationEquivalenceWitness (see §4.7) with: (i) PathSliceId, PublicationScopeId, (ii) bidirectional mapping (iso or optic) with Put-Get and Get-Put obligations, (iii) commuting squares for adjacent raw transfers, (iv) NoHiddenScalarization assertion when comparable, and (v) definedness region. The witness is PathSlice-local and usable only for idempotence and reversibility within the addressed slice. Any EntityOfConcernRef change SHALL have KindBridge (CL^k) on UTS.

#A.20:Appendix B — LEX discipline (summary)

Register token classes (Tech) include: TransformationFlowStructure, TransformationFlowMathDescription, OperationalGate, GateProfile, GateCheckKind, GateCheckRef, DecisionLog, FreshnessTicket, FinalizeLaunchValues, SubflowRef, FlowEmbed, SentinelId, PathSliceId, SliceRefresh, VALATA; discriminators use Base__P2W, Base__EvaluatingAndRefreshing; Tech names are ASCII; aliases for Gamma-time rules and plane lexemes, plus CLPlane and Phi, follow E.10. A.20 references these tokens; it does not introduce additional LEX classes. For each published CV check, GateCheckRef.aspect is fixed to ConstraintValidity. MVPK minima for CV faces also include PathId and PathSliceId where slice-local refresh applies through E.18, A.20, and G.11 when refresh wiring is present.

#A.20:End

---

Last Updated: 2026-06-14 — this section last modified in upstream FPF commit 7c617d5d (github.com/ailev/FPF)