#Transformation Flow Structure

E.18 · Stable · Structural pattern for ontic relations (E) · Normative unless explicitly marked informative · Part E - The FPF Constitution and Authoring Guides

#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.

Tech-name: TransformationFlowStructure (pattern label) Plain-name: Transformation flow structure Type: Structural pattern for ontic relations (E) Status: Stable Normativity: Normative unless explicitly marked informative Twin labels: Tech and Plain per E.10; faces published through E.17 MVPK (no schemas in Part E).

Provide a notation-independent pattern for TransformationFlowStructure: a selected compound structure whose loci may bind independently identified actual U.Transformation values and transformation-adjacent governed values. The EntityOfConcern is the selected structure itself: loci for those transformations and adjacent governed values, one typed U.Transfer relation, and Eulerian or declarative valuations over paths or path slices inside the same selected structure. A locus may designate or bind an actual U.Transformation only after A.3.4 independently grounds the exact occurrence from its changed referent, temporal extent or formal ordering boundary, boundary conditions, actual change facts, and continuity or reidentification rule; neither the locus nor the use admits that occurrence. A locus may express, constrain, or locate that bounded transformation, or it may bind a signature, mechanism, work plan, performed work, check, structural reinterpretation, publication, evidence, independently governed result entity or relation occurrence, or refresh value that participates in or constrains transformations without becoming the transformation. The selected structure, a flow arrow, adjacency, shared work, a selected or desired structure, a method, MethodDescription, WorkPlan, model, description, evaluation result, publication, transfer, or common affected referent establishes neither an actual transformation nor transformation composition. GateCrossings mark selected-structure state changes at gates; publication faces appear through MVPK; comparable claims pin editions, reference planes, their direct governing refs, and refresh scope. An F.9 Bridge appears only when two exact F.17 SchemeSenseCell values from different semantic contexts satisfy one exact Bridge predicate; the Bridge, any bounded-use claim, optional Bridge Card, and optional CL evidence shorthand remain separate from the structural crossing. Mathematical descriptions of this selected structure, including graph, algebra, category, tuple, path, slice, morphism, quotient, fold, refinement, factorization, or wiring expressions, are governed by E.18.2 and C.29 when lens adequacy matters.

#Relations

#Content

#Intent

Provide a notation-independent pattern for TransformationFlowStructure: a selected compound structure whose loci may bind independently identified actual U.Transformation values and transformation-adjacent governed values. The EntityOfConcern is the selected structure itself: loci for those transformations and adjacent governed values, one typed U.Transfer relation, and Eulerian or declarative valuations over paths or path slices inside the same selected structure. A locus may designate or bind an actual U.Transformation only after A.3.4 independently grounds the exact occurrence from its changed referent, temporal extent or formal ordering boundary, boundary conditions, actual change facts, and continuity or reidentification rule; neither the locus nor the use admits that occurrence. A locus may express, constrain, or locate that bounded transformation, or it may bind a signature, mechanism, work plan, performed work, check, structural reinterpretation, publication, evidence, independently governed result entity or relation occurrence, or refresh value that participates in or constrains transformations without becoming the transformation. The selected structure, a flow arrow, adjacency, shared work, a selected or desired structure, a method, MethodDescription, WorkPlan, model, description, evaluation result, publication, transfer, or common affected referent establishes neither an actual transformation nor transformation composition. GateCrossings mark selected-structure state changes at gates; publication faces appear through MVPK; comparable claims pin editions, reference planes, their direct governing refs, and refresh scope. An F.9 Bridge appears only when two exact F.17 SchemeSenseCell values from different semantic contexts satisfy one exact Bridge predicate; the Bridge, any bounded-use claim, optional Bridge Card, and optional CL evidence shorthand remain separate from the structural crossing. Mathematical descriptions of this selected structure, including graph, algebra, category, tuple, path, slice, morphism, quotient, fold, refinement, factorization, or wiring expressions, are governed by E.18.2 and C.29 when lens adequacy matters.

Use this when. Use E.18 when project work needs one exact selected transformation-flow structure, an internal position or portion of it, a path or path slice, a crossing or gate, a flow valuation, or a refresh locus over its internal U.Transfer occurrences. Several valuations belong here only when they resolve to that same TFS; a detailed portion belongs here as a SubflowRef only while all of its positions and transfers resolve inside one exact parent TFS. If the case needs two independently identified TFS values, or nested networks of them, plus an exact relation across their boundaries, use E.18.NET. Use the named governing pattern when the current EntityOfConcern is a work plan, performed work, method semantics, publication face, mathematical description, or wording-use cue rather than the selected structure.

First useful structure use. Name the selected transformation-flow structure, the locus kinds, the single U.Transfer relation, and the crossing, path, or path slice whose pins are required. For the ordinary case, this is enough: TransformationFlowStructure, current PathId or PathSliceId when a path or slice is the EntityOfConcern, locus kinds, one U.Transfer, and only the crossings or pins required by that application.

First-use slice:

TransformationFlowStructure:
  selectedStructure: cooling-loop stabilization path for one reactor subsystem review.
  loci:
    L1: Transformation locus -> U.Transformation; actual cooling-loop operating-state stabilization only after A.3.4 occurrence grounding.
    L2: U.Mechanism, control-law mechanism governing the stabilization.
    L3: U.WorkPlan, planned measurement and setting-change work.
    L4: one dated test-run Work individual admitted under U.Work, only after that world-side occurrence exists; any run record remains a separate U.Episteme.
  transferRelationKind: U.Transfer.
  currentPathSlice: emergency-load-change review slice.
  crossingOrGate: safety-review gate only when one selected-structure state binding changes under its direct governor; no semantic Bridge is inferred.
  mathematicalDescriptionRef?: E.18.2 only if a graph, algebra, or category expression is being used.

This slice names the selected structure and its governed loci first. If dated L4 is claimed to cause or realize L1, cite the exact subject-governed work-to-change basis or a local relation-bearing claim selected under [A.6.RCD](/generated/patterns/A.6.RCD) disposition 2; co-occurrence is insufficient. If production-work participation, entity-identity inception, or production completion is current, cite the corresponding local [A.15.PROD](/generated/patterns/A.15.PROD) claim and its direct governors. Those references do not become E.18 relation kinds or locus semantics. Publication faces, TEVB viewpoint mapping, GateDecision records, and conformance rows are applied only when that use actually publishes, maps viewpoints, crosses a gate, or consumes assurance checks.

Structure ontology. E.18 keeps these distinctions primary:

Result-claim assurance. Apply this expansion only after the Plain test above identifies what the value is a result of or for. The category-correct direct basis is exactly one of:

• an obtaining relation occurrence, with predicate, participants, applicability, occurrence identity, and direct owner;
• an [A.6.1](/generated/patterns/A.6.1) operation-application binding, with operation, application, and argument or result binding; or
• an [A.6.RCD](/generated/patterns/A.6.RCD) local [C.2.1](/generated/patterns/C.2.1) claim, with polarity, substrate or constructor, base predicates and their direct owners, participants, case facts, and any support required by the receiving use.

When a sentence says that a system performs an actual functional transformation at one point in a flow, E.18 carries only the selected flow structure, locus, path, slice, crossing, valuation, and pins. The independently identified bounded transformation, transformer or candidate bearer, affected referent, input and output boundary, functional-port boundary, functioning relation, method or algorithm, mechanism, and performed work are recovered through [A.3.4](/generated/patterns/A.3.4), [A.6.F](/generated/patterns/A.6.F), [C.30.ASV](/generated/patterns/C.30.ASV), [A.6.M](/generated/patterns/A.6.M), [A.6.1](/generated/patterns/A.6.1), and the A.15 family as applicable. A desired state, method, MethodDescription, WorkPlan, architecture selection, model, description, evaluation result, publication, or transfer does not ground the actual transformation. When exact dated work is claimed to cause or realize the change, cite the exact direct work-to-change governor or a local claim selected under [A.6.RCD](/generated/patterns/A.6.RCD) disposition 2. When production-work participation, entity-identity inception, or production completion is claimed, cite the separate local [A.15.PROD](/generated/patterns/A.15.PROD) claim; E.18 does not derive it from structure membership. A computational algorithm may fill MethodRef? or MethodDescriptionRef?; a physical-world way of transforming may fill U.Method; neither is inferred from E.18 structure membership.

Not this pattern when. Use [A.20](/generated/patterns/A.20) for internal step validity, [A.21](/generated/patterns/A.21) for gate-decision publication, [E.20](/generated/patterns/E.20) for mechanism-governing-definition placement, [A.3.4](/generated/patterns/A.3.4) for bounded transformation under conditions, [E.18.2](/generated/patterns/E.18.2) for mathematical descriptions of the selected structure, [C.27.TA](/generated/patterns/C.27.TA) for temporal aspects, [C.27](/generated/patterns/C.27) for temporal-claim adequacy or supported-use claims, the A.15 family for work planning, performed work, or work-entry readiness ([A.15.5](/generated/patterns/A.15.5)), [E.17](/generated/patterns/E.17) for publication faces, and [E.10](/generated/patterns/E.10) for wording-use repair when the current EntityOfConcern is not the selected structure, path, crossing, or flow valuation.

What goes wrong if missed. A practitioner may treat a reference flow, a wording-use cue such as transition, or a tool pipeline as a new graph kind or a hidden prescribed procedure, then lose comparability, crossing evidence, and slice-local refresh boundaries.

What this buys. E.18 keeps selected structure, publication pins, crossings, CV and GF separation, and refresh locality in one current structure pattern without turning every domain-specific path into its own flow doctrine or every mathematical graph description into the selected structure.

#Problem frame

One selected TransformationFlowStructure can carry many well-typed flow valuations only while every valuation resolves to that same exact structure, its identified positions, and its obtaining internal U.Transfer occurrences. Under VP.Functional, those valuations may concern transformations of one already identified target holon, for example in a declared U.Capability or transformation claim. That target remains distinct from the selected structure and does not become a context object merely because an engineering description concerns it; the E.18 EntityOfConcern is the selected structure over transformations and adjacent governed positions.

E.18.1 P2W Problem-to-Work Carry-Through begins with an accepted ProblemCard@Context claim and carries it into whichever directly governed method, plan, dated Work, transformation, evaluation, decision, entity, relation occurrence, interpretation, stop, branch, or local return becomes current. Before calling one of those values a result, say what it is a result of or for and cite the direct fact or binding that makes that reading true; otherwise stop. Use the adjacent Result-claim assurance expansion to classify that basis without mistaking the flow position for it. A first-principles specialization may traverse a path such as U.Signature(profile=FormalSubstrate) -> U.PrincipleFrame -> U.Mechanism -> U.ContextNormalization (UNM) -> selector relation -> U.WorkPlan or plan-item relation -> one exact Work occurrence admitted under U.Work -> evaluation or currentness relation. That is one possible transformation-flow path, not the definition or prescribed order of P2W: a P2W use may skip, branch, split, stop, return, or reopen, and every continuation remains governed by its direct pattern. Without a common structure discipline:

