#Pattern-Use Applicability, Recommendation, and Coordination

E.11.PUR · Stable · Pattern-language use pattern (E) · Normative for reliance-bearing applicability findings, pattern-use recommendations, and coordination among candidate FPF pattern uses. · 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.

Type: Pattern-language use pattern (E) Status: Stable Normativity: Normative for reliance-bearing applicability findings, pattern-use recommendations, and coordination among candidate FPF pattern uses.

#Relations

#Content

#Problem frame

#Use this when

Use E.11.PUR after one or more CandidatePatternUse@Context values are available and a person or assisting agent needs to decide whether each use fits, which use to recommend, or how several uses should be coordinated for the current concern.

Primary EntityOfConcern. One current PUR-governed value over already inspected candidate pattern uses: a PatternUseApplicabilityFinding@Context, a PatternUseRecommendation@Context, or a PatternUseCoordination@Context. A PatternUseOrderingRelation@Context is current only inside the coordination it qualifies.

The @Context suffix on these compatibility support names is retrieval wording only. It names no bounded-context entity, generic situation, project container, relation participant, or identity field; every episteme follows C.2.1 identity, and the ordering relation follows its direct participant, condition, obtaining, and occurrence rules below.

What this buys. Applicability no longer silently becomes recommendation, and presentation order no longer silently becomes workflow order. A project can preserve exact reasons for a consequential recommendation without burdening ordinary bounded use with five separate forms.

Not this pattern when. Use E.11 while public cards are still being compared. Use E.11.PUA to apply one selected pattern and obtain its first result. Use A.15 for work planning or performed work, A.21 for a gate decision, and the direct decision or authorization pattern when those claims are current.

In this pattern, next move is Plain shorthand for the currently recommended pattern use or conditional continuation. It is not a shared Move identity, U.Method, U.WorkPlan, performed U.Work, or actual U.Transformation; selection or imperative wording performs nothing.

#Problem

Several different claims are often compressed into "use this pattern next." A pattern can fit the problem frame but fail its Solution conditions. It can be applicable yet not be the recommended use because another pattern produces a more useful first result. Several candidate uses can belong together without forming a sequence, and a sequence can be shown without creating a WorkPlan.

When these distinctions are missing, familiar PatternIDs become proxies for value. Teams recommend the pattern they know, copy one result description into several order relations, and treat a diagram or teaching order as execution order.

#Forces

#Solution

Evaluate candidate uses against five distinct fit aspects. Keep those aspects in one compact rationale for ordinary bounded use. Materialize separate findings only when a named receiving reliance needs them. Aggregate applicability before issuing a recommendation. Coordinate several candidates with an explicit local ordering mode and pairwise precedence relations only where a real basis exists.

#Fit and applicability

PatternUseFitCriterionValue =
  problemFrame | forces | solutionConditions | ordinaryBoundary | resultAndReceivingUse

PatternUseFitResultValue = fit | misfit | insufficientBasis
PatternUseApplicabilityResultValue = applicable | inapplicable | insufficientBasis

PatternUseFitFinding@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing one CandidatePatternUse@Context
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  editionId
  fitCriterion: PatternUseFitCriterionValue
  fitResult: PatternUseFitResultValue
  fitRationaleRef: U.EpistemeRef, referencing one CandidatePatternUseRationale@Context

PatternUseApplicabilityFinding@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing one CandidatePatternUse@Context
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  editionId
  fitFindingRefs[5]: U.EpistemeRef, each referencing one PatternUseFitFinding@Context
  applicabilityResult: PatternUseApplicabilityResultValue
  missingBasisBoundaryRef?: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context

The five criteria refer to one candidate. In ordinary conversation, inspect all five and state the aggregate result in the recommendation without materializing five findings. PatternUseApplicabilityFinding@Context is the reliance-bearing support episteme: when it exists, its five findings cover each criterion exactly once. applicable follows only when all five are fit; any misfit yields inapplicable; one or more insufficientBasis values yield insufficientBasis and a missing-basis boundary.

problemFrame compares the candidate pattern's Problem frame with the current concern; it does not assert that an actual Problem obtains. When an actual Problem is relied on, cite one current C.22.PFR ProblematicForRelation occurrence with its exact actual-condition and criterion-applicability participants and adverse-episode identity. A ProblemCard, fit finding, assessment, or recommendation may support a claim about that occurrence but neither creates nor splits it.

#Recommendation

PatternUseRecommendationSupportProfileValue = ordinaryCompact | relianceBearing

