#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 adjacent values whose definitions or constraints are identified independently. The EntityOfConcern is the selected structure itself: loci for those transformations and adjacent 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 identified 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, the exact definitions or tests used by the comparison, 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. Use E.18.2 for mathematical descriptions of this selected structure, including graph, algebra, category, tuple, path, slice, morphism, quotient, fold, refinement, factorization, or wiring expressions; use C.29 when mathematical-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 adjacent values whose definitions or constraints are identified independently. The EntityOfConcern is the selected structure itself: loci for those transformations and adjacent 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 identified 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, the exact definitions or tests used by the comparison, 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. Use E.18.2 for mathematical descriptions of this selected structure, including graph, algebra, category, tuple, path, slice, morphism, quotient, fold, refinement, factorization, or wiring expressions; use C.29 when mathematical-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. 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, apply the pattern whose Solution answers that exact question.

First useful structure use. Name the selected transformation-flow structure, its locus kinds, the single internal U.Transfer relation, and the current position, path, or path slice when one is needed. Stop there when the application makes no separate crossing, launch, publication, comparison or selection, cycle or refresh, or assurance claim. A profile may strengthen a check for one of those current claims; it does not make an absent claim, object, record, or Work occurrence current.

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 that stabilizes the controlled value.
    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 and its local account states the from/to values, establishing basis, and any applicable declaration, rule, and current application; 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 identified loci first. If dated L4 is claimed to cause or realize L1, first use A.6.RCD disposition 1 when a current exact work-to-change predicate and the case facts answer that question. Use disposition 2 only when no current direct predicate expresses the needed compound claim, the admitted base predicates and constructor semantics support it, and one local C.2.1 claim closes this receiving use. That local claim admits no reusable predicate, relation kind, RelationSignature, or occurrence semantics. Keep the dated Work, actual Transformation, and claim-bearing episteme distinct; shared time, adjacency, or structure membership 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 the facts that satisfy its test. 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 its predicate and occurrence-identity rule plus exact participants, applicability, and case facts;