• flows look ad-hoc and non-comparable;
• structural crossings fail to name the changed state binding, its direct governor, or the gate that decides the transition;
• MVPK faces carry hidden arithmetic or restate input and output;
• set‑returning selection is silently replaced by single scores;
• cycles lack budget discipline; refresh is out‑of‑band.

MVPK already fixes publication drift at the single-arrow scope; E.18 lifts those publication and comparability rules to the selected transformation-flow structure as a whole.

#Problem

1. Mathematical lens != selected structure. A catalog of morphism-scoped, transformation-scoped, mechanism-scoped, work-scoped, or refresh-scoped patterns does not, by itself, explain how the whole selected structure is built, constrained, and audited.
2. Flow proliferation. Multiple “reference flows” can be declared; practitioners need one structure discipline that keeps their flow relations typed and comparable without privileging any single flow.
3. Unsafe publication. Faces re-list inputs and outputs, hide scalarization, omit edition and plane pins, or present a Bridge Card, CL value, UTS row, or policy id as if it made a GateCrossing or gate decision current.
4. Cycles without norms. Selection↔Planning loops run without an explicit budget (Γ_time), an exact stale-measurement finding and any separately governed refresh plan it triggers, or slice-scoped refresh; a pre-run gate decision is mistaken for actual launch bindings, or a FinalizeLaunchValues record is written before an exact Work occurrence and its independently obtaining bindings exist.

#Forces

#Solution - Transformation-flow structure model and relation disciplines

Dominant Solution uses. In ordinary E.18 use, keep five structure uses primary: name one selected transformation-flow structure; distinguish the selected structure from a flow valuation and from its mathematical descriptions; place gates only on crossings or on a pre-run work-entry claim; preserve normalize-before-compare and set-return discipline; and keep cycles under budget plus PathSlice refresh. A gate may authorize or block an intended entry, but it neither creates a future Work occurrence nor fills fields in one. S12 viewpoint mapping remains conditional viewpoint-mapping input when engineering or publication viewpoint mapping is current.

#S1 - Selected Structure (conceptual)

Define a typed, editioned transformation-flow structure TransformationFlowStructure := (Loci, Transfer, tau_L, tau_Transfer, Gamma_time, CrossingRefs, TransportRegistryRefs) with:

• Loci: structure positions or bindings to governed FPF values (open world). Common specialisations include but are not limited to one first-principles P2W example: an independently identified actual bounded U.Transformation, U.Signature(profile=FormalSubstrate), U.PrincipleFrame, U.Mechanism, U.ContextNormalization (UNM), a selector relation governed by current selector and comparator patterns, A.15.2 U.WorkPlan or a plan-item relation, one exact Work individual admitted under U.Work, and current evaluation or currentness relations. This list is illustrative, not exhaustive, and none of its entries is mandatory for general P2W. A structure position may be expressed by a morphism, graph vertex, tuple position, or category-theoretic object under a mathematical lens when that lens is current, but E.18 does not make every position a U.Morphism, graph vertex, or U.Transformation. Selection into the same structure, path adjacency, shared work, or a common affected referent supplies neither the A.3.4 actuality basis nor a transformation-composition governor.
• Transfer relation: a single relation kind U.Transfer (typed) carrying carrier refs and token refs inside one selected TFS. Raw transfer preserves CtxState. Every actual change to a locality, plane, edition, or design/run binding is represented by one GateCrossing at an OperationalGate(profile) and cites that binding's direct governor. An exact A.6.4 retargeting with unchanged CtxState follows the limited StructuralReinterpretation route in CC-E18-06-EX instead of becoming a crossing. Transport conversions cite their exact registry and policy owners. E.18 defines neither a generic semantic Bridge nor a generic penalty policy.
• Scopes: Gamma_time (budgets, horizons), PublicationScope for faces (E.17), and slice ids for refresh (G.11).

CtxState (PS‑projection; closed slots): CtxState = ⟨L, P, E⃗, D⟩ is the projection of E.17 Publication Scope. Slot definitions and direct-governor boundary (normative): • L := Locus — one exact U.ContextSlice value identified under A.2.6; any scope-membership or translated-scope claim remains with A.2.6 and its current F.9/C.2.1/A.10-or-B.3 premises when semantic translation is actually required. • P := ReferencePlane — a ref-only binding to the exact plane and units declaration used by the current case. E.18 has no generic plane-conversion governor: cite the current declaration and conversion owner by value or return missing-governor. • E⃗ := Edition vector — a partial map edition_key ↦ EditionId whose members cite the pattern or registry that owns each edition; G.11 governs edition-bump and refresh records, while E.17 governs publication of the refs. • D := DesignRunTag — design(T^D) or run(T^R) only as consumed by the exact A.21 gate and, at work entry, the A.15.5 readiness claim; the tag does not identify or create Work. Invariants. Raw U.Transfer preserves CtxState (⟨L,P,E⃗,D⟩): it does not write or update any CtxState slot; any CtxState write or update, including a design-to-run tag change for a pre-run work-entry claim, occurs at OperationalGate(profile). The gate changes the claim or decision state, not the ontic identity of a Work occurrence or any independently obtaining relation involving it. Extension discipline. A conforming use registers any extra slot beyond ⟨L,P,E⃗,D⟩ in the E.17 publication discipline and the E.18 LEX “CtxState Extension Registry” with slot‑id, intent, partial‑order rule (neutral or absorbing), and SquareLaw compatibility; unregistered extensions are non‑conformant. Data-shape location. E.18 names the structure and valuation obligations for PathId, PathSliceId, Gamma pins, and lineage: flow is a valuation over U.Transfer, raw transfer preserves CtxState, and path or slice evidence is carried through this pattern plus A.20, with G.6 for evidence-provenance path visibility and G.11 for refresh wiring. These are the current structure loci for path and slice currentness.

• Locus kinds: Transformation, Signature, Mechanism, WorkPlanning, Work, Check, and StructuralReinterpretation are the current minimal structure-positioned locus baseline. Domain-specific species are open-world and non-exhaustive, but each species binds to one of the locus kinds or requires an explicit E.18 update. These are positioned loci in the selected structure, not a local taxonomy of new FPF kinds. Exact identification (no local ontology): — Transformation ≡ A.3.4 U.Transformation only when the structure locus binds one independently identified actual bounded change with its exact changed referent, extent or ordering boundary, boundary conditions, actual change facts, and continuity or reidentification rule. Desired, intended, planned, modeled, selected, described, evaluated, published, or transferred change content remains with its direct governor; it is not a Transformation binding merely because it occupies the selected structure. Current-resolution identification establishes neither finer parts nor partlessness. A positive transformation-composition, TransformationPartOfRelation, composite-transformation identity, or transformation-holonhood claim stops with the TC-MWH missing-governor blocker defined by D14.16. The blocker states which required facts lack a governor or support: the candidate whole and its candidate constituents, each constituent's constructive contribution, compatibility across temporal or changed-referent boundaries and interfaces, and the whole's identity or reidentification rule. E.18 retains the independently identified transformations and supplies no provisional contribution, compatibility, parthood, or whole-change architecture; it does not preselect whether a later settlement uses a generic derived relation, subject-specific relations, local compound claims, or non-admission. — Signature ≡ A.6.0 U.Signature (universal, law-governed declaration). — Mechanism ≡ A.6.1 U.Mechanism (law-governed application over a SubjectKind and RangedValueKind), with placement and stabilization relations in E.20 when current. — WorkPlanning ≡ A.15.2 U.WorkPlan or its current plan-item relation when planning is the governed value. — Work ≡ an exact dated Work individual admitted under A.15.1 U.Work. A structure locus may point to that occurrence after it exists; before execution it points only to a U.WorkPlan, A.15.5 readiness relation, or another exact work-entry claim. No second enactment kind is introduced. — Check ≡ OperationalGate(profile) (universal gate; A.20 governs CV when internal step validity is current, and A.21 governs gate profile, check aggregation, decision, and publication minima when gate fit or gate decision is current). — StructuralReinterpretation is only the E.18 position of an exact retargeting governed by A.6.4; it is not a new retargeting kind. E.18 records source and receiving EntityOfConcern refs, preserved invariant, path-slice locality, and the direct A.6.4 witness. A semantic F.9 Bridge is additional and current only when two exact F.17 cells and the F.9 predicate are independently established; any suitability for this retargeting is a separate C.2.1 bounded-use claim with current A.10 or B.3 reliance when relied on. The legacy A.6.4 KindBridge/CL consumer wording remains parked under D14.17.3, so a case that needs that unsettled interface returns missing-governor rather than borrowing it here. OperationalGate is the E.18 check locus with DecisionLog aggregation. A check-locus label names only the current gate or check value that the selected structure positions: A.20 governs internal constraint validity when that claim is current, A.21 governs gate profile, aggregation, decision, and publication minima when gate fit or gate decision is current, and A.3.4 governs the bounded transformation claim that the check constrains. E.18 adds only a structure-local placement rule: when the exact A.6.4 retargeting is current and CtxState is unchanged, record its witness and PathSliceId without calling it a GateCrossing. If any CtxState binding changes, the path uses a GateCrossing and cites that binding's direct governor. A Bridge, card, UTS row, CL, or witness publication neither creates the retargeting nor decides the gate.

MVPK integration (import). Every locus with an external publication face is published via MVPK faces (PlainView, TechCard, AssuranceLane, InteropCard) under a declared PublicationScope (E.17). E.18 reuses MVPK's publication rules (pins, declared-order discipline, "no new numeric claims and no re-listing of inputs and outputs") and only adds structure-scope constraints in S3 and CC-E18-09 and CC-E18-10; it does not define a second, local publication semantics.

GateCrossing (normative)

Definition. A GateCrossing is E.18's structure-local transition from one exact <FlowPositionRef, CtxState> binding to another at one exact OperationalGate(profile). It is selected only when at least one CtxState binding changes. It is not a U.Relation, an F.9 Bridge, a gate decision, a plane conversion, a retargeting occurrence, a penalty, or a publication occurrence.

Direct-governor account. For every changed binding, cite the current owner and the exact fact or application it supplies:

A.20 may supply a current CV or SquareLaw witness; A.21 supplies GateProfile, check aggregation, GateDecision, and DecisionLog. Neither one supplies the changed locality, plane, edition, tag, or retargeting fact.