PatternUseRecommendation@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the selected CandidatePatternUse@Context
  entityOfConcernKindRef: U.KindRef
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  editionId
  recommendationSupportProfile: PatternUseRecommendationSupportProfileValue
  applicabilityResult: PatternUseApplicabilityResultValue
  compactApplicabilityAndSelectionRationaleRef: U.EpistemeRef, referencing one CandidatePatternUseRationale@Context
  applicabilityFindingRef?: U.EpistemeRef, referencing one PatternUseApplicabilityFinding@Context
  expectedResultExpectationRef: U.EpistemeRef, referencing one PatternUseResultExpectation@Context
  strongerNeighborPatternRef?: U.EntityRef, referencing the exact neighboring FPF pattern identity supplied by its pattern/framework owner
  recommendationBoundaryRef: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context

Recommendation selects one applicable candidate for the current concern because its expected result and receiving use are preferable under the stated rationale. In ordinaryCompact, the applicability result and compact rationale are carried directly and applicabilityFindingRef is absent. In relianceBearing, the same recommendation also cites one current applicability finding whose five fit findings can be replayed independently. The profile changes support cardinality, not the recommendation kind or authority.

expectedResultExpectationRef points to the exact E.11.PUA expectation. It identifies the expected result kind and direct owner, the kind of governed object relative to which the result phrase would be true, and the category-correct direct-basis branch; it asserts neither that the result exists nor that a relation, A.6.1 binding, or local claim is current. A recommendation does not authorize work, establish a gate, prove evidence sufficiency, create the expected result, or supply its later closure.

When a stronger neighboring pattern better addresses the current question, strongerNeighborPatternRef identifies that exact FPF pattern identity and recommendationBoundaryRef carries the return. The pattern reference does not establish U.MethodDescription membership; any such claim requires an independent A.3.2 membership result for an already identified episteme. Familiarity with the current candidate is not a recommendation basis.

#Coordination without forced order

PatternUseOrderingModeValue = unordered | partialOrder | totalOrder

PatternUseCoordinationRationale@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the coordination-question episteme
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  editionId
  subjectCandidatePatternUseRefs[2..*]: U.EpistemeRef, each referencing one CandidatePatternUse@Context
  coordinationRationaleDescriptionRef: U.EpistemeRef
  rationaleBasisEpistemeRefs[]: U.EpistemeRef
  coordinationBoundaryRef: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context

PatternUseCoordination@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the coordination-question episteme
  entityOfConcernKindRef: U.KindRef
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  editionId
  memberCandidatePatternUseRefs[2..*]: U.EpistemeRef, each referencing one CandidatePatternUse@Context
  orderingMode: PatternUseOrderingModeValue
  orderingRelationRefs[]?: U.EntityRef, each referencing one PatternUseOrderingRelation@Context
  coordinationRationaleRef: U.EpistemeRef, referencing one PatternUseCoordinationRationale@Context
  stopBoundaryRef: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context

unordered has no ordering relations. partialOrder and totalOrder use explicit pairwise relations. A total order is the bounded PatternUseSequence@Context specialization under its named receiving use; it is not a universal route or project WorkPlan.

#Pairwise precedence

PatternUsePrecedenceBasisValue =
  prerequisiteResult | methodPrecondition | sharedConstraintResolution

PatternUseOrderingRelation@Context <: U.Relation:
  coordinationRef: U.EpistemeRef, referencing one PatternUseCoordination@Context
  prerequisiteCandidatePatternUseRef: U.EpistemeRef, referencing one CandidatePatternUse@Context
  dependentCandidatePatternUseRef: U.EpistemeRef, referencing one CandidatePatternUse@Context
  precedenceBasis: PatternUsePrecedenceBasisValue
  precedenceBasisResultExpectationRef?: U.EpistemeRef, referencing one PatternUseResultExpectation@Context
  precedenceBasisResultClosureFindingRef?: U.EpistemeRef, referencing one current PatternUseResultClosureFinding@Context
  precedenceConditionRef: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context
  orderingRationaleRef: U.EpistemeRef, referencing one PatternUseCoordinationRationale@Context
  RelationRefKind: U.EntityRef
  Direction: prerequisiteCandidatePatternUseRef -> dependentCandidatePatternUseRef
  Dependence: local to coordinationRef, both candidate editions, the precedence basis and condition, and any current result-closure support to coordinationRef and both candidate editions
  Identity: <coordinationRef, prerequisiteCandidatePatternUseRef, dependentCandidatePatternUseRef, precedenceBasis, precedenceConditionRef>

The prerequisite and dependent candidates are different members of the same coordination relation. When precedenceBasis=prerequisiteResult, both result references are present. precedenceBasisResultExpectationRef equals the prerequisite candidate's exact expectation. precedenceBasisResultClosureFindingRef resolves to that same candidate and expectation and reports the exact independently governed result entity or obtaining relation, its direct owner, the exact method, plan, dated Work, transformation, evaluation, decision, or receiving-use object relative to which the result phrase is true, and one category-correct direct relation occurrence, A.6.1 operation-application binding, or A.6.RCD local-claim basis with its governor or governors. The ordering relation copies none of those result-kind, participant, or signature fields.