• 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 the patterns or declarations that define them, 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, use the current exact predicate and case facts under A.6.RCD disposition 1, or—only when no direct predicate expresses the compound claim and admitted base-predicate semantics support it—one local C.2.1 claim under disposition 2. Keep the Work, Transformation, and claim separate. 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 decisions, [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, the separation of internal constraint results from GateFit results, and refresh locality in one structure pattern without turning every 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 one exact function-oriented viewpoint P selected through an exact U.ViewpointRef, those valuations may concern transformations of one already identified target holon, for example in a declared U.Capability or transformation claim; VP.Functional, when used, is only P's ordinary designator. 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 identified positions.

E.18.1 P2W Problem-to-Work Carry-Through begins with an accepted ProblemCard@Context claim and carries it into whichever method, plan, dated Work, transformation, evaluation, decision, entity, relation occurrence, interpretation, stop, branch, or local return becomes current. For each continuation, state the exact current question and apply the pattern whose Solution answers it. Before calling one of those values a result, say what it is a result of or for and cite the fact, relation, or binding that makes that reading true; otherwise stop. Apply the adjacent result-claim assurance check only when a named reliance use needs it, and never mistake the flow position for assurance. A first-principles specialization may traverse a path such as U.Signature(profile=FormalSubstrate) -> U.PrincipleFrame -> U.Mechanism -> U.ContextNormalization (UNM) -> selector relation -> one exact U.WorkPlan, optionally with declaration-local A.15.3 planned-filling rows -> 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. Without a common structure discipline:

• flows look ad-hoc and non-comparable;
• structural crossings fail to name the changed state binding, its from/to values and establishing basis, any applicable rule and current application, or the separate gate decision;
• 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 identified 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 independently defined or constrained 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 that satisfies the current selector and comparator definitions or tests, one exact A.15.2 U.WorkPlan optionally carrying declaration-local A.15.3 planned-filling rows, 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 the facts, predicate, and identity rule needed for a transformation-composition claim.
• 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 has one local per-binding account that separates from/to values, establishing facts or claims, applicable declarations or rules, and current applications. An A.6.4 arrow r, an affirmative bounded-use assertion q, and a current-case judgement of satisfies, with unchanged CtxState, follow the limited StructuralReinterpretation route in CC-E18-06-EX instead of becoming a crossing. Transport conversions cite the exact registry entry, conversion rule, and applicable policy. 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 changed-binding account 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 supplies no generic plane conversion. Cite the current declaration and applicable conversion rule by value. Return missing-governor only when no current conversion predicate or rule can state the attempted crossing; return missing-information when the needed declaration or case values are unavailable; when the rule and facts are current, state its positive, negative, or inapplicable result rather than a generic blocker.
• E⃗ := Edition vector — a partial map edition_key ↦ EditionId whose members cite each versioned value, its exact edition, and the registry or declaration that assigns that edition; G.11 defines the edition-bump and refresh records, while E.17 defines 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 E.18 carries the path or slice evidence. Add A.20 only for a current internal-constraint claim, 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 under the definition or test for that exact claim; 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 under D14.16 with the exact A.6.RCD result: TC-MWH missing-governor only when no current predicate, applicability condition, or occurrence rule states the required contribution, compatibility, parthood, or whole-identity claim; TC-MWH factually unsupported when the governor exists and the available case basis is sufficient to apply its positive test but that test fails; and TC-MWH missing-information when a fact needed to decide the test is unavailable. A negative needs its own applicable non-obtaining criterion or complete closure basis and satisfying facts. 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 ≡ one exact A.15.2 U.WorkPlan when that plan occupies the structure position. Declaration-local A.15.3 SlotFillingsPlanItem rows remain content inside that WorkPlan and do not occupy a locus or identify a relation independently.
• 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) when a gate/check locus is present. A.20 supplies exact internal-constraint results when those constraints are current; A.21 defines the gate profile, independent check retention, result mapping, aggregate decision, and publication minima when a gate decision is current.
• StructuralReinterpretation is only the E.18 position of an independently identified A.6.4 arrow r, bounded-use assertion q, and current-case judgement; it is not a new retargeting kind. E.18 records r and q, the exact case basis and judgement result needed by this placement, and path-slice locality. q's ClaimGraph carries the invariant, visible loss, named receiving use, conditions, and affirmative or negative polarity; the judgement separately reports satisfies, fails, or cannot decide. A cannot decide result names the exact missing fact and reopen condition. F.9 is additional only when the same case asserts a semantic relation between two exact F.17 local senses and its predicate obtains; its bounded-use claim, optional CL, evidence, and reliance remain separate. OperationalGate is the E.18 check locus when a gate or check position is present. A.20 supplies an exact internal-constraint result when that claim is current. When a gate decision is current, A.21 supplies the exact profile application, independently identified check-application results, GateDecisionResult, and rationale. A DecisionLog is added only for a current audit, history, replay, or reuse need. E.18 adds only a structure-local placement rule: when r, an affirmative q, and a current-case judgement of satisfies are current and CtxState is unchanged, record their basis and PathSliceId without calling the placement a GateCrossing. If any CtxState binding changes, use a GateCrossing and state the changed binding's from/to values, establishing basis, and any applicable declaration, rule, and current application. A Bridge, card, UTS row, optional CL, witness publication, gate decision, or permission claim neither identifies r nor supplies q's polarity or the case judgement.

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, an A.6.4 arrow or use assertion, a penalty, or a publication occurrence.

Per-binding account. For an ordinary local crossing, one sentence or table row is enough: name the changed binding, its from and to values, the facts or claims that establish those values for this case, and any declaration or rule whose application is current. No record is required. When a named downstream use needs replay, the same distinctions may be packaged in this local E.18 block:

ChangedBindingAccount:  # local replay block, not an FPF kind or relation
  changedBindingId
  fromValueRef
  toValueRef
  establishingFactRefs[]?
  establishingClaimEpistemeRefs[]?
  applicableDeclarationRefs[]?
  applicableRuleRefs[]?
  ruleApplicationRefs[]?
  honestStop?

Facts or claims establish the case values. A declaration or rule supplies only the meaning, admissibility condition, or constraint it actually states; ruleApplicationRefs is present only when the current case depends on that rule applying to these values. A gate decision evaluates the crossing under A.21 and does not establish the underlying facts or apply a rule by itself. A permission claim is separate under A.2.8.PER and is cited only when authorization is current. None of those items entails another.

