E.11.PUR - Pattern-Use Applicability, Recommendation, and Coordination

Type: Pattern-language use pattern (E) Status: Stable Normativity: Normative for deciding applicability, recommendation, and coordination among candidate FPF pattern uses, with addressable support only when a later use relies on it.

E.11.PUR:1 - Problem frame

E.11.PUR:1.1 - Use this when

Use E.11.PUR after one or more candidate pattern uses have been inspected and a person or assisting agent needs to decide whether each use fits, which use to recommend, how several uses should be coordinated, or whether an earlier result already answers the current concern. The candidates may remain conversational in ordinary bounded use; addressable CandidatePatternUse@Context values are required only when a named later reliance needs them.

Primary EntityOfConcern. One current applicability, recommendation, or coordination judgement over already inspected candidate pattern uses. When that judgement must remain addressable, it may be represented by PatternUseApplicabilityFinding@Context, PatternUseRecommendation@Context, or PatternUseCoordination@Context; a PatternUseOrderingRelation@Context exists 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 an ordering relation follows its own participant, condition, obtaining, and occurrence rules.

What this buys. Applicability no longer silently becomes recommendation, presentation order no longer silently becomes workflow order, and a result that still answers the concern can end a repeated pattern use. A project can preserve exact reasons for a consequential recommendation without burdening ordinary bounded use with five separate forms or copying one result under another stage name.

Not this pattern when. Use E.11 while public entries are still being compared. Use E.11.PUA to use 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.

E.11.PUR:2 - 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 worth recommending: another use may offer a more useful first result, or continuing the present work may serve the concern better once the full burden of a new use is counted. Several candidate uses can belong together without forming a sequence, and displaying a sequence creates no WorkPlan, performed work, Transformation, or transformation-flow structure.

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.

E.11.PUR:3 - Forces

E.11.PUR:4 - Solution

Evaluate candidate uses against five distinct fit aspects. An ordinary reversible judgement may remain conversational: keep the aspects in one compact rationale, state the aggregate applicability when the current question needs it, then compare the expected receiving value and full burden of the serious continuations, including continuing without a new pattern use. Before repeating a recommended use, apply the result-reuse branch in 4.2.1. Materialize separate findings or a recommendation episteme only when a named later use needs addressable support. Coordinate several candidates with an explicit local ordering mode and add pairwise precedence only where a real basis exists.

E.11.PUR:4.1 - 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. When its basis must be addressable, consume PUA §4.4’s ordinary C.2.1 claim about that candidate and its exact supporting claims, relations or evidence uses; no candidate-basis U.Relation is required. A contradicted product-law premise and missing dependence information remain distinct inputs to these fit tests. In ordinary conversation, inspect all five without materializing five findings. State the aggregate applicability when it answers the current question; if the later comparison supports a recommendation, carry that result into the recommendation. PatternUseApplicabilityFinding@Context is the reliance-bearing support episteme: when it exists, its five findings cover each criterion exactly once. Use mutually exclusive branches: any misfit yields inapplicable, including when another aspect has insufficientBasis; with no misfit, one or more insufficientBasis values yield insufficientBasis and a missing-basis boundary; otherwise all five are fit and the result is applicable.

A known misfit settles this candidate’s applicability under the inspected conditions. Do not obtain more information merely to fill the remaining aspects when it cannot change that answer. If changing the failed condition is a serious continuation, appraise that change separately and reconsider the affected fit under 4.6. A different candidate may still be applicable and worth recommending.

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.

E.11.PUR:4.2 - Recommendation

Before recommending a new pattern use, compare its full receiving value and burden with the other serious continuations, including continuing the present work without it. Use C.11.DUA when the worth of the advice, its presentation or its interaction with other proposed changes is unclear. Applicability can coexist with no worthwhile recommendation now. In that case, finish without selecting a pattern use or materializing a positive recommendation; give a short reason only when the current question or later reliance needs it. Continuing without optional advice does not remove an existing obligation.

When the comparison supports a recommendation, state which candidate is applicable, why its expected first result warrants its full burden for the current concern, and where to stop or return. If the judgement is local, reversible, and has no named later reliance, that readable statement is sufficient.

