E.18:2 - 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 qualified holder-ability claim under A.2.2 or a 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.