[A.20](/generated/patterns/A.20) may supply an exact current constraint-validity result and witness or reason; [A.21](/generated/patterns/A.21) supplies the gate profile, retained check results, mapping, aggregate decision, and decision log. Neither supplies a changed locality, plane, edition, tag, retargeting fact, rule application, or permission claim.

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 required per-binding accounts.

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](/generated/patterns/E.17), not a constituent of the crossing or gate decision. It contains the CrossingRef, ChangedBindingAccountRefs[], GateId, the current profileApplicationRef and GateDecisionResultRef when a gate decision exists, an optional current DecisionLogRef, optional separately current PermissionClaimEpistemeRefs[], 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 one exact current policy applies to this crossing and its rule application to the crossing facts supports that penalty. Cite the policy and PolicyIdRef; when the claim also depends on who may issue or enforce it, cite the separately obtaining direct authority relation and its actual participants. E.18 derives no penalty from CL, plane difference, edition difference, or Bridge publication. If the policy, applicability, rule application, or any separately required authority fact is absent, make no penalty claim and infer no 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. 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.

#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 identified loci or flow valuations. A join relates several identified 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 set or archive returned by the exact selector relation, the selected-set result declaration when current, the exact publication relation when that value is published, and the smallest refresh scope when currentness changes. Apply the definitions and tests in A.19.CPM, A.19.SelectorMechanism, C.18, C.19, and G.5 when comparator, selector, archive, pool, or result-declaration claims are current; use E.17 for a source-backed publication face and return to source, E.24.PUB for the publication occurrence, form, carrier, audience, bounded use, and availability, A.21 for a gate claim, and G.11 for a refresh claim.

For evolutionary-engineering work, the same selected structure may contain, for example, loci for variant generation, retention, archive or front treatment, comparison, selected-set result declaration, actual publication, architecture-candidate movement, planning, performed work, effect measurement, residual triage, and refresh. E.18 defines only the structure, loci, U.Transfer, crossings, valuations, pins, and slice-local refresh. Apply the definitions and tests in C.18, C.19, and G.5 when archive, pool, or selected-set result-declaration claims are current; use E.17 for a source-backed publication face and return to source, E.24.PUB for the publication occurrence, form, carrier, audience, bounded use, and availability, C.11 and C.30 for their decision and architecture-candidate claims, the A.15 family for planning and performed Work, and G.11 for refresh.

#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 source for:

• the set of face designators (PlainView, TechCard, InteropCard, AssuranceLane),
• pin discipline and Publication Characteristics (PC),
• “no new claims; in the optional morphism profile, no re‑listing of inputs and outputs and no Γ‑semantics on publication morphisms”.

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, ChangedBindingAccountRefs[], GateId, and any current GateDecisionResult, optional DecisionLog, policy-application, or permission-claim 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 versioned value cites that exact value 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. Every current compare or launch publication face on an E.18 path pins Gamma_time; implicit latest is not admissible. A.21 cites the exact current profile application and qualification window. 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. A source unknown, notRun, or error remains explicit before the current profile rule maps it to a gate decision.

Reminder. MVPK supplies the "signature" naming rule, the optional morphism profile's input-output rule, arithmetic-visibility rules, and material numeric-pin requirements (E.17 §5.4-5.5). E.18 does not weaken those rules; CC-E18-09 states the additional constraints on faces published along transformation-flow paths.

Lean publish-mode (AssuranceLane-Lite). Lean changes publication faces only, not policy or checks. A current face cites the profileApplicationRef, identified GateCheckApplicationResult refs, and GateDecisionResultRef; it cites a DecisionLogRef only when an audit, history, replay, or reuse record is current. The underlying check-application results remain unchanged.

Decision stability and idempotency (gate-local). A gate decision is recomputed when an input named by A.21 changes. Only a current reuse, cacheability, or stability claim needs an equivalence witness covering the inputs whose equality that claim relies on; an optional DecisionLog may cite it. Use G.6 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 change is not established by a UTS row, mapping label, card, CL, or GateCrossing; a kind change alone only reopens the C.2.1 identity test. First recover the exact A.6.4 arrow r from its endpoints, arrow rule or designator, and formal equivalence. Separately recover q, whose ClaimGraph states the invariant, visible loss, named receiving use, conditions, and affirmative or negative polarity. Compare the exact current facts with q and keep the current-case judgement separate: satisfies, fails, or cannot decide; for cannot decide, name the exact missing fact and reopen condition. Any application occurrence and Work remain separate. If the use also needs a semantic relation between two exact local senses, apply F.9 separately and keep its own bounded-use claim, optional CL, evidence, and reliance separate.