Canonical reference. CrossingRef := ⟨TFSRef, GateId, FromPositionRef, ToPositionRef, FromCtxStateRef, ToCtxStateRef, ChangedBindingIds, PathSliceId⟩. A DecisionLog or downstream use that depends on the crossing cites this ref and the direct-governor account.

CrossingBundle publication block. Materialize a CrossingBundle only when a named selector, acceptance, audit, replay, or other downstream use relies on durable crossing evidence. The bundle is publication packaging under E.17, not a constituent of the crossing or gate decision. It contains the CrossingRef, the direct-governor refs for each changed binding, GateId, GateProfileRef, DecisionLogRef, PublicationScopeId, PathSliceId, and any current witness refs.

When that downstream use also relies on cross-semantic correspondence, add a separate F.9 block: the two exact SchemeSenseCell endpoints, the obtaining Bridge and its exact profile, the C.2.1 claim that says whether the Bridge suits this named structural use in the named direction under its rule and tolerance, and the current A.10 or B.3 reliance branch if reliance is claimed. A Bridge Card remains optional packaging and CL remains optional evidence shorthand; neither makes the structural crossing obtain, makes the gate pass, or grants the use.

A penalty appears only when an independently governed policy applies to this exact crossing and the bundle cites that policy owner and PolicyIdRef. E.18 derives no penalty from CL, plane difference, edition difference, or Bridge publication. Missing policy governance means no penalty claim, not an inferred default.

Term separation. Transfer denotes the sole relation kind U.Transfer in the selected structure. Transport denotes Phi-governed conversion policies and registries (TransportRegistry^Phi under UNM). Wording "reuse via Transport" refers to registries and policies, not to an additional transfer relation.

#S2 - Flows as valuations (paths, state, and guards)

• A Flow is a valuation nu over internal U.Transfer occurrences and cut-sets of one exact selected TFS, paired with an admissible path p = v0 -> ... -> vk in that structure. The valuation maps transfer occurrences or cut-sets to token and state values under CtxState and links publication-event records to a declared PublicationScopeId; it is not itself the performed work. The concrete pins and identifiers (PathId, PathSliceId, Gamma_time on compare and launch faces) are governed here as path and slice publication obligations and by A.20 when CV witnesses are current; use G.6 for evidence-provenance path visibility and G.11 for refresh wiring. This reflects the "selected structure != flow" norm (flow = valuation), with gates placed exactly on GateCrossings.

• Several valuations of one TFS. One TransformationFlowStructure may carry several flow valuations only after the use identifies the same exact TFS and its structural boundary for every valuation. For example, nominal-load and emergency-load valuations may differ in state values, paths, slices, or local DesignRunTag bindings while still using the same cooling-loop structure and the same internal transfer occurrences. Labels such as development, application, evaluation, refresh, or feedback do not establish that shared identity.

• Leave E.18 at a member boundary. U.Transfer relates positions only inside that one selected TFS. When candidate flows have independently identified TFS boundaries, separate governed objects or Work occurrences, and a relation across their positions, keep each TFS and its valuations local and use E.18.NET with the exact direct relation governor. Do not turn U.Transfer, adjacency, a carried product, or a feedback arrow into a universal cross-flow relation.

• Admissible path (definition). A path p is admissible iff: (a) locus kinds and transfer relation kinds match the declared tau_L, tau_Transfer; (b) any write or update to any member of ⟨L,P,E⃗,D⟩ appears at exactly one OperationalGate(profile). An exact A.6.4 retargeting with unchanged CtxState follows CC-E18-06-EX without a crossing; if that retargeting also changes a CtxState binding, the changed binding appears at exactly one gate; (c) each GateCrossing on p has a SquareLaw witness (CC-E18‑23), while an exact A.6.4 retargeting separately carries the direct retargeting witness required by CC-E18‑06‑EX; (d) no hidden crossings occur across raw transfers; (e) Γ‑pins are present on compare and launch faces; (f) T^D↔T^R occurs only at LaunchGate.

• U.Transfer preserves CtxState (⟨L,P,E⃗,D⟩) and carries Assurance‑operations only (see S3b); any crossing of locus, plane, edition, or T^D↔T^R is placed at OperationalGate(profile).

• A PathSlice is a selected portion of one path used to scope refresh and telemetry; faces pin PathSliceId; re‑emission happens when any pinned edition changes or SliceRefresh is triggered by sentinel rules. The slice is not performed work or an execution interval merely because it bounds those observations.

Consequences. One P2W practitioner application, or its optional C.2.1 carry-through note or stop description, may cite one path p in a TransformationFlowStructure only when the receiving decision or use relies on explicit selected-structure content. E.18.1 governs that carry-through practice and the local claim content; it introduces no ProblemToWorkCarryThroughRelation@Context, and the path is not such a relation. Every returned method, plan, Work, transformation, evaluation, decision, entity, or relation occurrence remains with its direct owner. Other domains, including supply chains, water networks, and neural-network function structures, may instantiate different paths under E.18.

Why "flow = valuation" preserves the ordinary "some state changes" intuition There are two complementary perspectives:

• Lagrangian (intuitive): track tokens or state changes through a physical, organizational, or computational network.
• Eulerian (structural): define a function on transfer relations ("which quantity or object is associated with each relation under a given regime"), with gate rules. E.18 deliberately fixes the Eulerian semantics of flow at the selected-structure scope: "flow (= valuation) with publication log", while change over time appears as re-valuation over a PathSlice (the selected path portion whose identifier scopes refresh and republication) under gate rules and the SquareLaw. This yields comparability, reproducibility, and slice-local refresh.

#Split-and-join structure discipline

Use split and join only as selected-structure relations inside one TransformationFlowStructure. A split separates one source locus, variant set, problem-side cue, or candidate family into several governed loci or flow valuations. A join relates several governed loci, selected sets, gates, measurements, or refresh returns back to one current structure position. Neither operation creates a new FPF kind, a new pattern, or a prescribed work procedure.

Minimum split-and-join use names the selected TransformationFlowStructure, the exact split or join predicate or policy when membership changes, the selector-governed set or archive when one is returned, the exact publication relation when that value is published, and the smallest refresh scope when currentness changes. Comparator, selector, archive, pool, publication, gate, and refresh authority remains with A.19.CPM, A.19.SelectorMechanism, C.18, C.19, G.5, A.21, and G.11 when those relations are current.

For evolutionary-engineering work, the same selected structure may contain loci for variant generation, retention, archive or front treatment, comparison, selected-set publication, architecture-candidate movement, planning, performed work, effect measurement, residual triage, and refresh. E.18 governs only the structure, loci, U.Transfer, crossings, valuations, pins, and slice-local refresh. C.18, C.19, G.5, C.11, C.30, the A.15 family, and G.11 govern the corresponding claims when they are current.

#Position and parent-relative subflow references

Use a FlowPositionRef to point to one structural position inside one exact TFS:

FlowPositionRef := <
  transformationFlowStructureRef,
  localFlowPositionId
>

The pair is the complete position-reference identity. If the TFS is reidentified, the same local id resolves to a different position. A FlowValuation, PathId, PathSliceId, actual filling, DesignRunTag, value kind, and reference mode may qualify or bind a use of that position; none of them enters its identity.

Use a SubflowRef when the practitioner needs to select and revisit a detailed internal portion of one exact parent TFS without pretending that the portion is another structure:

SubflowRef := <
  parentTransformationFlowStructureRef,
  exactIncludedFlowPositionRefs[],
  exactIncludedInternalTransferOccurrenceRefs[],
  exactBoundaryFlowPositionRefs[]
>

Every included and boundary position must resolve through FlowPositionRef to the same exact parent. Every included transfer must already obtain as an internal U.Transfer occurrence in that parent. A boundary position remains a position of the parent; an internal transfer crossing from an included to an excluded parent position marks the return to the parent. This resolution supplies the parent/subflow connection. It does not introduce parthood, containment, embedding, or membership as another world-side relation.

The tuple is the complete SubflowRef identity. Replacing the parent, an included position, an included internal transfer occurrence, or a boundary position gives another reference; reidentifying the parent invalidates the old resolution. Changing only a valuation, path or slice, tag, actual filling, graph, mathematical description, publication, or demonstrative view leaves the reference unchanged while the tuple still resolves. Branching, joining, or cycling inside the portion does not make it a network.

Quick discriminator. Grinding, dosing, and wetting may be shown as a coffee-preparation subflow while their positions, internal transfers, entry, and exit all remain in one coffee-brewing TFS. If heating instead has its own TFS identity and boundary and an exact relation connects it to preparation, stop using SubflowRef and apply [E.18.NET](/generated/patterns/E.18.NET).

#S3 - Publication discipline (faces)

E.18 imports E.17 wholesale and associates MVPK faces with PublicationScope (USM). MVPK remains the governing reference for:

• the set of face kinds (PlainView, TechCard, InteropCard, AssuranceLane),
• pin discipline and Publication Characteristics (PC),
• “no new numeric claims, no re‑listing of inputs and outputs, and no Γ‑semantics on faces”.

E.18 does not re-specify these rules; it only adds structure-scope obligations for faces published over transformation-flow paths:

1. Crossings on faces. When a face publishes a GateCrossing, it cites the CrossingRef, changed-binding direct-governor refs, GateId, and any current DecisionLog or policy refs. An F.9 Bridge block appears only for a separately established cross-semantic use; its optional card and CL do not replace those refs.
2. Edition refs on faces. A face that cites CG-Spec, ComparatorSet, UNM.TransportRegistryPhi, or another edition cites that value's exact owner and edition. Edition citation alone requires no Bridge Card, UTS row, or semantic Bridge.
3. ComparatorSet and set returns (structure-scope). Any ComparatorSet and SetSemanticsRef used along a transformation-flow path carries edition identifiers; affected faces are re-emitted on edition change; faces with comparison return sets and declared partial orders (no hidden scalarization), reusing MVPK's declared-order discipline.
4. Gamma_time on compare and launch faces. All compare and launch faces on E.18 paths pin Gamma_time; implicit latest is not admissible. A.21 carries current GateProfile binding and minimum profile semantics; E.18 paths include the pin. CHR avoids acceptance thresholds (NoThresholdsInCHR); gate and threshold claims are carried by A.21 and Part G, while actual performed facts are established through independently obtaining relations involving exact Work occurrences under A.15.1. Unknowns remain tri-state (pass|degrade|abstain) and fold per the active GateProfile (A.21).

Reminder. MVPK already bans "signature" on faces, input-output re-listing, arithmetic on faces, and unpinned numeric content (E.17 §5.4-5.5). E.18 does not weaken or override those rules; it only constrains how they are used along transformation-flow paths.