When the recommendation must remain addressable, use the schema below. ordinaryCompact keeps one compact rationale and no five-finding dossier; relianceBearing adds the current applicability finding only because a named later use needs independent replay.

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 episteme only when its identity changes the recommendation
  recommendationBoundaryRef: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context

Recommendation selects one applicable candidate because its expected receiving value warrants its full burden compared with the other serious continuations, including continuing without a new use, and, when a receiving use is current, supports that use under the stated rationale. A conversational judgement needs no record. In an addressable ordinaryCompact recommendation, 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.

When an addressable recommendation is materialized, expectedResultExpectationRef points to its exact E.11.PUA expectation. It identifies the expected result and only the pattern, relative-object, or category-correct basis distinctions that expectation actually uses; it does not assert that the result exists or that any 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, name it and state the return condition. Populate strongerNeighborPatternRef only when the exact pattern identity matters to an addressable recommendation. The reference does not establish formal U.MethodDescription membership; such membership requires its own A.3.2 basis. Familiarity with the current candidate is not a recommendation reason.

E.11.PUR:4.2.1 - Reuse an earlier result when it still answers the concern

After identifying an applicable candidate use, ask whether an earlier result episteme already answers the present concern. Use the pattern that defines or tests that result to compare:

• the result episteme’s EntityOfConcern and edition;
• the question answered and declared use;
• the source and dependency conditions on which the answer relies; and
• its qualification and currentness boundary.

When those values still match, cite and use the earlier result. Use A.10 when a named claim or bounded action relies on that result and the source-to-use account is still implicit. Add a dated U.Work occurrence only when that Work is itself a current claim. Use G.11 when currentness or refresh changes the use. Stop without repeating the same pattern use or copying the result under another stage name.

When one value changed, reopen the smallest affected result question under the pattern that defines or tests that result. Repeat the complete pattern use only when the unaffected reach cannot be established. If the applicable pattern supplies no basis for comparing the earlier result with the present concern, stop at insufficient result-comparison basis.

The candidate pattern use, the earlier result episteme, a later reliance relation, a currentness assertion, and later Work remain separate. This branch introduces no generic result-reuse relation.

E.11.PUR:4.3 - Coordination without forced order

For ordinary local coordination, state the candidates, whether they are unordered, partially ordered, or totally ordered, any real precedence basis, and the stop boundary in readable prose. Materialize the rationale, coordination episteme, and any pairwise ordering relations only when a named later use needs that coordination to remain addressable.

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. Treat the declared pairwise precedence as strict: its transitive closure must be irreflexive. A totalOrder additionally compares every pair of distinct members. A cycle or unresolved required pair blocks that ordering claim; preserve the known dependencies and state the unresolved coordination question.

E.11.PUR:4.4 - Pairwise precedence

A pairwise precedence relation is an applicable directed constraint between two exact candidate uses for the governed coordination question. It can obtain before either is performed. Establish its branch predicate:

• prerequisiteResult: the dependent use’s direct rule requires exact content, and the coordination has a stated basis for selecting this prerequisite use to supply it. Cite that rule, content and selection basis together with the prerequisite candidate’s exact expectation. Matching output kinds alone is insufficient. The result need not yet exist for the dependency to obtain.
• methodPrecondition: performing the dependent use first would invalidate a condition that the prerequisite use actually needs, and the proposed order preserves that condition. Name both uses and the condition; unary candidate fit alone supplies no pair.
• sharedConstraintResolution: an applicable schedule or priority rule selects this direction to resolve the actual shared constraint. Shared-resource exclusion alone establishes conflict, not A-before-B. A rule selecting B-before-A defeats the proposed A-before-B claim.

PatternUsePrecedenceBasisValue =
  prerequisiteResult | methodPrecondition | sharedConstraintResolution

PatternUseOrderingRelation@Context <: U.Relation:
  coordinationRef: U.EpistemeRef, describing the governed coordination question
  prerequisiteCandidatePatternUseRef: U.EpistemeRef
  dependentCandidatePatternUseRef: U.EpistemeRef
  precedenceBasis: PatternUsePrecedenceBasisValue
  precedenceBasisResultExpectationRef?: U.EpistemeRef  // prerequisiteResult only
  requiredContentAndSelectedSupplierBasis?:  // prerequisiteResult only
  precedenceConditionRef: U.EpistemeRef, describing the applicable semantic condition
  constitutiveOrderingRuleRef?: exact schedule or priority rule when it constitutes this order
  orderingRationaleRef: U.EpistemeRef
  Direction: prerequisiteCandidatePatternUseRef -> dependentCandidatePatternUseRef