#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 applicable conversion rule are cited. Return missing-governor only if no current conversion predicate or rule can state the crossing, and missing-information if the declaration or case values needed to apply it are unavailable; otherwise state the rule's positive, negative, or inapplicable result.

If one exact current policy applies and its rule application supports a penalty, cite the policy and PolicyIdRef and publish the penalty only in the assurance lane specified by that policy. When the claim also depends on an issuing or enforcing authority, cite the separately obtaining direct authority relation and its actual participants. 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 publication records for sets or archives (e.g., QD archives) pin DescriptorMapRef.edition, DistanceDefRef.edition, and CharacteristicSpaceRef.edition when applicable; refresh is slice-local. For current selector, archive, pool, selected-set result-declaration, comparator, or refresh claims, apply the definitions and tests in A.19.SelectorMechanism, C.18, C.19, G.5, G.9, and G.11. For actual publication, use E.17 for a source-backed face and return to source and E.24.PUB for the occurrence, form, carrier, audience, bounded use, and availability.

#S6 - Cycle discipline (Selection ↔ Planning)

• The selected structure may center a loop between the SelectionAndTuning locus, whose relation satisfies the named selector and comparator definitions or tests, and the WorkPlanning locus, which binds one exact A.15.2 U.WorkPlan. Any A.15.3 planned-filling row remains declaration-local content inside that WorkPlan.
• The Selection-Planning loop is represented under local budget and max_iter in Γ_time; at expiry, the exact selector 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 identified U.WorkPlan with any declaration-local A.15.3 planned-filling rows, or a separately identified configuration or policy that passes its own applicable rule, carries that tuning; it is not another entity returned by the selector. Further improvement is placed in the next PathSlice only through that explicit planning, configuration, policy, or refresh continuation.
• UNM occurs before the loop. When the normalized basis shows missing or stale measurements, retain the finding returned by the UNM test. A freshness request remains a request. If the receiving use plans measurement refresh, A.15.2 identifies the exact WorkPlan; when a reusable declaration member must be pinned, A.15.3 adds only a declaration-local row inside that WorkPlan. For later dated refresh Work, recover each exact actual performer through A.13 and let A.15.1 independently admit the occurrence. Add F.6 only when the receiving use also consumes precise assignment-bound attribution; F.6 neither discovers the performer nor supplies classification, and its failure leaves the Work intact. Keep the later measurement and calibration separate. A RefreshReport@Context is likewise separate from the request, plan, Work, measurement, and calibration. A publication that states a calibration target cites the calibration reference and any applicable transport-conversion rule. A penalty requires its own current policy, applicability, rule application, and any authority relation actually used; calibration, conversion, registry publication, or a report 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. For current selector, archive, pool, selected-set result-declaration, comparator, or refresh claims, apply the definitions and tests in A.19.SelectorMechanism, C.18, C.19, G.5, G.9, and G.11. For actual publication, use E.17 for a source-backed face and return to source and E.24.PUB for the occurrence, form, carrier, audience, bounded use, and availability.

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

Profile-application boundary (cross-reference). A.21 distinguishes a GateProfile description from the exact current fact that applies it to one gate, subject, action, scope, and window. E.18 cites that application only where a current gate or crossing needs it; a profile name, matrix, branch, or PathSlice supplies no application or authority by itself.

Scope-translation guards (cross-reference). A.2.6 defines and tests 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. Use A.21 for gate aggregation; no CL value or Bridge Card decides the guard.

Error, timeout, or unknown (profile-bound). Keep each source error, timeout, unknown, and notRun result explicit. The exact current profile application cites the rule and edition that maps that result to abstain, pass, degrade, or block; a profile name alone supplies no fixed fold, and no missing or unrun required result maps to pass or neutral abstain. The GateDecisionResult retains the mapping and rationale.

#S9 - Transport and crossings

• A GateCrossing records one selected-structure transition between exact source and receiving positions and CtxState bindings at one exact gate whose profile and decision test come from A.21. Cite A.2.6 for locality and scope membership, the current plane or units declaration and conversion rule, each versioned value and exact edition 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. If no current predicate, applicability condition, occurrence rule, conversion rule, or decision test can state a claim on which the crossing depends, return missing-governor. If the governor exists and the available case basis is sufficient to apply its positive test but that test fails, return factually unsupported; if a fact or declaration needed to decide the test is unavailable, return missing-information. State a negative crossing only under an applicable non-obtaining criterion or complete closure basis and satisfying facts.
• 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 change remains with A.6.4. E.18 may place the independently identified r, q, and current-case judgement; it creates none of them, records no operation application by implication, and supplies no KindBridge or mandatory CL. 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 ChangedBindingAccountRefs[], with gate-decision and permission-claim refs separate when current; an F.9 block is added only for a separately established semantic Bridge and bounded use.