The closure finding is a C.2.1 episteme and creates neither the result nor the ordering relation. The ordering relation obtains only while its precedenceConditionRef is satisfied by the directly governed result and basis reported there. A missing governor, missing information, false predicate, or absent operation binding leaves the precedence relation non-obtaining and the dependent use at its exact return boundary. For methodPrecondition and sharedConstraintResolution, both result-reference positions are absent. The dependent candidate use is admitted under a precedence relation only after its precedence basis is established. Page order, seminar order, identifier order, or visual adjacency does not create that relation.

#Practical procedure

1. Recover each candidate's current concern, direct pattern, Solution, expectation, and ordinary boundary.
2. Choose ordinaryCompact unless a named receiving use needs the fit aspects to remain independently addressable; use relianceBearing only for that reliance.
3. Inspect all five fit aspects. In ordinary use, keep them in one compact rationale. Under named reliance, materialize five separate findings and one applicability finding.
4. State the aggregate applicability result directly in the recommendation; when a reliance-bearing applicability finding exists, the two result values agree.
5. Recommend an applicable candidate only when its expected result and receiving use answer the current concern better than the live alternatives; the expectation is not an achieved result.
6. Coordinate several candidates as unordered, partially ordered, or totally ordered. Add a pairwise relation only when one declared precedence basis is current. For prerequisiteResult, require the prerequisite candidate's exact expectation and one current E.11.PUA result-closure finding with the complete direct basis.
7. Stop at the recommendation or coordination result. A Plain next move names only the recommended pattern use or conditional continuation. Continue to PUA, P2W, planning, gate, decision, or work only when that next claim becomes current.

#Replay and currentness

Replay an ordinary compact recommendation from its candidate, applicability result, compact rationale over all five aspects, current live alternatives, expected result and receiving use, and recommendation boundary. Replay a reliance-bearing recommendation from those same positions plus the current applicability finding and its five fit findings. Replay coordination from its members, question, ordering mode, pairwise relations, precedence bases, stop boundary, and, for each prerequisiteResult relation, the exact expectation and current E.11.PUA closure finding.

Recheck the smallest affected finding or relation when a candidate Solution, result expectation, result entity, governed relative object, direct basis or governor, fit basis, live alternative, receiving use, coordination member, precedence basis, condition, or boundary changes. A changed candidate fit reopens its applicability and any recommendation that relied on it. A changed prerequisite expectation or closure reopens only the affected ordering relations and their dependent uses unless the coordination question or membership also changed. G.11 governs edition, telemetry, currentness-window, and decay orchestration; PUR supplies the judgement-specific values and change conditions.

#Archetypal Grounding

#Applicable but not recommended

A team considering a high-cost pump test has candidate uses of C.28 causal triage and A.21 gate discipline. Both may be applicable. The immediate uncertainty is whether a causal model output may support intervention, so C.28 offers the more useful first result. That uncertainty and the recommendation are epistemic; neither asserts an actual C.22.PFR Problem.

Recommend C.28 without claiming that the test is authorized. The later gate use remains a separate candidate whose applicability can be reconsidered after the causal-use result exists.

Because this local recommendation is reversible and no later use relies on five separate findings, the team records recommendationSupportProfile=ordinaryCompact, the applicability result, and one compact rationale over all five aspects. If a later gate review needs to replay each aspect independently, that review may create current fit findings and a current applicability finding from the then-current basis. It does not claim that those addressable findings existed when the earlier compact recommendation was made; the original compact rationale remains its historical basis.

#Unordered complementary uses

A clinical team needs both a terminology repair and an evidence-basis review before revising a protocol. Neither result is a prerequisite for the other in the current context.

Use one coordination relation with orderingMode=unordered. The team may perform the uses in either order or in parallel. Their coexistence does not create a lifecycle or WorkPlan.

#Result-based precedence

A design team's architecture-candidate comparison begins only after its evaluation coordinates are defined. One candidate use of A.19.ECS expects an EvaluationCharacteristicSpaceSpec; the dependent comparison use consumes that exact result.

Use precedenceBasis=prerequisiteResult, point to the ECS candidate's existing expectation, and cite its current E.11.PUA result-closure finding. The closure must identify the exact EvaluationCharacteristicSpaceSpec, its direct owner, the governed evaluation or application relative to which it is this result, and the direct relation, A.6.1 binding, or local-claim basis and governor. Do not copy the spec or its signature into ordering fields. Until that basis is current, no precedence occurrence is established and the dependent use stays at its return boundary.

#Method precondition is not a result dependency

A machining pattern assumes an admitted material-kind classification. The classification is a method precondition already current for that exact machining use, not the result of another candidate pattern use.

