E.18:5.2 - 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. E.18 specifies the concrete path and slice publication pins and identifiers (PathId, PathSliceId, Gamma_time on compare and launch faces); apply A.20 when exact internal-constraint results are current, 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 identified 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 cross-boundary relation predicate and occurrence rule. 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). A current A.6.4 arrow r, affirmative q, and current-case judgement of satisfies with unchanged CtxState follow CC-E18-06-EX without a crossing; if the same case changes a CtxState binding, the changed binding appears at exactly one gate; (c) each GateCrossing on p carries the SquareLaw witness required by its exact current crossing rule, if that rule requires one (CC-E18-23), while the exact case facts used by the current-case judgement remain separate from q; they neither identify r nor determine the judgement without comparison against q; (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 describes that carry-through practice and defines the local claim content; it introduces no ProblemToWorkCarryThroughRelation@Context, and the path is not such a relation. Each returned method, plan, Work, transformation, evaluation, decision, entity, or relation occurrence keeps its independent identity and uses the pattern that defines or constrains the current claim about it. 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). A SquareLaw condition enters only where an exact current crossing rule requires it. This yields comparability, reproducibility, and slice-local refresh.