#S12 - Exact viewpoint references to E.18 constructs

Use this when. Use S12 only when a current claim maps one exact viewpoint episteme to exact E.18 constructs. Ordinary work with a selected transformation-flow structure, valuation, path slice, or crossing does not open S12, and one mapping may stop after one row.

Imported interface. E.17.0 defines viewpoint membership and episteme–viewpoint conformance. E.17.1 defines local catalogue declarations and U.ViewpointRef members. E.17.2 provides the project-local TEVB authoring template; it ships no catalogue, reference, or viewpoint episteme value. S12 uses those results and does not copy their catalogue or conformance procedure. E.24.PUB defines publication, and C.29 defines any separately current representation or correspondence.

First useful move. Resolve one viewpointRef : U.ViewpointRef under the effective reference scheme to the named viewpoint episteme. Then name only the E.18 loci, transfer occurrences, gates, crossings, paths, or valuations used by the mapping claim. The reference is not a relation, the viewpoint episteme is not a template position, and the mapping makes neither the E.18 constructs nor their conformance relation obtain.

Stop there unless the current claim separately needs candidate-view conformance, whole-family coverage, retargeting, cross-context meaning, publication, representation, or actual Work. Follow the defining pattern for that claim rather than reproducing it here. A token such as VP.Functional may remain P's ordinary reader-facing designator after resolution; it is not a viewpoint id, reference, family member, or conformance result.

The four rows use one grammar: an exact reference resolves exact P, and a separately current mapping claim names the E.18 constructs it uses. A project may use one row without materializing the other three. Four rows are required only by a separately identified whole-family coverage claim under E.17.1/E.17.2.

Conditional map row. Persist UTS.ViewpointMap only when the mapping claim is made or consumed:

UTS.ViewpointMapRow:
  EffectiveReferenceSchemeRef:
  ViewpointRef: exact U.ViewpointRef
  ResolvedViewpointEpistemeRef: exact P
  PrimaryE18ConstructRefs[]:
  MappingClaimEpistemeRef?: when the mapping claim is persisted separately
  CandidateEpistemeRef?: only with an obtaining E/P conformance relation
  EpistemeViewpointConformanceRelationRef?: only with CandidateEpistemeRef
  CrossingRefs[]?: only crossings consumed by the mapping
  GateRefs[]?: only gates consumed by the mapping
  PublicationUseRef?: only an independently current E.24.PUB use
  RepresentationRelationRef?: only an independently current C.29 relation

The optional branches carry references to independently established results. They do not repeat the classification, assignment, responsibility, Work, publication, representation, Bridge, or retargeting tests. If a semantic-context comparison is current, use the exact F.17/F.9 path and bounded-use claim; catalogue provenance or equal labels supply none of them.

S12-scoped checks, only when UTS.ViewpointMap is current.

1. ViewpointRef resolves exact P under the stated effective scheme. The row never calls the reference a relation or P a position.
2. Every PrimaryE18ConstructRef, crossing, and gate resolves the exact E.18 value or occurrence consumed by the mapping; the row creates none of them.
3. Candidate-view, whole-family, publication, representation, cross-context, retargeting, and Work branches appear only when that separate claim is current and cite its defining pattern's result.
4. One-viewpoint use needs one row. Familiar labels or four unbound template names establish no whole-family coverage.

Purpose. Provide a neutral E.18 mapping from one resolved project-local engineering viewpoint reference to exact E.18 constructs without turning the reference into a relation, P into a template position, or a familiar label into viewpoint, view, family, publication, or conformance evidence.

#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 identified positions. E.18.1 separately carries the accepted problem-side claim through whichever of those relations becomes current.