If coordination is still useful, use methodPrecondition and leave both result-reference positions absent. Do not invent a prerequisite result merely to make the relation look uniform.

#Repair a stale copied prerequisite locally

An older architecture coordination copied EvaluationCharacteristicSpaceSpec and its signature into an ordering record. The ECS candidate's current expectation later changed, leaving the copy stale while both candidates, their applicability findings, the coordination question, and partialOrder mode remained sound.

Repair only the ordering relation: remove the copied result description, set precedenceBasis=prerequisiteResult, and reference the ECS candidate's current expectation and current E.11.PUA result-closure finding. If the exact result, governed relative object, direct basis, or governor cannot be recovered, keep the precedence relation non-obtaining and the dependent use at its return boundary. Candidate inspection, applicability, coordination membership, and direct Solutions do not restart.

#A higher recommendation score can reduce useful fit

An assistant ranks candidate pattern uses by historical recommendation acceptance. The familiar A.21 gate candidate receives a higher score and is recommended first more often for causal-use uncertainty. Recommendation acceptance rises, but wrong-turn returns also rise because the needed C.28 causal-use result is still absent.

The score improved while first-result fit and receiving-use value worsened. Keep the historical score as telemetry, apply E.13 to the substitution, and base recommendation on current applicability, expected result, receiving use, and live alternatives. A higher score is not another fit finding.

#Bias-Annotation

• Applicability-as-recommendation bias. A fitting pattern is automatically selected. Compare the expected practical result and live alternatives before recommending it.
• Favorite-pattern proxy bias. Familiar PatternID substitutes for current value. State the concern, expected result, and receiving use in the rationale.
• Five-form bias. Every ordinary use creates five findings. Keep them in one compact rationale unless their separate identity is relied on.
• Sequence bias. Presentation order becomes precedence. Repair by naming the pairwise basis.
• Result-copy or expectation-as-result bias. A prerequisite result kind is duplicated in ordering fields, or its expectation is treated as achieved. Reuse the prerequisite candidate's exact expectation and current E.11.PUA closure finding; the closure reports but does not create the exact result and direct basis.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits. A team can explain why a pattern fits, why it is recommended, and how several uses relate without creating a false workflow. Reliance-bearing decisions remain replayable. Result-based precedence stays synchronized with both the candidate expectation and the exact directly grounded result closure.

Costs. Consequential recommendations need explicit rationales and sometimes five addressable findings. Partial orders need pairwise relations. Ranking candidates that solve different questions produces an inadmissible comparison rather than a useful shortcut.

#Rationale

Applicability, recommendation, and coordination answer different questions. Applicability asks whether a candidate's conditions hold. Recommendation asks which applicable use best serves the current concern. Coordination asks how several candidate uses belong together. Keeping the questions separate prevents a familiar label or score from becoming an unexamined decision.

Pairwise precedence is intentionally narrow. A graph of pattern uses can be unordered, partially ordered, or totally ordered. Only a current dependency justifies an edge. A prerequisite-result edge needs both the exact expectation and an E.11.PUA closure whose directly governed result and category-correct basis satisfy the stated condition; neither a result label nor an expectation can do so. This preserves graph structure without turning every explanation into a chain or minting a generic result relation.

#SoTA-Echoing

The practical implication is to recommend a use for its expected result, not for its familiarity or score, and to add order only where a real dependency exists.

Que et al. is the current decision-bearing recommender source in this narrow use; Nunes and Jannach supplies lineage. The 2026 navigation preprint supplies bounded reconsideration, while current FPF NQD, OEE, and A.19 supply the transdisciplinary candidate and comparison basis. These sources change 4.1-4.5 and 5.6; none decides FPF kinds or recommendation authority.

Reopen the score-proxy adaptation when stronger evaluation evidence shows that the relied-on score tracks current expected-result and receiving-use fit without the identified exposure or rationale loss. Reopen the wrong-turn adaptation when peer review, replication, or use evidence changes the value of reconsideration. G.11 orchestrates source and telemetry currentness; PUR changes the affected fit, rationale, recommendation, or return relation.

#Relations

• Builds on: E.11.PUA for candidate uses, expectations, rationales, and boundaries; A.6.5 for slot discipline; and E.18 for coupled-flow relations when results cross flows.
• Coordinates with: E.11 for public discovery; C.22.PFR when an actual Problem is relied on; A.19 and A.19.ECS for characteristic-space construction and A.19.CPM for an actual comparison application; E.18.1 for P2W; G.11 for currentness orchestration; and the direct pattern governing any plan, work, transformation, gate, evidence, decision, authorization, result entity, or category-correct result basis.
• Leads to: E.11.PUA for applying the recommended pattern, or to the exact neighboring pattern when the recommendation makes a stronger subject claim current.

#E.11.PUR:End

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