Lean publish‑mode (AssuranceLane‑Lite). Lean changes publication faces only (PlainView/AssuranceLane minimal), not checks; publication shows GateProfile, GateCheckRef[], and DecisionLogRef; the underlying GateChecks list remains unchanged.

Decision stability and idempotency (gate-local). Gate decisions are stable under a declared equivalence relation over the pins used by A.21; the witness is recorded as DecisionLog or EquivalenceWitnessRef, with G.6 used for evidence-provenance path visibility and G.11 for refresh implications. E.18 does not prescribe storage formats, key shapes, or hashing schemes.

Retargeting and semantic-Bridge boundary.

An EntityOfConcernRef or kind change is not admitted by a UTS row, mapping label, card, CL value, or GateCrossing. First recover an exact A.6.4 retargeting with its source and receiving subjects, invariant, preserved and withdrawn commitments, applicability, and witness. If the retargeting also needs a semantic relation between different local senses, apply F.9 separately and keep its bounded-use claim and reliance branch separate. Because A.6.4's legacy KindBridge/CL consumer interface is parked under D14.17.3, a use that cannot meet the current direct-owner facts stops at that named missing governor.

#S4 - Assurance‑operations on U.Transfer (counterfactual admissibility)

On U.Transfer relations, an operation is interpreted as a declarative assurance-operation iff it is one of ConstrainTo(rule), CalibrateTo(calibrationReference), CiteEvidence(evidenceRef), or AttributeTo(provenanceReference); otherwise this explanation does not apply. Under this interpretation, CtxState⟨L,P,E⃗,D⟩ is preserved. If a claimed assurance operation would change plane or units, this assurance-operation explanation does not apply. Use a GateCrossing only after the exact plane or units declaration and conversion owner is cited; otherwise return missing-governor.

If an independently governed policy assigns a penalty, cite its owner and PolicyIdRef and publish the penalty only in its governed assurance lane; otherwise no penalty claim appears here.

#S5 - Comparability and aggregation (normalize‑then‑compare; counterfactual form)

The comparison explanation applies under the following admissibility conditions:

• If a path segment intends to compare or aggregate, it is admissible as a comparison only when UNM precedes it; UNM is method‑independent, publishes TransportRegistry^Phi and CG-Spec references, and faces cite those editions; otherwise this comparison explanation does not apply.
• If the comparator defines a declared partial order, then returns are sets or archives (Pareto or Archive); if a total order is declared, it is the one provided by the comparator; otherwise set semantics apply and covert scalarization is out of scope here.
• If a claim is ordinal‑only, then only comparison results are published; arithmetic transforms (e.g., means and z‑scores) are out of scope of this explanation and belong to declared comparators or downstream policy.

Edition-aware set or archive publication records (e.g., QD archives) pin DescriptorMapRef.edition, DistanceDefRef.edition, and CharacteristicSpaceRef.edition when applicable; refresh is slice-local. Comparator, archive, and refresh checks are governed by A.19.SelectorMechanism, C.18, C.19, G.5, G.9, and G.11 for current archive or refresh cases.

#S6 - Cycle discipline (Selection ↔ Planning)

• The selected structure may center a loop between the SelectionAndTuning locus governed by selector and comparator patterns and the WorkPlanning locus governed by A.15.2 U.WorkPlan or a plan-item relation.
• The Selection-Planning loop is represented under local budget and max_iter in Γ_time; at expiry, the exact selector-governed relation returns its declared current set or archive outcome, such as CandidateSet, with the applicable partial-optimality status. If the next step needs changed tuning, a separately governed U.WorkPlan, plan-item relation, configuration, or policy carries that tuning; it is not another entity returned by the selector. Further improvement is placed in the next PathSlice only through that separately governed continuation.
• UNM occurs before the loop. When the normalized basis shows missing or stale measurements, retain that exact UNM-governed finding. A freshness request remains a request. If the receiving use then plans measurement refresh, A.15.2 separately identifies the U.WorkPlan or plan-item relation; only an exact dated Work occurrence admitted under U.Work by A.15.1 enacts it. A later measurement and its calibration remain separately governed. If G.11 produces a RefreshReport@Context, identify that report artefact separately from the request, plan, dated Work, later measurement, and calibration; being a report, audit artefact, record, or publication makes it neither the Work occurrence nor the returned world-side result. A CalibrateTo(calibrationReference) publication cites the exact calibration reference and the current TransportRegistry^Φ owner when transport conversion is involved. Any penalty is a separate policy-governed claim with its own owner and PolicyIdRef; calibration, conversion, or registry publication supplies no penalty by itself.
• Work-entry claim and actual Work stay distinct. workEntryClaimRef designates one exact U.WorkPlan, A.15.5 readiness relation, or other prospective claim consumed by LaunchGate. If Work later occurs, each actual launch value is established only through an independently obtaining direct relation or exact A.6.1 application binding of that Work individual. A separate FinalizeLaunchValues episteme may then designate the Work occurrence and those facts; it neither performs Work nor fills slots in the occurrence.

Refresh orchestration. Telemetry records and publications that designate an exact Work occurrence are slice-scoped, editions re-pinned, and faces re-emitted. Telemetry remains a separate episteme and does not constitute the occurrence.

#S7 - Selector semantics (G.5) and parity harness (G.9)

E.18 keeps set-return, archive preservation, and comparator refs visible along the path. It does not define selector, archive, dominance, or comparator semantics; those remain with A.19.SelectorMechanism, C.18, C.19, G.5, G.9, and G.11 for current selector or comparator cases.

• Selectors return sets. Default DominanceRegime is ParetoOnly; IlluminationSummary (telemetry summary) and any coverage and regret telemetry quantities are report-only telemetry (reported), excluded from dominance unless a CAL policy promotes them as declared dominance inputs (policy-id in SCR).

If PortfolioMode=Archive, a QD archive can be returned; when generation is in scope, pairs {environment, method} are managed under declared EnvironmentValidityRegion and TransferRulesRef; parity records and PathSliceId are pinned on publication. Comparator semantics and archive pinning are governed by A.19.SelectorMechanism, C.18, C.19, G.5, G.9, and G.11 for current archive or comparator cases.

#S8 - Guard aggregation assignment and handling (USM §1.2)

• USM.CompareGuard and USM.LaunchGuard publish the guard-gate aggregation assignment field GuardOwnerGateId. The legacy field name is read here as a gate-reference assignment, not as an owner relation. Guard failures are events aggregated by the declared gate (not GateChecks).
• Aggregation-assignment rules: (i) USM.LaunchGuard.aggregationGate = LaunchGateId(workEntryClaimRef), where the ref resolves to the exact prospective claim consumed by the gate and never to a not-yet-existing Work occurrence; (ii) inside a Subflow, USM.CompareGuard.aggregationGate = OperationalGate(InSentinel); join loci cannot be assigned as guard-pin aggregation gates.

GateProfile data shape (cross-reference). A.21 carries the current GateProfile binding and minimum profile semantics. E.18 names the structure only where crossings need it; fuller profile-matrix material is not a separate current authority unless a current governing pattern explicitly admits it.

Scope-translation guards (cross-reference). A.2.6 governs exact slice and scope membership and any actual translated-scope application. When that translation relies on different local senses, it additionally requires an obtaining F.9 Bridge, a separate affirmative C.2.1 bounded-use claim, and current A.10 or B.3 reliance. A.21 still owns gate aggregation; no CL value or Bridge Card decides the guard.

Error, timeout, or unknown (profile-bound). GateCheck errors and timeouts fold to degrade under Lean or Core and to block under SafetyCritical or RegulatedX; unknown follows the GateCheck's governing rule (safety-default: degrade). The A.21 DecisionLog record and equivalence witness carry decision stability; E.18 does not define storage or key structures.

#S9 - Transport and crossings

• A GateCrossing records one selected-structure transition between exact source and receiving positions and CtxState bindings at one exact A.21-governed gate. Cite A.2.6 for locality and scope membership, the exact current owner for plane or unit conversion, each edition owner plus G.11 when refresh is current, A.21 for DesignRunTag and the gate decision, and A.15.5 for a prospective work-entry boundary. When the claimed change, retargeting, or penalty depends on one of those governors and that governor is missing, return the named missing-governor stop.
• A semantic F.9 Bridge is additional, not constitutive. Use it only when the case identifies two exact F.17 SchemeSenseCell values from different semantic contexts and the Bridge predicate actually obtains. Keep the proposed structural use in a separate C.2.1 claim, recover current A.10 or B.3 reliance when relied on, and keep any Bridge Card or CL optional and non-constitutive.
• An EntityOfConcern or kind change remains with A.6.4. The current A.6.4 legacy KindBridge/CL branch is parked under D14.17.3; E.18 records no positive substitute. T^D↔T^R is handled at the exact A.21 gate with DesignRunTagFrom and DesignRunTagTo and the current A.15.5 or publication locus, without implying Work occurred.

#S10 - Non‑mechanism boundary

• Publication is a typed projection, not execution. Any build, render, or upload is Work on carriers; faces do not carry Γ-semantics.

#S11 - Coordination wording labels (when current)

Coordination wording may be published as LexicalView labels over a P2W carry-through flow valuation; it is orientation-only unless an exact structural crossing, work relation, semantic Bridge, or gate decision is independently current. It adds no current structure locus kind, checks, or mechanisms. A published crossing cites CrossingRef and direct-governor refs; an F.9 block is added only for a separately established semantic Bridge and bounded use.

#S12 - Viewpoint Families To E.18 Constructs (neutral, holonic)

S12 use. S12 is secondary viewpoint-mapping input for a current viewpoint-family mapping claim. It is not the ordinary E.18 core for naming a selected structure, flow valuation, path slice, or crossing.

E.18 does not mint new viewpoint or view kinds. It imports the generic multi-view machinery of E.17.0 U.MultiViewDescribing, bundles from E.17.1, and the TEVB engineering bundle from E.17.2. S12 only describes how these existing U.Viewpoint and U.ViewpointBundle ids are used in transformation-flow structures and in UTS.ViewpointMap; intent and concern semantics are governed by E.17.0-E.17.2.

Two-part use of TEVB and MVPK (ISO 42010 summary, no local re‑definition).