Show-A (Supply chain). The loci run from procurement through inbound quality control and normalization to supplier selection; selection and planning inform each other; planning leads to execution and then refresh. Execution includes receipt Work admitted under U.Work and keeps its receipt records separate; refresh uses quality telemetry and re-emits the affected faces. When an incoming lot moves from the supplier-receipt position to the internal-QC position and its locality binding changes, record the crossing with CrossingRef, the A.2.6 locality fact, the rule that permits the change, and the A.21 gate. If the two labels also use different local senses, identify their F.17 cells and test the F.9 Bridge, the C.2.1 bounded-use claim, and current reliance separately. A penalty appears only when a current policy is cited through PolicyIdRef, the policy applies, its rule supports the penalty, and any separately needed authority relation and participants are established. Comparators remain pinned to the named CG-Spec value and edition.

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 identified 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 with its defining predicate and occurrence rule. Do not join them with U.Transfer; if a required relation has no predicate or occurrence rule, 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 identified 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, together with the pattern or declaration that defines its predicate and occurrence identity; if no such rule is available, return missing-governor. E.18 defines each member's internal structure and smallest reopened PathSlice. A reader-facing role label remains ordinary wording until E.10.ROLE recovers its meaning; neither that label nor a feedback arrow makes the members one TFS or supplies the cross-member relation.

Cross-pattern boundary slice (QD archive). A QD selector returns an archive. Under E.18, the selector occurrence and returned archive may occupy positions on one PathSlice; the archive is returned by the exact selector relation, not by the slice, and remains a set or archive rather than a hidden scalar. Under A.20, an archive insertion or update step may have exact constraint-validity results and a complete required-set summary; no acceptance is inferred. Under A.21, a comparability gate or LaunchGate publishes a decision only when its gate relation consumes the declared independent check results. Under E.20, a newly introduced selector-mechanism definition remains the meaning locus. These are four identified 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 the applicable semantic definitions and tests explicit at the loci and gates.
• Over-formalization risk. Category-theoretic formalisms can obscure operational guard-rails; ordinary E.18 states each crossing in readable prose, while replay-facing use keeps exact positions, per-binding accounts, one separate A.21 gate decision, and 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. Select checks from the current use before applying a profile. Require edition pins when a current comparison or publication depends on them, inspect the GateDecisionResult for a current decision and an optional DecisionLog only when audit, history, replay, or reuse depends on it, and keep refresh tests within the affected PathSlice.

#Conformance Checklist — Unified checklist (normative)

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

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

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

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

Glossary (additions)

• Open-world species - non-exhaustive domain-scoped locus specializations that map to the minimal locus baseline and name the pattern content that defines or constrains them.

• Signature locus - structure-positioned use of A.6.0 U.Signature (universal block). It is an independently defined value bound into the selected structure, not a local kind and not a C.3.2 KindSignature.

• KindSignature (C.3.2) - definition of a U.Kind by intent, extent, and formality; unrelated to E.18 locus kinds; never a genus.

• Species (domain-scoped) — typed specialisations speciesOf(kind=...) that declare KindDefinition=<pattern id for the current definition> (e.g., kind=Mechanism; KindDefinition=A.6.1).

• Semantic Bridge boundary — F.9 defines and tests an obtaining semantic relation between two exact F.17 cells. A structural crossing or A.6.4 retargeting does not imply that relation; a Bridge Card and CL are optional episteme/evidence apparatus.

• Eulerian interpretation - operational stance where a flow is treated as a valuation over U.Transfer and transfer relations perform assurance-only operations (no token-passing semantics).

• GateCheckKind boundary. GateCheckKind is a recognition label within one identified A.21 check application, not a structure locus kind and not enough to identify or merge results. No such label becomes an E.18 Check locus unless an OperationalGate(profile) locus is actually present.

• GateCheckRef boundary. Where a publication face over a selected structure carries a GateCheckRef, that value refers to one exact A.21 GateCheckApplicationResult. It must resolve the checked subject, criterion and edition, applicable rule application, case, scope, and window; the old {aspect, kind, edition, scope} projection is insufficient.

• GateDecision, GateDecisionRationale, and GateDecisionExplanation (terminology).

  • GateDecision - the lattice value inside one A.21 GateDecisionResult, derived from one exact profile application and its complete required set of identified check-application results.
  • GateDecisionRationale - the structured rationale inside that result: retained source outcomes, explicit mappings, aggregate, and action consequence. A current publication or optional DecisionLog may cite it; neither supplies the rationale or decision.
  • GateDecisionExplanation — an optional human-readable narrative derived from the rationale; it carries no decision value. It may explain any retained result and mapping, including why an A.20 input prevented passage; absence of a narrative does not make a check inapplicable.

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

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

  This shape is publication-only; it introduces no new execution steps and no arithmetic on faces. (Couples to A.20 or A.21 without duplicating their check catalogs.)