The candidates are distinct members of the coordination. The relation obtains while the applicable branch predicate holds for those candidates, the governed question and semantic condition. A known false branch condition establishes non-obtaining; a missing rule or needed case fact leaves it unresolved. An unmet prerequisite result is not a false dependency condition: it concerns readiness below.

Identity and extent. Keep the same dependency for the same exact candidates, governed coordination use, branch and meaning of its precedence condition, including any genuinely constitutive schedule/priority rule. A different rendering, witness or descriptive coordination episteme alone changes none of those values. A changed candidate or meaning-changing condition/rule requires a new relation claim and identity assessment; the record reference is not itself the identity law. Within a temporally qualified use, the occurrence lasts while that branch predicate holds; a gap where it ceases to hold ends the occurrence, and a later re-established occurrence has a new extent. Omit temporal machinery for an atemporal constraint.

Readiness is a separate claim. For prerequisite-result continuation, identify a current E.11.PUA result-closure finding and the actual result and category-correct basis that satisfy the required content and receiving conditions. The closure may concern the prerequisite use or an adequate earlier result reused under §4.2.1. State readiness/applicability for this continuation as its own ordinary C.2.1 claim. A known unmet condition means not ready; missing information leaves readiness unresolved. An expectation, ordering edge or closure record’s presence alone supplies no achieved result.

The dependency is not an instruction to repeat a use whose adequate earlier result is already available. Apply the result-reuse exit before proposing execution. A changed closure can change readiness without changing the prospective dependency. No ordering or readiness claim authorizes Work. Page, seminar, identifier and display order do not establish a dependency.

E.11.PUR:4.5 - Practical procedure

1. Recover each candidate’s current concern, direct pattern, Solution, expectation, and ordinary boundary.
2. Keep a local reversible applicability, recommendation, or coordination judgement conversational when no named later reliance needs it. When a recommendation must remain addressable, choose ordinaryCompact unless that reliance needs the fit aspects separately addressable; use relianceBearing only for that reliance.
3. Inspect all five fit aspects. In ordinary use, keep them in one compact rationale. Under relianceBearing, materialize five separate findings and one applicability finding.
4. Establish the aggregate applicability under 4.1. A known misfit ends the applicability inquiry for that candidate under the inspected conditions. If the aggregate is insufficientBasis, obtain missing information only when an attainable answer can change a worthwhile continuation; otherwise return the missing-basis boundary. State the aggregate separately when the current question needs it. If step 5 supports a recommendation, include it there; when a reliance-bearing applicability finding exists, the two result values agree.
5. Compare an applicable candidate with the other serious continuations, including continuing the present work without a new pattern use. Recommend it only when its expected receiving value warrants its full burden; use C.11.DUA when that judgement is unclear. Finish without a positive recommendation when no candidate warrants one. The expectation is not an achieved result.
6. Before repeating a recommended use, compare any earlier result through 4.2.1. Reuse a matching result or reopen only the affected result question.
7. Coordinate several candidates as unordered, partially ordered, or totally ordered. Establish each needed pair under §4.4’s branch predicate. For prerequisiteResult, name exact required content, the selected supplier-use basis and its expectation. Then assess current readiness separately from actual closure, reusing an adequate earlier result before requiring another use.
8. Stop at the applicability answer or missing-basis boundary, recommendation, matching earlier result, coordination result, or conclusion that no new use is worth recommending now. The last outcome selects no candidate and requires no refusal document; it leaves existing obligations in force. A Plain next move, when one is useful, 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.

E.11.PUR:4.6 - Replay and currentness

Replay an ordinary conversational or addressable compact recommendation from the current concern, inspected candidate pattern and Solution, aggregate applicability, compact rationale over all five aspects, serious continuations considered, expected result and full burden, any current 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 inspected candidate uses, question, ordering mode, any pairwise precedence and bases, stop boundary, and, for each prerequisiteResult relation, the exact expectation, required content and selected supplier-use basis. Replay a readiness claim separately from the actual result closure, receiving conditions and any earlier-result reuse.

