E.11.PUA:5.1b - A selection result can support later planning

E.11.PUR governs the identity and content of one PatternUseRecommendation@Context; A.15.2 separately governs one U.WorkPlan. patternSelectionFlowResult and selectedPatternApplicationFlowResult are descriptive positions that keep these two entities apart. If either episteme is claimed to have been first constituted by dated Work, cite its own local A.15.PROD inception claim rather than saying that selection or application generically produced it.

If the recommendation participates in later planning, name its exact source and receiving positions and either the direct relation occurrence with its applicable predicate or the applicable A.6.1 binding. If that basis cannot be established, keep the recommendation and plan separate and state the exact missing-governor, unresolved-grounding, false-predicate, or missing-endpoint-binding boundary. Neither the recommendation nor the plan becomes the machined component expected from downstream subject work.

Build-the-builder recognition case. An executable compiler edition occupies one exact result-bearing position (FlowPositionRef) in a compiler-build TFS and participates at one exact compiler-use position (FlowPositionRef) in a separately identified program-compilation TFS through a direct compiler-use relation occurrence. Its applicable predicate identifies that occurrence; the compiler edition keeps its kind. Use E.18 when either TFS-local position is unresolved; use E.18.NET when the question is how the separately identified build and compilation TFS values form a network, including a recursive one. With no compiler-use kind or predicate, return missing-governor; with undecided case facts, keep the relation open; with a false predicate, assert no compiler-use occurrence; with an obtaining occurrence but a missing endpoint binding, return missing-endpoint-binding and name that binding. None of these branches permits calling the compiler edition the second flow’s input by label alone.