• Engineering viewpoints. For engineering holons, E.18 assumes a TEVB bundle with ViewFamilyId = VF.TEVB.ENG. EngineeringVPId is one of {VP.Functional, VP.Procedural, VP.AllocationResponsibility, VP.ModuleInterface}, and TEVB is the governing reference for their semantics. E.18 does not refine these viewpoints.
• Publication viewpoints. Publication viewpoints come from MVPK (E.17); PublicationVPId is a MVPK.ViewpointId that governs faces under a PublicationScope.
• Architecture relation. E.18 can supply the selected transformation-flow structure used by one exact ArchitectureOf@Context claim or by a use that selects that exact architecture structure. Name that claim or structure and its direct owner. Identify any C.2.1 description episteme, actual EntityOfConcern, effective reference scheme, ClaimScope, or BoundedModelUseStructure separately and only when the architecture use actually relies on it. E.18 does not define architecture itself, and a transformation-flow structure is not the functional architecture by default. Use C.30, C.30.ASV, and the architecture transformation-flow relation pattern when the selected structure is used in an architecture-flow relation. Structural crossings follow E.18 S9 and CC-E18-11/-23; any penalty additionally requires an independently governed policy and PolicyIdRef. Neither changes viewpoint semantics.
• Separation of roles. VP.* from TEVB are EngineeringVPId values only; they are not publication faces. PublicationVPId values are defined in MVPK. The mapping between them is entirely via ISO-style correspondences and the UTS.ViewpointMap; E.18 does not define a second notion of viewpoint.

Described-subject and publication scope (summary).

• Engineering described subject. TEVB may describe an already identified target holon (U.System or U.Episteme) under its EntityOfConcernClassSpec. That subject remains distinct from any U.ContextSlice, claim scope, description episteme, and selected TransformationFlowStructure; viewpoint mapping creates no context-holon or context-object identity. E.18 governs only the selected transformation-flow structure when that structure is under concern. Transformation, method, procedure and control, allocation-responsibility structure, structural architecture, module, interface, and allocation terms remain viewpoint concern and content about that holon. A different EntityOfConcern requires one exact A.6.4 retargeting with its source and receiving subjects, invariant, applicability, and witness. If that use also needs correspondence between two different local senses, test the two exact F.17 cells and the F.9 Bridge separately, followed by the bounded-use claim and current reliance branch. If the only available route is A.6.4's parked legacy KindBridge/CL interface, return the D14.17.3 missing-governor stop.
• Publication described object. MVPK can treat the architecture description itself as an EntityOfConcern; publication viewpoints for that AD are defined in MVPK, not here. E.18 only checks that such faces honor MVPK discipline and E.18 crossing rules when they publish selected transformation-flow material.

Naming rules (aligned with E.17.0, E.17.1, and E.17.2).

• ViewFamilyId is the U.ViewpointBundle.viewFamilyId (e.g. VF.TEVB.ENG for TEVB); its lexical and ontological discipline is governed by E.17.1.
• EngineeringVPId : ViewpointId is always a U.ViewpointId drawn from some bundle (for TEVB, one of {VP.Functional, VP.Procedural, VP.AllocationResponsibility, VP.ModuleInterface}). E.18 never defines new VP.* ids.
• PublicationVPId : ViewpointId is a MVPK.ViewpointId defined in E.17; TEVB viewpoints are never reused as publication viewpoints (per TEVB guard and MVPK).
• The unqualified field name ViewpointId is not valid in S12 rows. Use EngineeringVPId, PublicationVPId, or both explicitly; any imported row with an unqualified ViewpointId is normalized to PublicationVPId before the row is used.

Terminology guards (no local semantics).

• Within S12, “viewpoint”, “view” and “correspondence” have exactly the meanings given in E.17.0; “publication face” means an MVPK face (PlainView, TechCard, InteropCard, AssuranceLane) under some PublicationVPId.
• Faces are carriers for views: a face is part of a view only when linked via an ISO‑style CorrespondenceRef to an engineering U.View under some EngineeringVPId; S12 does not add extra conditions beyond E.17.0 and E.17.2.
• Labels such as “Functional view”, “Procedural view”, “Allocation‑Responsibility view”, “Module‑Interface view” in this section are plain viewpoint labels for TEVB viewpoints; they are not interpreted as extra viewpoint kinds or as publication-face types.

Purpose. Provide a neutral (F.18) mapping from TEVB engineering viewpoint families - bundle VF.TEVB.ENG with VP.Functional, VP.Procedural, VP.AllocationResponsibility, and VP.ModuleInterface - to E.18 constructs so that the same holon can be described through functional, procedural, allocation-responsibility, or module-interface viewpoints while the E.18 construct scope remains explicit. S12 does not introduce new U.Viewpoint or U.View kinds, and it does not claim that all such views share one underlying transformation-flow structure unless the structure, EntityOfConcernRef, and correspondence refs are declared.

Holon target. The mapping applies to any holon. A Work occurrence admitted under U.Work requires its actual performer U.System, exact obtaining covering U.RoleAssignment, enacted method, temporal extent, and containing U.System. The performer is the assignment's holder and performs the Work under that assignment; when explicit attribution identity is used, cite the canonical F.6 relation performedUnderAssignment(W, RA). Merely being a System or structure locus creates no Work. Supervisory and structural hierarchies remain distinct (B.2.5).

Viewpoint family to primary E.18 constructs (TEVB-aligned) All four families referenced below are TEVB engineering viewpoints; the "what ..." clauses are interpretive glosses for how they use E.18 constructs. Formal intent, concerns, and allowed episteme kinds remain in TEVB (E.17.2).

1. Function-Oriented View (EngineeringVPId = VP.Functional, capability and transformation viewpoint) - "what transformation is achieved under roles"
   • Flow valuation example: P2W carry-through flow valuation through loci U.Signature(profile=FormalSubstrate) -> U.PrincipleFrame -> U.Mechanism -> U.ContextNormalization (UNM) -> SelectionAndTuning locus -> WorkPlanning locus -> later exact Work occurrence admitted under U.Work -> EvaluatingAndRefreshing locus, where each illustrative locus label names a governed value or relation rather than a new U.* kind.
   • Publication: MVPK publication faces per E.17; comparable claims pin CG-Spec and ComparatorSet editions; a structural crossing publishes CrossingRef and direct-governor refs. Add an F.9 Bridge block only for a separately established cross-semantic use.
   • Checks: A.20 (CV) inside transformations; A.21 (GateFit) at gates; comparator, set-return, and No-Hidden-Scalarization discipline is carried through A.19.SelectorMechanism, C.18, C.19, G.5, G.9, and G.11 for current selector or comparator cases.
   • Holonic note: U.Episteme does not act; it is used by systems acting on carriers. An actual Work occurrence is admitted under U.Work only with its actual performer U.System, exact obtaining covering U.RoleAssignment, enacted method, temporal extent, and containing U.System. The system is the assignment's holder and performs the Work under that assignment; when explicit attribution identity is used, cite the canonical F.6 relation performedUnderAssignment(W, RA).
2. Procedure‑Oriented View (EngineeringVPId = VP.Procedural, step and time storyboard) — “what steps occur and when”
   • FPF constructs: U.WorkPlan (A.15.2) for intent and schedule; an exact Work occurrence admitted under U.Work (A.15.1) for actual performance; and a separate assertion or record when the occurrence is described.
   • Boundary: OperationalGate(profile) with USM.LaunchGuard consumes one exact workEntryClaimRef and may authorize or block an attempted run; it does not create or mediate ontic entry into Work. DesignRunTag separates design-time and run-time claims, and DesignRunTagFrom and DesignRunTagTo appear only at gates. If Work occurs, its occurrence identity and actual relations are grounded independently under A.15.1.
   • Holonic note: Applies to any U.System scope (single holon or a supervised sub‑holon cluster); supervisory structure is handled by roles rather than structural mereology (B.2.5).
3. Allocation‑Responsibility and Device‑Structure View (EngineeringVPId = VP.AllocationResponsibility) — “which systems, interfaces, constraints, role assignments, and responsibility allocations are relevant”

   • FPF constructs: Module interfaces are Signature loci; module realizations are Mechanism loci; inter-module dependencies traverse U.Transfer, with gates on crossings.

   • Publication: MVPK faces are typed projections, not Work occurrences, performed-work records, or execution carriers; faces add no new numeric claims (E.17). Constraints and compatibility appear as CV checks (A.20).

   • Holonic note: Structural mereology (part-whole structure of the carrier) is modeled in Part A; E.18 ties interface and exposure semantics to mathematical-lens expressions and gates only when those are current.

   • Device-view structural reinterpretation. The same transformation-flow valuation may be described through a device-oriented view without changing the declared TransformationFlowStructure. A real EntityOfConcernRef change requires an exact A.6.4 retargeting and witness; if CtxState is unchanged, record it as a path-slice-local retargeting rather than a GateCrossing. If a CtxState binding changes, use a GateCrossing with that binding's direct governor. Do not infer a semantic Bridge, use licence, or gate result from the view change.

   • Role‑label guard. TypicalEnactorRoleName is pedagogical only and is not used as a GateFit role; GateFit uses U.Role (A.21).

4. Module‑Interface View (EngineeringVPId = VP.ModuleInterface, physical and logical module structure) — “what modules exist and how they specify commitments and constraints across interfaces”
   • FPF constructs: Module interfaces are Signature loci; module realizations are Mechanism loci; inter-module dependencies traverse U.Transfer, with gates on crossings.
   • EntityOfConcernRef note: A functional-view-to-element-structure change follows the Device-view rule above: exact A.6.4 retargeting first, then a GateCrossing only for changed CtxState; any semantic F.9 Bridge remains a separate relation and bounded-use question.
   • Holonic note: The same module can appear as a holon in multiple views; supervisory loops (B.2.5) remain orthogonal to structural composition. This is an expandable list of viewpoint families; E.18 is intentionally viewpoint-neutral. Additional engineering bundles beyond TEVB (safety, mission, information, ...) are introduced as separate U.ViewpointBundle species via E.17.1 and E.17.2; S12 does not define them.

View-family label discipline for transformation-flow loci (recognition-only). Scope. When a viewpoint-family mapping claim is current, a pattern or domain profile may declare LocusViewFamilyLabels[] for transformation-flow locus labels so practitioners can recognize familiar engineering wording while the selected structure stays governed by E.18. Semantics come from the referenced U.ViewpointBundle, E.18 locus binding, and MVPK correspondences; labels are recognition aids, not loci, viewpoints, publication faces, checks, or work records.

Norms.

1. Each current transformation-flow locus label may publish LocusViewFamilyLabels[] records of the form { ViewFamilyId, EngineeringVPId?, Label : TechASCII }.
   • If ViewFamilyId = VF.TEVB.ENG, then EngineeringVPId is one of {VP.Functional, VP.Procedural, VP.AllocationResponsibility, VP.ModuleInterface} (TEVB; CC-TEVB-1 and CC-TEVB-6).
   • Other ViewFamilyId values denote U.ViewpointBundle instances defined elsewhere, not ad-hoc local families.