When a later use needs to replay a conclusion without a recommendation, recover the concern, the serious continuations, the value and burden that mattered, and the condition for reconsideration. No selected-candidate reference or five-finding dossier is required for that conclusion.

Replay a result-reuse stop from the earlier result episteme and edition, the question and declared use, relied source and dependency conditions, qualification and currentness boundary, and any separately current A.10 reliance or G.11 assertion.

Recheck the smallest affected finding, result question, or relation when a candidate Solution, result expectation, result entity or edition, relative object, direct basis or defining ClaimGraph, relied source or dependency condition, qualification or currentness boundary, fit basis, value or burden, alternative under consideration, dependent 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 earlier result condition reopens only the affected result question and later uses unless the candidate or present concern also changed. A changed prerequisite expectation or semantic precedence condition reopens the affected dependency and dependent use. A changed closure reopens readiness and only dependencies whose semantic basis also changed. A changed witness or rendering alone creates no new dependency. Recheck a genuinely constitutive schedule/priority rule when it changes. Separate G.11 assertions state edition, telemetry, currentness-window, and decay facts; PUR supplies the judgement-specific values and change conditions.

E.11.PUR:5 - Archetypal Grounding

E.11.PUR:5.1 - 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 named later use relies on it, the team states the applicability result and one compact rationale over all five aspects in the working conversation; it materializes no recommendation episteme or support profile. 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 backdate those addressable findings; if the original readable rationale was retained, it remains the earlier recommendation’s historical basis.

E.11.PUR:5.1.1 - An earlier result still answers the concern

The same team already has a C.28 causal-use result for the same pump model, intervention question, declared use, sources, assumptions, and qualification window. The team uses C.28 to compare that result episteme and edition with the present concern. Every comparison value still matches, so the team cites the result and stops instead of performing the C.28 use again.

If the team uses the result as a premise in a project discussion and the source-to-use account is still implicit, it uses A.10 to make the source → result → claim connection explicit for that bounded use. If the later gate Work relies on that result, its A.10 evidence-provenance path names the result and bounded use. If new operating conditions change the causal-use assumptions or qualification window, the team reopens that affected C.28 question rather than treating the old result as current or restarting every coordinated pattern use.

E.11.PUR:5.1.2 - No new use is worth recommending

A team considers an optional check that fits its concern and conditions. The most it could save is ten minutes; performing it takes an hour. The present work already meets the needed result, and no obligation requires this check. The team establishes applicability, compares the hour with the possible saving, and continues without selecting a new use. It needs neither a recommendation episteme with a fictitious candidate nor a refusal document. If asked why, it states the cost comparison in the conversation.

If new information makes that check capable of preventing a consequential loss, the team reopens this comparison. If the check becomes obligatory, the earlier optional-advice conclusion does not discharge the obligation. A less burdensome check with a worthwhile expected result can support the ordinary positive recommendation instead.

E.11.PUR:5.2 - 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.

State an unordered coordination: the team may use either pattern first or use them in parallel. No coordination episteme or ordering relation is required for that local judgement. If the later protocol revision becomes a named reliance that needs the coordination replayable, materialize one PatternUseCoordination@Context with orderingMode=unordered and no ordering relations. Their coexistence does not create a lifecycle or WorkPlan.

E.11.PUR:5.3 - Result-based precedence

A design team’s comparison rule requires the exact evaluation coordinates for candidates X and Y and their intended review question. The coordination selects its A.19.ECS candidate to supply that EvaluationCharacteristicSpaceSpec under a stated criterion for this task. The known rule, required content and supplier selection establish prerequisite-result precedence even while the spec is absent. Readiness is false when absence is known, or unresolved when its existence/applicability is unknown.

When a current PUA closure identifies the actual spec and its basis meeting those receiving conditions, readiness can be supported. If an earlier ECS result already meets them under §4.2.1, reuse that result without repeating ECS. A same-kind spec for another question is insufficient. If the comparison rule no longer requires this content, the dependency fails; if the rule itself is missing, the dependency is unresolved. Neither result changes candidate inspection or supplies Work authorization.

E.11.PUR:5.4 - Method precondition and a real ordered pair

An already-current material-kind classification is a solutionConditions fit fact for one machining candidate; it supplies no second candidate and no ordering pair.

