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

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.

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

#Recommendation

PatternUseRecommendationSupportProfileValue = ordinaryCompact | relianceBearing

PatternUseRecommendation@Context <: U.Episteme:
  boundedContextRef: U.BoundedContextRef
  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 one U.MethodDescription
  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. A recommendation does not authorize work, establish a gate, prove evidence sufficiency, or create the expected result.

When a stronger neighboring pattern better addresses the current question, name it and use the recommendation boundary to return. 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:
  boundedContextRef: U.BoundedContextRef
  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
  precedenceConditionRef: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context
  orderingRationaleRef: U.EpistemeRef, referencing one PatternUseCoordinationRationale@Context
  RelationRefKind: U.EntityRef
  Direction: prerequisiteCandidatePatternUseRef -> dependentCandidatePatternUseRef
  Dependence: bounded-context local 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, precedenceBasisResultExpectationRef is present and equals the prerequisite candidate's exact result expectation. The ordering relation never copies result kind or relation-signature slots. For methodPrecondition and sharedConstraintResolution, the result-expectation position is 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 result and receiving use answer the current concern better than the live alternatives.
6. Coordinate several candidates as unordered, partially ordered, or totally ordered. Add a pairwise relation only when one declared precedence basis is current.
7. Stop at the recommendation or coordination result. 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, and stop boundary.

Recheck the smallest affected finding or relation when a candidate Solution, result expectation, fit basis, live alternative, receiving use, coordination member, precedence basis, or boundary changes. A changed candidate fit reopens its applicability and any recommendation that relied on it. A changed prerequisite expectation 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.

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 and point to the ECS candidate's existing expectation. Do not copy EvaluationCharacteristicSpaceSpec and its signature into new ordering fields. After the result is grounded, the dependent use can begin under its own Solution.

#Method precondition is not a result dependency

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

If coordination is still useful, use methodPrecondition and leave the result-expectation position 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. The dependent use returns until that expected result is grounded. 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 bias. Prerequisite result kind is duplicated in ordering fields. Reuse the prerequisite candidate's exact expectation.

#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 the candidate expectation.

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, and only a prerequisite result justifies a result-expectation reference. This preserves graph structure without turning every explanation into a chain.

#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, A.19 and A.19.ECS for subject comparison, E.18.1 for P2W, G.11 for currentness orchestration, and the direct pattern governing any plan, work, gate, evidence, decision, or authorization claim.
• 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-07-12 — this section last modified in upstream FPF commit 4a55618e (github.com/ailev/FPF)