2. Labels are recognition-only: no arithmetic, no new claims, no check participation, no CtxState slot writes or updates, and no DesignRunTag change. They do not create MVPK faces.
3. Labels are not used as PublicationVPId; publication viewpoints remain in MVPK.
4. Twin registers are allowed as Tech and Plain labels per E.10; naming follows F.18 local-first discipline.
5. Do not name transformation-flow loci by operands or output states; an operation is not its operand or output state.
6. TypicalEnactorRoleName can be added for pedagogy; it is not used as a GateFit role because GateFit uses U.Role only.
7. Morphology: ASCII TitleCase; conjunctions use And; for composite operation labels use XingAndYing or XAndYing when grammar calls for it.
8. The first-principles illustrative row used by one P2W case (U.Signature(profile=FormalSubstrate) through current evaluation or currentness relations) is informative. It neither defines general P2W nor changes kind or viewpoint semantics.

Conditional publication block — UTS.ViewpointMap (TEVB-aligned when current).

Publish a UTS block named ViewpointMap only when an engineering or publication viewpoint-family mapping claim is made or consumed. Ordinary E.18 use does not require UTS.ViewpointMap when the question under repair is only the selected structure, flow valuation, path slice, or crossing.

Minimum row schema (per row, when ViewpointMap is current).

• ViewFamilyId — U.ViewpointBundle.viewFamilyId (e.g. VF.TEVB.ENG for TEVB, or another bundle id).
• EngineeringVPId : ViewpointId — a viewpoint from that bundle (for TEVB, one of {VP.Functional, VP.Procedural, VP.AllocationResponsibility, VP.ModuleInterface}).
• PublicationVPId : ViewpointId? — MVPK publication viewpoint id that governs faces implementing this engineering view (optional if not publishing).
• TargetHolon ∈ {U.System, U.Episteme} (extension species must be admitted holon kinds by a direct governing pattern. U.PromiseContent and U.MethodFamily do not fill TargetHolon by label. If promise-content or method-family wording is current, recover the direct promise, method, description, work, or architecture governing pattern first, and use E.18 only for selected transformation-flow structures around an admitted target. If TargetHolon != U.System, this row cannot supply the System-holder basis required for an A.15.1 Work occurrence.)
• PrimaryE18Constructs - loci, transfer relations, and gates actually used for this (ViewFamilyId, EngineeringVPId, TargetHolon) (typically one of the four families above).
• Crossings{CrossingRef, ChangedBindingGovernorRefs[], GateId, DecisionLogRef?} — only crossings actually used by this mapping.
• EditionPins{...} whenever comparable claims appear, each resolving the exact edition owner; publication follows E.17 and does not require a Bridge Card merely because an edition is cited.
• SemanticBridgeUse? — present only when the row separately identifies two exact F.17 SchemeSenseCell values, an obtaining F.9 Bridge, the C.2.1 claim for this mapped use, and any current reliance branch; absent otherwise.
• (REQUIRED when publishing) CorrespondenceRef[] — ISO 42010 correspondences linking published faces to the engineering view(s) they implement; can cross architecture descriptions.
• Optional relation field ConcernsCovered[] — ISO 42010 stakeholder concerns addressed by this row via GateProfiles and check catalogues.