• VALATA (VA, LA, and TA) — value-annotation scheme used on AssuranceLane; carriers are referenced via SCR and RSCR; detailed evidence obligations use the definitions and tests in A.10 and the named evidence, publication, or crossing pattern for the current case. Included here so evidence pins are self-describing in Part E texts.

• Transfer vs Transport - Transfer = the sole relation kind U.Transfer in the selected structure. Transport = conversions defined by Phi policies and registries (TransportRegistry^Phi) referenced by UNM; "reuse via Transport" refers to the latter.

• GateCrossing - an E.18 structure-local transition between exact source and receiving position/state bindings at one exact gate whose profile and decision test come from A.21; it is not a semantic Bridge or gate decision.

• Admissible path - a typed path obeying the GateCrossing discipline: no hidden crossings, every witness required by an exact current crossing rule is present, compare and launch publication faces are Gamma-pinned when present, and T^D<->T^R occurs only at LaunchGate; see S2.

#Common Anti-Patterns and How to Avoid Them

#Gating Profiles (applied to E.18)

Profiles set strictness only through an exact current application to one gate, subject, action, scope, and window. A profile description or name does not by itself introduce a crossing, LaunchGate, publication face, comparator, selector, cycle, refresh, audit record, evidence lane, or Work occurrence. A.21 defines the profile-application, check-application, decision-result, and optional reuse-record boundaries.

Profile selection and change. Cite the exact current policy-application fact, including its rule and edition, applicability, gate and subject, scope, window, required set, mappings, and any separately required authority. A PathSlice only bounds changed data or currentness and may trigger reevaluation; it neither selects, inherits, overrides, nor weakens a profile. G.11 supplies refresh wiring only when refresh itself 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 work-entry boundary: When an exact design-run-tag claim and applicable profile rule are current, a LaunchGate may consume the corresponding identified check result. The gate never establishes actual launch values. Those values obtain only through exact direct relations or A.6.1 application bindings involving one later Work occurrence; acceptance claims and telemetry records remain separate epistemes or relations that may designate that occurrence.
5. Assurance visibility: When publication or reuse is current, MVPK can make the exact profile application, gate-decision result, optional audit record, and any sufficient reuse witness locally checkable without making them mandatory for an ordinary local structure use.

Trade‑offs. a) Higher upfront modeling cost: exact crossing positions, per-binding replay accounts, gate refs, and optional durable crossing bundles demand care; mitigated by keeping ordinary local crossings in readable prose and unbundled when no downstream reliance needs replay. b) Longer transfer face sets: Required path and publication refs can lengthen faces; 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); the patterns named below supply the definitions and tests 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, a per-binding account for each change, and CrossingRef. GateDecision and any permission claim remain separate; 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 declaration 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. When the selected structure contains an exact current LaunchGate relation for one prospective workEntryClaimRef, that gate is the pre-run decision locus for that claim. Actual launch values are established only through independently obtaining direct relations or A.6.1 bindings involving a later Work occurrence and may be cited by a separate finalization witness.

This arrangement gives checkable conditions for functorial publication on crossings and keeps inner constraint validity distinct from profile fit. A.21 can therefore aggregate mapped check results without evaluation order changing which independently established facts remain available.