By contrast, candidate A inspects the intact surface of one specimen and candidate B destructively tests that specimen. If B destroys the very surface condition A needs and A-before-B preserves both applicable uses, the methodPrecondition predicate supports that direction. If B leaves A’s required condition unaffected, this ground supplies no precedence. Two individually fitting candidates alone do not establish an edge.

E.11.PUR:5.5 - Shared resources and changes to support

Two candidate uses require the same exclusive instrument. Exclusion alone leaves their coordination conflict unresolved. An applicable selected schedule S1 assigning A before B supplies the directional sharedConstraintResolution basis; an applicable S2 selecting B before A defeats that A-before-B claim. An unknown priority rule leaves the direction unresolved. Adding both opposite edges would violate the strict-order cycle condition.

If a coordination description copied an old ECS expectation, replace the copy with the current exact expectation and required-content/supplier basis. Reassess the dependency only where that semantic content changed. A new closure or witness can instead change readiness without changing the ordering relation. A new rendering of S1 is descriptive; an actual change from S1 to S2 is constitutive and requires the changed order to be assessed. Candidate fit and unrelated dependencies remain usable.

E.11.PUR:5.6 - 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 the recommendation on current applicability, expected result, any current receiving use, and the other candidates still under consideration. A higher score is not another fit finding.

E.11.PUR:6 - Bias-Annotation

• Applicability-as-recommendation bias. A fitting pattern is automatically selected. Compare its expected receiving value and full burden with the serious continuations, including no new use; the best of several unhelpful candidates need not be recommended.
• Favorite-pattern proxy bias. Familiar PatternID substitutes for current value. State the concern, expected result, and any current 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.
• Stage-name repetition bias. The same result question is answered again because a later review or phase uses another label. Compare the earlier result through its direct pattern, reuse it when the relevant values still match, and reopen only the changed result question.

E.11.PUR:7 - Conformance Checklist

E.11.PUR:8 - Common Anti-Patterns and How to Avoid Them

E.11.PUR:9 - Consequences

Benefits. A team can explain why a pattern fits, why another is recommended, how several uses relate, and when an earlier answer remains usable without creating a false workflow. Ordinary reversible judgement remains light; reliance-bearing recommendations remain replayable. Prospective precedence retains its exact required content and supplier basis; readiness stays synchronized with actual PUA closure and earlier-result reuse.

Costs. A consequential or delayed-use recommendation needs an explicit rationale and may need five addressable fit findings. Partial orders need justified pairwise relations. Ordinary local judgement pays no record cost merely for symmetry, and candidates that answer different questions are not forced into a scalar ranking.

E.11.PUR:10 - 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 set of candidate pattern uses can be unordered, partially ordered, or totally ordered. Only an applicable directed constraint justifies an edge. A prerequisite-result edge can be established from the required content and selected supplier basis before the result exists. Actual closure is required for current readiness, including through a reusable earlier result. The alternative enabled-only edge would leave the known planning dependency unstated. This preserves graph structure without turning every explanation into a chain or minting a generic result relation.

Result reuse answers another question: whether an already obtained answer still serves the present concern. The direct result pattern supplies that comparison; A.10 supplies any later reliance account; and G.11 supplies currentness when it matters. Keeping those contributions separate avoids both duplicate work and a generic reuse relation that would hide why the result remains applicable.

E.11.PUR:11 - SoTA-Echoing

The practical implication is to recommend a use for its expected result, not for its familiarity or score, to stop on an earlier result that still answers the concern, 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, A.19, C.2.1, A.10, and G.11 supply the transdisciplinary candidate, comparison, result-identity, reliance, and currentness basis. These sources change 4.1-4.5, 5.1.1, 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. Use G.11 to manage source and telemetry currentness, then revise the affected PUR fit, rationale, recommendation, or return relation.

E.11.PUR:12 - 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 for an actual Problem; A.19, A.19.ECS, and A.19.CPM for characteristic-space construction and comparison; E.18.1 for P2W; the pattern that defines or tests an earlier result for result reuse; A.10 for later reliance on that result; G.11 for currentness; and the direct pattern that defines, constrains, or tests any stronger plan, work, transformation, gate, evidence, decision, authorization, result, or basis claim.
• Leads to: E.11.PUA for using the recommended pattern, or to the exact neighboring pattern when the stronger claim becomes current.

E.11.PUR:End