Conformance (S12-scoped, only when ViewpointMap is current). (i) UTS.ViewpointMap exists when a viewpoint-family mapping claim is made or consumed. (ii) For each holon that claims TEVB alignment, there are at least four rows whose {ViewFamilyId, EngineeringVPId} cover {VF.TEVB.ENG × {VP.Functional, VP.Procedural, VP.AllocationResponsibility, VP.ModuleInterface}} (per CC-TEVB-1 and CC-TEVB-6). (iii) Rows that carry edition identifiers resolve each exact edition owner and publish the refs under E.17; edition citation alone creates no Bridge or Bridge Card duty. (iv) A row with SemanticBridgeUse resolves exactly two endpoint cells, an obtaining F.9 Bridge, its bounded-use claim, and the current reliance branch; a row without cross-semantic use carries none of that apparatus. (v) Any TargetHolon = U.System row that includes a prospective work-entry claim shows its LaunchGate with DesignRunTag consistency; any later Work locus points to an independently grounded exact Work occurrence rather than treating the gate decision as the occurrence. (vi) Crossings referenced in ViewpointMap resolve CrossingRef, every changed-binding governor, and the A.21 gate; comparability along mapped paths follows CC-E18-10. (vii) Rows do not use an unqualified ViewpointId; they use EngineeringVPId, PublicationVPId, or bothexplicitly. (viii) When faces are published,CorrespondenceRef[]is present and resolvable toU.Viewpointids. (ix) Additional bundles (e.g. assurance, information, mission) can appear as extraViewFamilyIdvalues but are declared asU.ViewpointBundlespecies; they do not extendVF.TEVB.ENG`.

#Archetypal Grounding (Tell–Show–Show; concise)

Tell (one first-principles P2W specialization). A first-principles-to-work path is one path through a selected transformation-flow structure, not P2W as a whole: U.Signature(profile=FormalSubstrate) declaration, principle frame, mechanism, normalization, selection, planning, pre-run work-entry claim, later exact Work occurrence when one exists, and current evaluation or currentness relations occupy exact governed positions. E.18.1 separately carries the accepted problem-side claim through whichever of those relations becomes current.

Show-A (Supply chain). Loci: procurement -> inbound QC (UNM) -> selection (supplier set; declared order) <-> planning (lotting and schedule; budget) -> execution (exact receipt Work occurrences admitted under U.Work, with separate receipt records) -> refresh (quality telemetry; affected faces re-emitted). When the incoming lot moves from the supplier-receipt position to the internal-QC position and a declared locality binding changes, record that structural transition with its CrossingRef, exact A.2.6 locality fact, changed-binding governor, and A.21 gate. If supplier and internal labels also use different local senses, identify the two exact F.17 cells and test the F.9 Bridge, the C.2.1 bounded-use claim, and current reliance separately. A penalty appears only under a cited independent policy owner and PolicyIdRef; comparators remain pinned to the exact CG-Spec edition owner.

Show-B (Neural-net functional). Loci: U.Signature(profile=FormalSubstrate) declaration (typed tensor-operation declaration) -> mechanism (combinator algebra) -> UNM (dataset normalization; TransportRegistry^Phi) -> selection (architecture and hyperparameter set; Pareto set over accuracy@ratio and FLOPs@ratio) <-> planning (compute budget horizon) -> Work (exact training-run occurrences admitted under U.Work; any Delta is stated in a separate record) -> refresh (parity inserts; slice-scoped). Faces pin DescriptorMapRef.edition and DistanceDefRef.edition when QD telemetry values are shown; illumination remains report-only telemetry by default.

Show-C (Developed product, then application - network case). Development, later application, and further use keep separately identified TFS values when they have their own governed objects, Work occurrences, local position bindings, DesignRunTag boundaries, and change boundaries. A tool may be made, then used to make a chair, then the chair may be used while a person writes a text. Apply E.18.NET to select those TFS members and cite each exact production, use, participation, or other cross-member relation under its direct governor. Do not join them with U.Transfer; if a required relation has no governor, return missing-governor.

Show-D (FPF pattern development and use - network case). Pattern development, application to an EntityOfConcern, and use-found evaluation keep separately identified TFS values when each has its own governed object, Work, positions, and local state. Apply E.18.NET and cite the exact use, evaluation, evidence-return, or repair-trigger relation that connects their positions under its direct owner; if that relation has no governor, return missing-governor. E.18 still governs each member's internal structure and smallest reopened PathSlice; a role label or feedback arrow alone neither makes the members one TFS nor supplies the cross-member relation.

Cross-pattern boundary slice (QD archive). A QD selector returns an archive. Under E.18, the selection occurrence and returned archive may be positioned along one PathSlice in one TransformationFlowStructure; the archive is the selector-governed returned entity, not the slice, and selection returns a set or archive rather than a hidden scalar. Under A.20, the archive insertion or update step has a current CV class, CV.Status, and witness or refusal; no acceptance is inferred. Under A.21, a comparability gate or LaunchGate can publish a GateDecision only when that gate relation is current and consumes the relevant CV result. Under E.20, if a new selector mechanism-governing definition is introduced, the mechanism-governing definition is the locus for the meaning while suites and wiring only cite or bind it. These are four governed loci, not one prescribed work order.

Post-2015 SoTA echoes (illustrative): TAMP and MPC, MAP-Elites and QD (incl. CMA-ME), refinement-typed stacks, profunctor optics. Worked examples and Tell-Show-Show vignettes for P2W, comparator and archive, network cases over separately identified development and application TFS members, and one-TFS refresh specializations stay outside this selected-structure core unless a current pattern explicitly selects them.

#Bias-Annotation (per E.8 SG-bias slot)

• Acyclic-bias risk. Tooling accustomed to DAGs may discourage admissible feedback loops; E.18 explicitly permits loops with budget and sentinel controls (CC-E18-13, -18).
• Scalarization-bias risk. Cultural defaults to single-score rankings can suppress Pareto fronts and QD archives; E.18 keeps declared order relations and return sets visible (CC-E18-10, CC-E18-12).
• Interop-dominance risk. File and format ecosystems (CWL, RO-Crate, and lineage) can be mistaken for semantic sources; E.18 places them in InteropCard and keeps governing semantics in loci and gates.
• Over-formalization risk. Category-theoretic formalisms can obscure operational guard-rails; E.18 grounds crossings in exact positions, changed state bindings, direct governors, one A.21 gate, and a replayable CrossingRef (CC-E18-11, -23).
• Retrospective rewrite risk. Global rewrites break replay; E.18 confines them to edition bumps and slice-local refresh (CC-E18-16).

Mitigations. Profile-gated publication, audit of DecisionLog, mandatory edition pins, Lean-to-Core upgrade conditions, and conformance tests tied to PathSlice replay.

#Conformance Checklist — Unified checklist (normative)

Conformance use. This checklist is evidence for the selected-structure, flow-valuation, and crossing use guidance already stated in the Solution. It is not the first entry text for ordinary use and not a full audit regime by default; an item is applied only when its corresponding structure, crossing, publication, gate, refresh, or assurance claim is current. Before applying any item, name the Solution use it tests; if no such practitioner use is current, treat the item as auxiliary-only or not applicable rather than expanding the applied assurance or conformance material.

Conformance groups. Ordinary E.18 use starts with selected structure, single transfer relation kind, locus typing, CtxState preservation, and flow valuation. Crossing and launch items apply only when a GateCrossing, LaunchGate, StructuralReinterpretation, or work-boundary crossing is current. Publication and assurance items apply only when MVPK faces, edition pins, evidence carriers, decision logs, or replay are current. Extension and change items apply only when locus-kind scope, budget and refresh behavior, or UNM and comparator editions are being changed or consumed downstream.

Coupling note. CC-E18‑07 (CV⇒GF) and CC-E18‑21a (Decision join) together ensure that any GateFit‑scoped GateCheckRef returns abstain until the aggregated CV status equals pass; CV and GF separation remains intact. Scope note (E.18 vs named governing patterns): Detailed mechanism-scoped checks and publication obligations are governed by the current patterns named in this pattern's Relations. E.18 fixes only selected-structure obligations: single U.Transfer relation kind, gate crossings, valuation, publication pins, CV and GF boundary, and slice-local refresh.

Glossary (additions)

• Open-world species - non-exhaustive domain-scoped locus specializations that map to the minimal locus baseline and name a governing pattern.

• Signature locus - structure-positioned use of A.6.0 U.Signature (universal block). It is a governed 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=<current governing pattern id> (e.g., kind=Mechanism; KindDefinition=A.6.1).

• Semantic Bridge boundary — F.9 governs only 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 publication or check lexeme used inside GateCheckRef, not a structure locus kind. No GateCheckKind becomes an E.18 Check locus unless an OperationalGate(profile) locus is actually present.

• GateCheckRef shape (publication lexeme governed by A.21). Where publication faces over a selected structure carry GateChecks, a GateCheckRef is a record defined by A.21; E.18 constrains only where such faces carry those refs along transformation-flow paths.

GateCheckRef := { aspect, kind, edition, scope } with: aspect ∈ {ConstraintValidity, GateFit}, kind ∈ GateCheckKind, edition ∈ Editions, and scope ∈ {lane | locus | subflow | profile}.

• GateDecision, GateDecisionRationale, and GateDecisionExplanation (terminology). — GateDecision — the aggregated lattice value returned under A.21 by the exact OperationalGate(profile) aggregation over a specific {GateProfile, GateCheckRef[]}. — GateDecisionRationale — the minimal structured rationale for that GateDecision: per‑check outcomes, profile‑bound folds, and published evidence or witness references on the DecisionLog; it records why the GateDecision is admissible under the active profile. — GateDecisionExplanation — an optional human‑readable narrative derived from the GateDecisionRationale; it does not carry the decision value. While aggregated ConstraintValidity ≠ pass, GateFit‑scoped checks return abstain; any GateFit‑oriented GateDecisionExplanation does not apply.

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 are governed by 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 A.21-governed gate; it is not a semantic Bridge or gate decision.

• Admissible path - a typed path obeying the GateCrossing discipline (no hidden crossings; witnesses present), Gamma-pinned on compare and launch, and T^D<->T^R only at LaunchGate; see S2.

#Common Anti-Patterns and How to Avoid Them

#Gating Profiles (applied to E.18)

This table is a selected-structure coverage table for E.18 crossings and path slices. It does not govern GateProfile semantics. A.21 governs gate decision semantics, folds, DecisionLog minima, and the GateFit check-catalog boundary.

Gating is expressed as publication-gating per E.17 profiles. The structure model aligns with the CC items listed for the chosen profile; broader obligation profiles include all narrower-profile items.

Recommended defaults (non-normative, tie-in to A.21 and G.11). Profiles inherit along a PathSlice; local overrides only add GateChecks; weakening uses a new PathSlice and refresh wiring through the current G.11 locus when refresh wiring is current.

#E.18 LEX Discipline (registration)

Register Tech tokens (ASCII) used by this pattern with twin labels: TransformationFlowStructure, TransformationFlowValuation, StructuralReinterpretation, OperationalGate, GateCrossing, CrossingRef, CrossingBundle, GateProfile, GateCheckRef, GateCheckKind, DecisionLog, USM.CompareGuard, USM.LaunchGuard, FlowPositionRef, SubflowRef, FlowEmbed, SentinelId, PathSliceId, SliceRefresh, FinalizeLaunchValues, VALATA. Bridge, BridgeCard, and CL retain their F.9/C.2.1 meanings and are not E.18 crossing tokens. Reference MVPK E.17 naming for faces. CtxState Extension Registry. Register any extra CtxState slot beyond ⟨L,P,E⃗,D⟩ with: slot id, informal intent, partial‑order rule (with neutral or absorbing), SquareLaw compatibility note, and the Gate profile or profiles allowed to change it. Absence of registration ⇒ non‑conformant.

#Consequences

Benefits.

1. Universality with discipline: one transfer relation kind and explicit gates eliminate second hidden work and method orders and make cross-domain flows (ML, supply-chain, TAMP and MPC, scientific work structures) uniformly analyzable and auditable.
2. Comparability and replayability: CSLC and edition‑pinned comparators prevent covert scalarization and enable declared set returns and reproducible decisions.
3. Locality of change: sentinel subflows restrict refresh to affected PathSlices; large selected structures remain stable under frequent edition bumps.
4. Clean DesignRunTag fold: LaunchGate and DesignRunTagConsistency stop premature claims of actual launch values. Actual bindings obtain through exact direct relations or A.6.1 application bindings involving one exact Work occurrence; acceptance claims and telemetry records remain separate epistemes or relations that may designate that occurrence.
5. Assurance visibility: MVPK makes GateProfile and DecisionLog records locally checkable and cacheable for the same {PathSlice, GateChecks, Editions}.

Trade‑offs. a) Higher upfront modeling cost: exact crossing positions, changed-binding governors, gate refs, and optional durable crossing bundles demand care; mitigated by keeping ordinary local crossings unbundled when no downstream reliance needs replay. b) Longer transfer face sets: MVPK faces are verbose by design; lean face sets can be used for low-risk segments. c) Tooling alignment: some incumbent DAG-only orchestrators conflict with budgeted cycles and set-return semantics; adapters project E.18 semantics to their interop boundary, while E.18.2 carries the mathematical graph-description relation when that projection matters.

#Rationale

E.18 states strict separation of concerns (selected-structure scope only); specialized semantics are governed by the patterns named below for those current relations:

• What the selected structure is: structure-positioned transformation and slot-filler loci plus the single relation kind U.Transfer; graph, morphism, tuple, category, or algebra language is used only when a current mathematical description or lens expresses the relation.
• Where and when structural state changes: only at one OperationalGate(profile), with exact source and receiving positions, changed CtxState bindings, their direct governors, and CrossingRef. An F.9 Bridge, bounded-use claim, reliance, optional card, and optional CL appear only for a separately established cross-semantic use.
• How comparability works: UNM is the single governing locus for unit, plane, and transport declarations, and selectors operate only on normalized, edition-pinned comparators, returning sets or archives rather than totals. Edition-aware pins and archive semantics are checked through A.19.SelectorMechanism, C.18, C.19, G.5, G.9, and G.11 for current selector or archive cases.
• How change propagates: sentinel-bounded PathSlice refresh; editions are monotone; LaunchGate is the sole pre-run decision locus for the selected workEntryClaimRef, while actual launch values are established only through independently obtaining direct relations or A.6.1 bindings involving the later Work occurrence and may be cited by a separate finalization witness.

This arrangement gives checkable conditions for functorial publication (commuting squares on crossings) and orthogonality of inner technical validity (ConstraintValidity) to context fit (GateFit), which in turn keeps gate aggregation order-independent under the CV=>GF activation predicate.

#SoTA-Echoing (post-2015, multi-Tradition)

Each row states the source idea, the FPF invariant E.18 adopts, the practitioner implication, and the shortcut it rejects. Vendor, tool, and literature tokens are informative; the invariant and practitioner implication carry the pattern explanatory work.

Cross-tradition note. Rows 1-3 (compositional graph practice), rows 4-5 (publication and reproducibility practice), row 6 (controls and robotics), row 7 (evolutionary search), and row 8 (programming-language semantics) jointly position E.18 across multiple traditions per E.8, but each row is retained only because it changes a practitioner implication or rejected overread.

#Relations (explicit pattern-to-pattern relations)

• E.18 -> coordinates with -> A.15.5 WorkEntryReadiness. A selected structure may position a launch or work-boundary readiness locus only as a relation to A.15.5; E.18 supplies the crossing, path, slice, LaunchGate position, and structure-local pins, while A.15.5 governs FullKitCondition, planned preparation references, commitment disposition, resource-readiness references, and whether intended work is ready to enter performed-work execution.
• E.18 -> coordinates with -> C.32.P2S ProblemToStructureArchitecturingFlow. P2S may cite a selected transformation-flow structure, path, crossing, or valuation as architecture content or uncertainty. When Plain wording calls that value a method handoff, work handoff, or feedback input, C.32.P2S must identify the independently governed receiving entity or relation occurrence, its participants, obtaining condition, and direct governor; those labels supply none of them. E.18 still governs the transformation-flow structure and does not become the whole architecturing flow.
• E.18 -> coordinates with -> C.33, C.34, and C.35 structural-information patterns. When a transformation-flow carrier, path, generated map, or independently governed changed entity or relation occurrence that carries or describes structure needs architecture-specific capture, preservation, or discovery adequacy, use C.33, C.34, or C.35 for that architecture use. Before a selected structure is returned to a named architecture use, cite the exact selector or selection relation, or another direct relation occurrence, that returns it; name that relation's predicate, participants, obtaining condition, occurrence identity, and direct governor. Also cite the exact source-to-use relation and the direct owner to which the receiving architecture claim exits. C.33, C.34, and C.35 are governing patterns, not participants in those relations. E.18 keeps the selected transformation-flow structure, path, crossing, valuation, and any exact slice-local subject relation cited by that architecture use visible; it supplies no generic result, return, or receiving relation.
• E.18 -> coordinates with -> A.22.CGUS through E.18.3 when transformation-flow unfolding is current. Under E.18, independently identify the one-TFS or parent-relative internal-subflow substrate; use E.18.NET for an independently identified network substrate. E.18.3 qualifies one separate A.22-selected CGUS only when that CGUS uses exact substrate positions, bindings, and already-obtaining occurrences under current applied-condition claims, any E.18 GuardFail events with their gate-assignment facts, and any independently defined guard-relation occurrences. The substrate ref does not resolve to selectedCGUSRef. Neighboring values and stronger claims remain independently identified and connect through exact supporting relations, predicate-definition content, and current facts. Ordinary E.18 use is not automatically substrate for a CGUS, and narrative, abductive, typing-grounding, improvement, evidence, refresh, and first-entry seed structures do not become E.18 structures by route-shaped wording alone.

Relation rows use the named relation kinds builds_on, constrains, coordinates, specializes, publishes_on, requires, and provides_checks_for.

Foundations

• E.18 -> builds_on -> E.17 MVPK (for publications of selected-structure content). Faces, pins, lanes, functorial publication, Lean, Core, and Regulated profiles.
• E.18 -> builds_on -> A.6.0 U.Signature and A.6.1 U.Mechanism. Locus kinds and governing-definition content boundaries.
• E.18 -> builds_on -> A.7 Strict Distinction (EntityOfConcern, Description episteme, Description episteme admitted for specification use, and publication and carrier separation). No new claims on faces; publication faces project selected structure, crossing, or flow-valuation information without becoming the governed selected structure, Description episteme, specification use, evidence, gate decision, work occurrence, or carrier.

Flow semantics and checks

• E.18 -> coordinates -> A.20 Flow Constraint Validity. CV checks apply inside transformations and transformation-flow valuations; no declaration or translation of planes or units in CV; error, timeout, or unknown folds follow CC-E18-22 as the minimum default (profiles can be stricter). Terminology discipline (A.20 boundary). In CV scope, publications use status and witness language; GateDecisionRationale and GateDecisionExplanation are reserved for gating and do not apply to CV.
• E.18 -> coordinates -> A.21 GateProfilization (GateFit scope). GateFit-scoped GateChecks are aggregated by OperationalGate(profile) with CV=>GF activation; the enumeration and publication shape of GateChecks are governed by A.21. Equivalently: a GateFit decision different from abstain appears only when aggregated ConstraintValidity = pass; otherwise the GateDecisionExplanation (GateFit-oriented) does not apply.
• E.18 -> uses -> USM.CompareGuard and USM.LaunchGuard. Guards publish scope and responsible gate; guard failures are handled by the declared gate.
• E.18 -> coordinates with -> F.9 and F.17 only for a current cross-semantic use. E.18 owns the structural GateCrossing; F.17 identifies the two exact local sense cells and F.9 alone decides whether a semantic Bridge obtains. The proposed structural use, reliance, optional Bridge Card, optional CL, actual gate decision, and any penalty remain separately governed.
• Operational interpretation (default): Eulerian. A flow is a valuation over U.Transfer; transfer relations carry assurance-only operations (see CC-E18-17); no token-passing semantics are assumed.

UNM and comparability

• E.18 -> constrains -> UNM declaration and use loci. CG-Spec, ComparatorSet, and UNM.TransportRegistryPhi declarations are governed by UNM; normalize-then-compare is mandatory.
• E.18 -> constrains -> G.5 SelectionAndTuning. Set-returning, comparator-pinned decisions and no hidden scalarization; cite the exact selector-declared set, handoff, abstain, or escalation outcome. Any next-step tuning remains in its separately governed plan, plan-item relation, configuration, or policy, with no launch-value slot filling.
• E.18 -> constrains -> G.11 EvaluatingAndRefreshing. EditionBumpProposal, two-phase update through the UNM declaration locus, and path-local refresh. When current, identify RefreshPlan@Context, dated Work, later measurement and calibration, and RefreshReport@Context separately; no request, plan, record, audit artefact, or publication substitutes for another or becomes the returned world-side result by label.

Work boundary

• E.18 -> coordinates with -> A.15.1 Work occurrences and A.15.5 work-entry readiness. LaunchGate consumes one exact prospective workEntryClaimRef and keeps FreshnessUpToDate hard before an attempted run. If Work occurs, A.15.1 governs the identity of the exact Work individual and requires the relevant world-side relations involving it to obtain independently; a separate FinalizeLaunchValues witness, telemetry record, or acceptance claim may designate the occurrence but is not that occurrence.
• E.18 -> coordinates with -> A.3.4, A.15.1, and A.15.PROD at actual-change and production boundaries. A Transformation locus points to one independently identified actual change under A.3.4; an adjacent Work locus points to an exact dated occurrence under A.15.1. A work-causes-change assertion cites its direct subject governor or a local claim selected under A.6.RCD disposition 2. Production-work participation, entity-identity inception, and historically indexed production completion cite separate local A.15.PROD claims; E.18 neither derives them from proximity nor introduces replacement relation kinds.

Structure and reuse

• E.18 -> provides selected-structure base for transformation-flow families. Flow patterns such as P2W and EvaluatingAndRefreshing use E.18 for selected structure, valuation, crossings, guards, MVPK faces, and slice-local refresh. The current ontology is: A.3.4 governs each independently identified actual bounded U.Transformation; E.18 governs the selected compound structure over transformations and adjacent governed loci without asserting transformation composition; and the named governing patterns govern method, work, mechanism, work-to-change, production, evidence, publication, gate, decision, and refresh claims when those claims are current.
• E.18 -> coordinates with -> E.18.NET Network of Transformation-Flow Structures. E.18 owns one exact TFS, its FlowPositionRef, parent-relative SubflowRef, valuations, paths, slices, local state, and internal U.Transfer. E.18.NET starts only when independently identified TFS or nested-network members are selected with exact cross-member relation occurrences; it does not replace a detailed internal portion or several valuations of one TFS.
• E.18 -> coordinates with -> architecture transformation-flow relation patterns. When a selected transformation-flow structure is used in an architecture-flow relation, the architecture transformation-flow relation pattern records the relation between TransformationFlowStructure and ArchitectureOf@Context; E.18 keeps selected structure, crossing, and flow-valuation discipline.
• E.18 -> publishes_on -> E.17 MVPK views (PlainView, TechCard, InteropCard, AssuranceLane) for every transfer or locus where publication occurs; Lean mode applies only as per profile.

#Conformance Use Checks

1. Model lint: run static checks for CC-E18-01...25 (transfer relation kind, gates on crossings, CV=>GF, guard aggregation assignment, UNM declaration locus, SquareLaw).
2. Publication audit: sample a commuting square and a sentinel‑bounded subflow; verify pins and DecisionLog behavior on block or degrade.
3. Replay test: hold editions fixed; re‑run selection on a PathSlice; observe identical return‑sets; apply a bump; see only affected PathSlices refresh.
4. StructuralReinterpretation probe: construct one exact A.6.4 retargeting candidate; confirm source and receiving subjects, invariant, direct applicability, witness, unchanged CtxState, and PathSliceId locality. If cross-semantic correspondence is also claimed, test an independent F.9 Bridge and bounded-use claim. If the use depends on the parked legacy KindBridge/CL interface, return missing-governor.

Relation boundary: E.18 governs selected transformation-flow structures whose loci may bind independently identified actual U.Transformation values and structure-positioned adjacent governed values. It does not define a second change ontology, a transformation-composition relation, a work sequence, a method, a mechanism, a mathematical graph expression, or a publication record. A flow arrow, adjacency, shared work, common affected referent, or placement in one selected structure establishes neither an actual transformation nor transformation composition. When a selected-structure use raises bounded-transformation, dynamics-episteme, temporal-aspect, temporal-claim adequacy, work planning, performed work, work-to-change, production, evidence, assurance, gate, decision, architecture, structural-view, mechanism, selector, comparison, refresh, publication, or wording-use claims, name the direct governing pattern for that relation before relying on the structure.

When a selected structure locus, selected path, path slice, substructure, or flow valuation expresses or constrains one independently identified actual bounded transformation, use A.3.4 for the U.Transformation claim and E.18 for the selected structure, containing locus, pins, locus kind, crossing, publication, comparability, and refresh discipline. Cite the exact direct work-to-change governor when dated work is claimed to cause or realize it, and cite the separate local A.15.PROD claim when production-work participation, entity-identity inception, or production completion is current. E.18 locus kinds do not automatically fill slots in other patterns: Transformation points to A.3.4, Signature points to A.6.0, Mechanism points to A.6.1 and E.20, WorkPlanning and Work point to the A.15 work family, and Check points to A.20 or A.21 according to the current claim.

#E.18.1 P2W Child-Pattern Relation

E.18.1 is a child pattern for problem-to-work carry-through. It governs the practitioner carry-through practice and, when durable replay is needed, its optional C.2.1 note or stop-description claim content. It introduces no local P2W relation kind or occurrence. Each next method, plan, dated Work, transformation, evaluation, decision, entity, or relation occurrence remains with its direct owner. A P2W application consumes this pattern's selected-structure discipline only when a named receiving decision or use relies on an explicit TransformationFlowStructure, path, flow valuation, transfer, crossing, or gate position; when branches, joins, guards, or governing-pattern positions must be recoverable, E.18.3 governs that fuller structure. In this split, E.18.1 carries the accepted problem-side claim and local continuation, while E.18 carries selected transformation-flow structure without making it mandatory for ordinary P2W use.

#E.23 Improvement-Loop Boundary Relation

When a transformation-flow structure contains a cycle, budgeted retry path, monitor/escalate path, or slice-local refresh relation, E.18 governs the selected structure: loci, transfer relation, path or slice, gate positions, pins, and refresh locality. The cycle becomes an E.23 quality-improvement loop only when a named object version is changed and then re-evaluated by a declared object-under-improvement evaluation. Otherwise the cycle remains a transformation-flow structure, work-control cue, gate relation, or refresh relation governed by its direct governing pattern.

Agent-loop diagrams often contain both kinds. A monitor/retry/escalate loop over physical execution state may be a valid TransformationFlowStructure and may include an A.21 gate, but it does not prove that the controlled object improved. If the harness itself is improved, E.23 governs that object-version improvement; if the harness only runs work, the A.15 family governs the work occurrence.

#E.18.3 Constraint-Governed Unfolding Relation

Open E.18.3 when one A.22-selected CGUS is being qualified by its use of an independently identified E.18 substrate. Name selectedCGUSRef separately from the mutually exclusive one-TFS, parent-relative internal-SubflowRef, or E.18.NET substrate branch; then recover the transformed concern, exact substrate positions and bindings, already-obtaining transfer or dependency occurrences, paths or slices, crossings, applied-condition claims, any E.18 GuardFail events with their gate-assignment facts, any independently defined guard-relation occurrences, optional valuation, preserved and lost transformation structure, non-admissible overreads, and the ordinary stop or reconsideration question.

This relation is deliberately narrow. E.18.3 can organize a transformation-flow slice inside P2W, P2S, work-control, architecture-feedback, evidence, narrative-publication, or refresh situations, but every stronger neighboring claim needs its independently identified value, exact supporting relation, applicable predicate-definition content, and current facts. A path card, graph expression, route prose, workflow diagram, or demonstrative slice remains a description or teaching slice until both the A.22-selected CGUS and its independent E.18 substrate use are recoverable; the pattern reference adds no connection relation.

#E.18:End

Last Updated: 2026-08-04 — upstream FPF commit 67092138 (github.com/ailev/FPF)