#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 in relation to A.15.5. E.18 supplies the current path, slice, and any actually present crossing, LaunchGate position, or structure-local pins; A.15.5 defines and tests 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 receiving entity or relation occurrence independently, including its participants, obtaining condition, and the pattern content that defines or tests it; those labels supply none of them. E.18 still defines 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 identified 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 relation occurrence, that returns it; name that relation's predicate, participants, obtaining condition, occurrence identity, and the content that defines or tests it. Also cite the exact source-to-use relation and the pattern that defines or constrains the receiving architecture claim. C.33, C.34, and C.35 supply definitions or tests; they are 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 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. A.20 reports exact internal-constraint results for transformations, operation applications, or A.6.4 retargeting uses when those constraints are current. E.18 supplies no constraint truth, plane or unit declaration, gate consequence, or acceptance. Terminology discipline (A.20 boundary). Preserve A.20 applicability, evaluation state, outcome, summary, and witness or reason. GateDecisionRationale and GateDecisionExplanation remain A.21 terms.
• E.18 -> coordinates -> A.21 Gate decisions. When an OperationalGate(profile) decision is current, it consumes independently identified check-application results under one exact profile application. An unsatisfied or incomplete A.20 input affects the aggregate under that current rule without making another applicable check inapplicable; each deferred required check remains notRun. A.21 defines check-application identity, mappings, aggregation, result and rationale, and optional publication or reuse records.
• 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. Use E.18 for 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 policy-based penalty remain separately identified.
• 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. Declare CG-Spec, ComparatorSet, and UNM.TransportRegistryPhi only at the UNM declaration locus; 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 identified U.WorkPlan with any declaration-local A.15.3 planned-filling rows, or in a separately identified configuration or policy that passes its own applicable rule, 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. When an exact current LaunchGate relation consumes one prospective workEntryClaimRef, its current profile application selects any required freshness, tag, ingress, or other checks and maps their results to the attempted-entry consequence. If Work occurs, A.15.1 defines and tests 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 uses A.6.RCD disposition 1 when its exact predicate and case facts are current; disposition 2 supplies only one local C.2.1 compound claim when no direct predicate expresses it and admitted base-predicate semantics support this receiving use. Work, Transformation, and that claim remain separate. 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. A.3.4 defines and tests each independently identified actual bounded U.Transformation; E.18 defines the selected compound structure over transformations and adjacent identified loci without asserting transformation composition; and the named neighboring patterns define or test 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. Use E.18 for 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

Choose tests from the current use, then apply the selected profile to those tests. The full CC-E18 table is available for combined or high-assurance uses; it is not an instruction to run every row for every selected structure.

1. Ordinary selected-structure check: verify the selected structure, independently grounded locus values, one internal U.Transfer relation kind, and only the current position, path, path slice, or valuation. The cooling-loop first-use slice can close here when it asserts no crossing, launch, publication, comparison or selection, cycle or refresh, or assurance branch; missing faces, LaunchGate, selector, DecisionLog, and SquareLaw are then not defects.
2. Crossing or launch check, when current: for a GateCrossing, apply its crossing and gate rows, including the exact positions and changed-binding account; add launch rows only for a current LaunchGate or work-entry claim. Do not infer a Work occurrence from either gate.
3. Publication or assurance check, when current: for a published face, apply the MVPK, pin, and no-new-claim rows. Inspect DecisionLog, evidence-lane, replay, or SquareLaw material only when the current decision, crossing, publication, or named downstream reliance needs it.
4. Comparison, selection, cycle, or refresh check, when current: apply comparator and set-return tests to a current comparison or selection; apply budget, sentinel, edition, and slice-local replay tests to a current cycle or refresh. Hold editions fixed only for a replay claim, and test an edition bump only for a current refresh use.
5. Structural reinterpretation check, when current: confirm one exact A.6.4 arrow r, an affirmative q, a separate current-case judgement of satisfies, unchanged CtxState, and PathSliceId locality. Apply A.20 only when q also raises a current internal constraint. Test an independent F.9 Bridge and its bounded-use claim only when cross-semantic correspondence is also claimed; keep optional CL, evidence, reliance, any application, and Work separate.

Relation boundary: E.18 defines selected transformation-flow structures whose loci may bind independently identified actual U.Transformation values and structure-positioned adjacent values whose definitions or constraints are identified independently. 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, apply the pattern whose Solution answers that exact claim 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, apply A.3.4 to the U.Transformation claim and E.18 to the selected structure, containing locus, pins, locus kind, crossing, publication, comparability, and refresh discipline. Cite the exact predicate and case facts 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. For a claim about the independently identified value bound at a locus, apply A.3.4 to the bounded-transformation claim, A.6.0 to the signature declaration, A.6.1 and E.20 to the mechanism claim, the applicable A.15 pattern to planning or dated Work, and A.20 or A.21 to the current internal-step-validity or gate claim.

#E.18.1 P2W Child-Pattern Relation

E.18.1 is a child pattern for problem-to-work carry-through. It describes the practitioner carry-through practice and, when durable replay is needed, defines 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 keeps its independent identity and uses the pattern that defines or constrains the current claim about it. 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 positions for the patterns that define or test their claims must be recoverable, E.18.3 defines 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 defines 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 it remains a transformation-flow structure, work-control cue, gate relation, or refresh relation; apply the pattern whose Solution answers that exact claim.

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, use the E.23 object-version improvement definition and test; if the harness only runs work, use the A.15 family to identify and test 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-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)