FPF Reference

    Pattern Use in a Working Situation and First Useful Result

    E.11.PUA · Stable · Pattern-language use pattern (E) · Normative within FPF pattern use from a current practical question to the first directly governed result. · 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 within FPF pattern use from a current practical question to the first directly governed result.

    Relations

    E.11.PUAbuilds onPractical-Use Guidance and Pattern Discovery
    E.11.PUAbuilds onFPF Authoring Conventions & Style Guide
    E.11.PUAcoordinates withPattern-Use Applicability, Recommendation, and Coordination
    E.11.PUAcoordinates withTransformation Flow Structure
    E.11.PUAcoordinates withNetwork of Transformation-Flow Structures
    E.11.PUAcoordinates withP2W Problem-to-Work Carry-Through
    E.11.PUAcoordinates withConstraint-Governed Transformation-Flow Unfolding Structure
    E.11.PUAcoordinates withRole-Method-Work Alignment (Contextual Enactment)
    E.11.PUAbuilds onTransformation Flow Structure
    E.11.PUAbuilds onNetwork of Transformation-Flow Structures
    E.11.PUAbuilds onExact Relation Recovery for Method and Work Claims
    E.11.PUAbuilds onNeeded Relation Claim Derivation and Relation-Kind Admission
    E.11.PUAbuilds onRole-Method-Work Alignment (Contextual Enactment)
    E.11.PUAbuilds onU.Episteme: Constitution, Empirical Grounding, and Edition Relations
    E.11.PUAbuilds onRelation-Declaration Slot Discipline - SlotKind, ValueKind, RefKind, and participant-designation discipline
    E.11.PUAcoordinates withImprovement-Oriented Quality Evaluation Question Framing
    E.11.PUAcoordinates withQuality Improvement Loop Method
    E.11.PUAcoordinates withTelemetry-Driven Refresh & Decay Orchestrator
    E.11.PUAcoordinates withPractical-Use Guidance and Pattern Discovery
    E.11.PUAoutline parentPractical-Use Guidance and Pattern Discovery
    E.11.PUAoutline next siblingPattern-Use Applicability, Recommendation, and Coordination
    E.11.PUAexplicit referencePractical-Use Guidance and Pattern Discovery
    E.11.PUAexplicit referenceU.Mechanism - Reusable Law-Governed Operation Declaration
    E.11.PUAexplicit referenceNeeded Relation Claim Derivation and Relation-Kind Admission
    E.11.PUAexplicit referenceU.Episteme: Constitution, Empirical Grounding, and Edition Relations
    E.11.PUAexplicit referenceMulti‑Method Dispatcher & MethodFamily Registry
    E.11.PUAexplicit referenceU.Method: Reusable Way of Doing with Explicit Applicability
    E.11.PUAexplicit referenceRole-Method-Work Alignment (Contextual Enactment)
    E.11.PUAexplicit referenceMulti‑View Publication Kit
    E.11.PUAexplicit referenceProblemCard
    E.11.PUAexplicit referenceTransformation Flow Structure
    E.11.PUAexplicit referenceNetwork of Transformation-Flow Structures
    E.11.PUAexplicit referenceProduction Work, Entity-Identity Inception, and Production Completion Recovery
    E.11.PUAexplicit referenceEvaluation CharacteristicSpace Construction
    E.11.PUAexplicit referencePattern-Use Applicability, Recommendation, and Coordination
    E.11.PUAexplicit referenceU.WorkPlan: The Schedule of Intent
    E.11.PUAexplicit referenceEvidence Graph Referring (C-4)
    E.11.PUAexplicit referenceTrust & Assurance Calculus (F–G–R with Congruence)
    E.11.PUAexplicit referenceTelemetry-Driven Refresh & Decay Orchestrator
    E.11.PUAexplicit referenceFPF Authoring Conventions & Style Guide
    E.11.PUAexplicit referenceExact Relation Recovery for Method and Work Claims
    E.11.PUAexplicit referenceRelation-Declaration Slot Discipline - SlotKind, ValueKind, RefKind, and participant-designation discipline
    E.11.PUAexplicit referenceP2W Problem-to-Work Carry-Through
    E.11.PUAexplicit referenceImprovement-Oriented Quality Evaluation Question Framing
    E.11.PUAexplicit referenceQuality Improvement Loop Method

    Content

    Problem frame

    Use this when

    Use this pattern when a person or assisting agent has a current entity or relation of concern, a practical question, and one plausible FPF pattern, and needs to follow that pattern's Solution to identify the smallest independently governed result usable now, or to stop because the direct basis required for that result is absent.

    The ordinary working moment is simple: "This pattern looks relevant. What do I do with it, what result should I expect, and when should I stop or return?" The user should be able to answer that question conversationally before any durable pattern-use record is considered.

    Primary EntityOfConcern. One use of one selected FPF pattern for a current practical question, ending at one exact first result or one honest stop. A realized or intended receiving use is named only when a current continuation or reliance actually needs it.

    What this buys. The user gets a direct path from a pattern to a useful subject result without confusing pattern inspection, method description, planning, performed work, and result evidence. A heavier trace remains available when another person, agent, tool, audit, or delayed decision will rely on the distinctions.

    Not this pattern when. While several public practical-use cards remain plausible, keep comparing the cards governed by E.11; begin E.11.PUA only after one direct pattern is selected. Use E.11.PUR when applicability, recommendation, or coordination among several candidate uses is the current question. Use E.18.1 when a wider method, plan, work, interpretation, and return flow depends on preservation of accepted problem-side distinctions. Use the A.15 family for intended or performed work.

    Problem

    Reading a pattern does not by itself apply it. Without an explicit use method, users often stop at recognition, create a meta-card instead of the subject result, or report a plan, note, generated answer, or support record as if the intended physical, clinical, organizational, learned, or epistemic result already existed.

    The opposite failure is also common: every bounded use is burdened with a shortlist, candidate form, five fit records, provenance graph, and closure dossier. The paperwork then becomes the apparent result and obscures the direct Solution that should guide the work. FPF adds no generic U.Result, U.WorkProduct, U.PatternApplication, or generic Use kind. First identify the exact result entity or relation occurrence and the pattern that governs its identity or obtaining. Then identify the method, plan, dated Work, transformation, evaluation, decision, or separately governed receiving-use object relative to which the result phrase is true, plus one category-correct direct basis: an obtaining relation occurrence, an A.6.1 operation-application binding, or an A.6.RCD local C.2.1 claim. The local claim has polarity and base-predicate owners; it does not obtain, and its derivation governor replaces none of those owners. A downstream receiver is separate and conditional.

    Forces

    ForcePressure on the solution
    Immediate usefulnessA reader needs a first result, not a tour of the pattern library.
    Ontological precisionPattern text, semantic method, plan, dated work, actual result, evidence, and receiving use have different kinds and remain governed by different direct patterns.
    Light ordinary useA reversible question with fast feedback should be handled in conversation or a short note.
    Durable relianceAnother person's later use, audit, automation, delayed feedback, expensive feedback, or hard reversal can rely on addressable distinctions.
    Result honestyA generated description or plan does not establish a physical change, clinical outcome, learned capability, organizational change, or performed work.
    Flow localityPattern selection, selected-pattern application, and downstream subject work can have different results. When one result later participates in another TFS, name both exact positions and the direct relation.
    Recoverable returnA wrong pattern, missing basis, stronger neighbor, or changed question is represented by a named return rather than silent improvisation.

    Solution

    Apply one selected pattern through a short result-oriented procedure. Keep the subject result in the foreground; add addressable pattern-use records only when a named receiving use relies on them.

    Kind-preserving dependency order (Plain)

    The acting U.System works under a U.RoleAssignment: it selects, constructs, or refines a semantic U.Method, records intended work only when planning is current, performs dated U.Work, and thereby changes, preserves, examines, or evaluates the real EntityOfConcern. The epistemic support line may guide and evaluate this work; it does not become the actor, role assignment, method, work, or affected entity.

    Use the following as a Plain dependency order for reading the case. It is not a U.Structure, workflow, form, interface, serialization, causal chain, or claim that every item exists. Each later item is inspected only when its direct governor and the current question make it necessary:

    1. start from the current EntityOfConcern, effective ReferenceScheme, and practical question;
    2. add an exact ClaimScope, project-work relation, or bounded-model-use structure only when that neighboring relation changes the use;
    3. add accepted problem-side material only when it is current;
    4. inspect a public template or the direct pattern, then keep the selected or rejected direct pattern with its fit reason;
    5. identify a selected, constructed, or refined U.Method only when the direct Solution makes that method current;
    6. identify a PlanItem or U.WorkPlan only when intended work is current, and identify dated U.Work only after the work occurs;
    7. name the independently governed entity or obtaining relation that answers the question; identify the exact method, plan, dated Work, transformation, evaluation, decision, or separately governed receiving-use object relative to which it is a result; and cite the category-correct direct basis for that reading; and
    8. state the separate receiving use, stop, return, or neighboring pattern only when it is current.

    TaskSignature remains a pre-method-selection signature. It can constrain method search; it is not the task, plan, or work occurrence. OEE and NQD may retain method or architecture candidates before selection. G.5 publishes a selected set; A.3.1 settles method identity; A.15 governs planning and work. The order above introduces no arrow, transfer, production, result, or use relation.

    The ordinary seven-step use

    Before making any pattern-use record, answer aloud: "What exactly do I have now? Which fact, measured condition, completed change, decision, or declared relation makes that answer true? What can I do next, and which later work has not happened yet?" Then use the exact terms below only where they change that answer.

    1. Recognize the working situation. Name the subject or relation in ordinary domain language and ask the current practical question. State an exact kind now only when a nearby kind difference can change the pattern or result.
    2. Inspect one direct pattern. Read its Problem frame, Problem, Forces, Solution, Consequences, ordinary boundary, and nearest stronger neighbor. Do not select from its title or one trigger word alone.
    3. Say what useful result would answer the question. Name the entity or obtaining relation plainly enough to distinguish it from a plan, description, recommendation, work occurrence, or other nearby value. Also say which exact method, plan, dated Work, transformation, evaluation, decision, or separately governed receiving-use object makes the result phrase meaningful here. When a nearby distinction remains ambiguous or replay matters, state the result kind and direct owner separately from the category-correct relation occurrence, A.6.1 binding, or local-claim basis that makes the phrase true.
    4. Apply the Solution. Perform the direct pattern's action-guiding method under its conditions. A project-tailored method description, WorkPlan, gate result, work occurrence, or other entity keeps its own direct governor. If the use claims that dated Work first constituted an entity, recover the separate A.15.PROD inception claim; pattern application is not a generic production relation.
    5. Check what now exists or obtains. Identify a newly current entity, relation occurrence, evaluation, decision, or change under its own direct owner. Open A.15.PROD only when exact dated Work and its actual changes are claimed to have first constituted an entity under its identity rule. A pre-existing entity may instead receive new grounding for the current question. If the expected subject result still does not exist, name only the exact interim entity and its own direct basis while leaving the subject expectation open. Do not turn grounding, planning, evaluation, acceptance, publication, or non-agentive change into production.
    6. State the immediate continuation only as needed. Name the next receiving use, stronger neighbor, or unresolved clarification in conversation. Materialize basis, expectation, result, flow, provenance, or boundary epistemes only when a named later use needs them to remain addressable.
    7. Stop or return. Stop when the smallest useful result or honest interim entity, its direct owner, the exact governed object relative to which the result phrase is true, and the category-correct direct basis can answer the current question, or when a pre-existing entity is adequately grounded through its exact relations. Return when the concern, basis, expected entity, governing pattern, direct relation, or current receiving-use condition changes. A genuine stop needs no receiver.

    The practical delta has three honest forms. An entity or relation occurrence may become current under its exact direct owner and category-correct basis; A.15.PROD enters only when exact dated Work and actual change are claimed to have first constituted an entity. A pre-existing entity may remain unchanged while an exact grounding finding becomes adequate for the current use. If the expected subject entity still does not exist, the exact interim entity, its direct basis, and the return condition become explicit while the expectation remains open.

    Reliance profiles

    PatternUseRelianceProfileValue = ordinaryBounded | relianceBearing

    In ordinaryBounded use, the subject, practical question, inspected pattern, useful result in ordinary language, governed relative-object kind, and stop or return remain recoverable in conversation. State exact kinds, direct owner, and category-correct direct basis only when needed to distinguish the result from a nearby value. No candidate basis, fit record, flow-position record, provenance note, closure record, or receiver is required.

    In relianceBearing use, materialize only the distinctions that the named reliance will use. Another reader may need a candidate basis and rationale. Automation may need the result kind and direct owner, the exact governed object, and the category-correct basis with its separate governors. Delayed review may need the descriptive flow position and a separate receiving-use disposition. A receiver appears only when return, continuation, or named reliance is current. No profile causes all support records to be materialized.

    When one named later use needs a compact replay carrier but not the fuller candidate and closure relations, use this reliance-bearing trace:

    CompactPatternUseTrace@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef
  entityOfConcernKindRef: U.KindRef
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  claimScopeRef?: U.EntityRef, referencing one U.ClaimScope
  modelUseStructureRef?: U.EntityRef, referencing one BoundedModelUseStructure
  projectWorkRef?: U.EntityRef, referencing one composite U.Work
  editionId
  practicalQuestionDescriptionRef: U.EpistemeRef
  consideredDirectPatternRef: U.EntityRef, referencing one U.MethodDescription
  patternSelectionDisposition: selected | rejected
  compactFitRationaleRef: U.EpistemeRef
  expectedResultKindRef: U.KindRef
  expectedResultDirectOwnerPatternRef: U.EntityRef, referencing one U.MethodDescription
  expectedResultRelativeToGovernedObjectKindRef: U.KindRef
  expectedResultRelativeToGovernedObjectDescriptionRef: U.EpistemeRef
  expectedResultDirectBasisKind: directRelationOccurrence | operationApplicationBinding | localRelationBearingClaim
  expectedResultDirectBasisDescriptionRef: U.EpistemeRef
  expectedResultDescriptionRef: U.EpistemeRef
  obtainedResultRef?: U.EntityRef
  obtainedResultKindRef?: U.KindRef
  obtainedResultDirectOwnerPatternRef?: U.EntityRef, referencing one U.MethodDescription
  obtainedResultRelativeToGovernedObjectRef?: U.EntityRef
  obtainedResultRelativeToGovernedObjectKindRef?: U.KindRef
  obtainedResultDirectBasisKind?: directRelationOccurrence | operationApplicationBinding | localRelationBearingClaim
  obtainedResultDirectBasisRef?: U.EntityRef
  obtainedDirectRelationOrBindingGoverningPatternRef?: U.EntityRef, referencing one U.MethodDescription
  obtainedLocalClaimDerivationGoverningPatternRef?: U.EntityRef, referencing A.6.RCD
  obtainedLocalClaimBasePredicateGoverningPatternRefs[]?: U.EntityRef, each referencing one U.MethodDescription
  boundaryDisposition: stop | return
  boundaryConditionDescriptionRef: U.EpistemeRef
  conditionalReceivingPatternRef?: U.EntityRef, referencing one U.MethodDescription

    The trace is absent from ordinary conversational use. When materialized for a named reliance, C.2.1 identifies it through claim content, exact EntityOfConcern, and effective reference scheme. claimScopeRef, modelUseStructureRef, and projectWorkRef are present only when the exact neighboring relation changes the pattern use; they are not additional episteme-identity fields, and the reference alone does not make that relation obtain.

    The expectation names the exact result kind and direct owner, the kind of method, plan, dated Work, transformation, evaluation, decision, or separately governed receiving-use object relative to which the result phrase would be true, and one category-correct basis branch. It asserts neither existence nor obtaining. For a selected pattern, the obtained-result core positions—from obtainedResultRef through obtainedResultDirectBasisRef—are present together or absent together; a rejected pattern leaves them absent. In the direct-relation branch, the claim graph exposes predicate, participants, applicability, obtaining, occurrence identity, and direct governor. In the A.6.1 branch, it exposes the operation, application, argument or result binding, and direct governor. In the local-claim branch, the direct relation-or-binding governor is absent, the A.6.RCD derivation governor and every base-predicate direct owner are present, and the claim graph exposes polarity, substrate or constructor, base predicates, participants, case facts, and any support or warrant required by the receiving use. The claim episteme does not obtain, and A.6.RCD does not replace its base owners.

    A return names conditionalReceivingPatternRef only when that continuation is current. A genuine stop leaves the field absent. No receiver is fabricated merely to complete the trace.

    Admitted support species and governing patterns

    PracticalUseQuestion@Context <: U.Episteme
PatternUseResultExpectation@Context <: U.Episteme
PatternUseResultClosureFinding@Context <: U.Episteme
PatternUseReceivingUseDispositionFinding@Context <: U.Episteme
PatternUseBoundaryCondition@Context <: U.Episteme
CandidatePatternUseRationale@Context <: U.Episteme
PatternUseCoordinationRationale@Context <: U.Episteme
PracticalUseCardComparisonRationale@Context <: U.Episteme
PatternUseFitFinding@Context <: U.Episteme
CandidatePatternUse@Context <: U.Episteme
PatternUseApplicabilityFinding@Context <: U.Episteme

    @Context in these legacy support-species names is a compatibility and retrieval suffix. It names no U.BoundedContext, universal situation, project container, relation, or identity field. Every support episteme follows C.2.1 identity. Claim scope, bounded model use, project work, qualification window, and other working conditions enter only through the exact neighboring object and direct relation needed by the receiving use.

    PUA governs the practical question, optional compact trace, candidate basis, candidate support episteme, candidate rationale, result expectation, result-closure finding, and separate receiving-use-disposition finding. [E.11](/generated/patterns/E.11) governs public card comparison rationale. [E.11.PUR](/generated/patterns/E.11.PUR) governs fit, applicability, recommendation, coordination rationale, coordination, and ordering. These relations consume A.6.5 SlotSpec discipline; A.6.5 does not govern their identity. PUA's findings cite the result's direct owner and one category-correct direct basis. In the local-claim branch they keep the A.6.RCD derivation governor distinct from every base-predicate owner. They introduce no result or actual-use relation kind.

    Question, boundary, and expectation

    PracticalUseQuestion@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef
  entityOfConcernKindRef: U.KindRef
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  claimScopeRef?: U.EntityRef, referencing one U.ClaimScope
  modelUseStructureRef?: U.EntityRef, referencing one BoundedModelUseStructure
  projectWorkRef?: U.EntityRef, referencing one composite U.Work
  editionId
  questionDescriptionRef: U.EpistemeRef

PatternUseBoundaryCondition@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the CandidatePatternUse@Context or PracticalUseQuestion@Context whose use is bounded
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  editionId
  boundaryConditionKind: candidateAdmission | minimumUsableResult | stop | return | wrongTurnRecovery | strongerNeighbor | missingGovernor | missingInformation | costEscalation | reversibilityEscalation | receivingPatternContinuation
  conditionDescriptionRef: U.EpistemeRef
  governingPatternRef: U.EntityRef, referencing one U.MethodDescription
  conditionalReceivingPatternRef?: U.EntityRef, referencing one U.MethodDescription
  conditionalReceivingPatternPositionKindRef?: U.KindRef
  conditionalReceivingPatternPositionRef?: U.EntityRef

PatternUseResultExpectation@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the CandidatePatternUse@Context whose result is expected
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  editionId
  expectedResultKindRef: U.KindRef
  expectedResultDirectOwnerPatternRef: U.EntityRef, referencing one U.MethodDescription
  expectedResultRelativeToGovernedObjectKindRef: U.KindRef
  expectedResultRelativeToGovernedObjectDescriptionRef: U.EpistemeRef
  expectedResultDirectBasisKind: directRelationOccurrence | operationApplicationBinding | localRelationBearingClaim
  expectedResultDirectBasisDescriptionRef: U.EpistemeRef
  expectedResultFlowPosition: patternSelectionFlowResult | selectedPatternApplicationFlowResult | downstreamSubjectWorkFlowResult
  expectedResultDescriptionRef: U.EpistemeRef
  minimumUsableResultBoundaryRef: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context
  intendedReceivingPatternRef?: U.EntityRef, referencing one U.MethodDescription
  intendedReceivingGovernedObjectKindRef?: U.KindRef
  intendedReceivingUseDescriptionRef?: U.EpistemeRef
  receivingPatternContinuationBoundaryRef?: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context

    The expectation never proves that the result entity exists, that a relation or binding obtains, or that a local claim is true. It first identifies the result kind and its direct owner. It then names which kind of exact method, plan, dated Work, transformation, evaluation, decision, or separately governed receiving-use object a real closure must identify, and which direct basis would make the readable result phrase true relative to that object. The basis description is branch-specific: relation occurrence; A.6.1 operation-application binding; or A.6.RCD local C.2.1 claim with polarity, substrate or constructor, base predicates and their direct owners, participants, case facts, and any support or warrant required by the receiving use. The last branch is not an obtaining basis, and the derivation governor is not a substitute subject owner.

    The flow position is a descriptive PUA role. intendedReceivingPatternRef, intendedReceivingGovernedObjectKindRef, intendedReceivingUseDescriptionRef, and receivingPatternContinuationBoundaryRef are present together only when an actual continuation or named downstream reliance is current; otherwise all four are absent. A genuine stop needs no receiver. In a boundary record, return, wrongTurnRecovery, strongerNeighbor, and receivingPatternContinuation may name the current receiver; stop, missingGovernor, and missingInformation do not invent one. Receiving-position kind and ref are both present or both absent. candidateAdmission means that Problem frame, Forces, Solution conditions, expected result, category-correct basis template, and ordinary boundary are recoverable enough for further inspection; it is neither an applicability finding nor a selection.

    Candidate basis under named reliance

    Construct a durable candidate only after inspecting the direct pattern's Problem frame, Problem, Forces, Solution, Consequences, and ordinary boundary. A public README template can supply a reusable starting point, but current project values come from the exact EntityOfConcern, practical question, effective reference scheme, and any current claim-scope, project-work, model-use, qualification-window, or other direct relation named by value.

    CandidatePatternUseBasisRelation@Context <: U.Relation:
  publicTemplateRef?: U.EpistemeRef, referencing one PublicCandidatePatternUseTemplate@FPFReadme
  directPatternRef: U.EntityRef, referencing one U.MethodDescription
  directSolutionSectionRef: U.EntityRef, referencing the E.17 PublicationUnit containing the direct pattern's Solution
  entityOfConcernRef: U.EntityRef
  entityOfConcernKindRef: U.KindRef
  practicalUseQuestionRef: U.EpistemeRef, referencing one PracticalUseQuestion@Context
  problemCardRef?: U.EpistemeRef, referencing one C.22.2 ProblemCard episteme
  resultExpectationRef: U.EpistemeRef, referencing one PatternUseResultExpectation@Context
  additionalBasisRelationRefs[]?: U.EntityRef, each referencing one CandidatePatternUseAdditionalBasisRelation@Context
  candidatePatternUseRef: U.EpistemeRef, referencing one CandidatePatternUse@Context
  RelationRefKind: U.EntityRef
  Direction: <entityOfConcernRef, practicalUseQuestionRef, directPatternRef> -> candidatePatternUseRef
  Dependence: local to the exact direct pattern, question, expectation, candidate editions, and any additional basis relation named below
  Identity: <entityOfConcernRef, practicalUseQuestionRef, directPatternRef, directSolutionSectionRef, resultExpectationRef, candidatePatternUseRef>

CandidatePatternUseAdditionalBasisRelation@Context <: U.Relation:
  candidatePatternUseRef: U.EpistemeRef, referencing one CandidatePatternUse@Context
  basisValueRef: U.EntityRef
  basisValueKindRef: U.KindRef
  basisRelationSignatureRef?: U.EntityRef, referencing one U.Signature
  basisGoverningPatternRef: U.EntityRef, referencing one U.MethodDescription
  basisUseDescriptionRef: U.EpistemeRef
  RelationRefKind: U.EntityRef
  Direction: basisValueRef -> candidatePatternUseRef for basisUseDescriptionRef
  Dependence: local to the candidate, basis value, exact governing relation, and their current editions
  Identity: <candidatePatternUseRef, basisValueRef, basisValueKindRef, basisRelationSignatureRef if present, basisUseDescriptionRef>

CandidatePatternUse@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef
  entityOfConcernKindRef: U.KindRef
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  claimScopeRef?: U.EntityRef, referencing one U.ClaimScope
  modelUseStructureRef?: U.EntityRef, referencing one BoundedModelUseStructure
  projectWorkRef?: U.EntityRef, referencing one composite U.Work
  editionId
  practicalUseQuestionRef: U.EpistemeRef, referencing one PracticalUseQuestion@Context
  problemCardRef?: U.EpistemeRef, referencing one C.22.2 ProblemCard episteme
  publicTemplateRef?: U.EpistemeRef, referencing one PublicCandidatePatternUseTemplate@FPFReadme
  directPatternRef: U.EntityRef, referencing one U.MethodDescription
  directSolutionSectionRef: U.EntityRef, referencing the E.17 PublicationUnit containing the direct pattern's Solution
  resultExpectationRef: U.EpistemeRef, referencing one PatternUseResultExpectation@Context
  candidateAdmissionBoundaryRef: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context
  returnBoundaryRef: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context

    Each additional basis relation names its exact value, kind, relation signature when current, direct governing pattern, and use in this candidate. The public template is absent when the candidate was formed by direct pattern inspection without a README template. directSolutionSectionRef is the Solution section of directPatternRef; no redundant solution-method-description ref is retained. A project-tailored method description is a separate U.MethodDescription under A.3.2. If dated Work first constitutes that episteme and the inception claim matters, A.15.PROD governs the claim; any derivation or reuse relation to the direct pattern remains separately governed. Applicability, recommendation, and coordination remain governed by [E.11.PUR](/generated/patterns/E.11.PUR).

    Rationale subjects stay distinct

    CandidatePatternUseRationale@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing one CandidatePatternUse@Context
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  editionId
  rationaleDescriptionRef: U.EpistemeRef
  rationaleBasisEpistemeRefs[]: U.EpistemeRef
  rationaleUseBoundaryRef: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context

    Candidate rationale has one candidate subject. [E.11.PUR](/generated/patterns/E.11.PUR) owns the coordination-rationale schema over a declared candidate set. [E.11](/generated/patterns/E.11) owns the public-card comparison-rationale schema over one public guidance episteme before a project candidate is constructed. No rationale episteme is a universal bag.

    Actual-result closure and receiving-use disposition

    PUA introduces no actual-result relation and no universal actual-use relation. Keep two questions separate: what makes the candidate result entity exist or the relation occurrence obtain under its direct owner, and what exact direct basis makes the readable result phrase true relative to the current method, plan, dated Work, transformation, evaluation, decision, or separately governed receiving-use object. Those bases may be the same occurrence only when the result itself is that relation occurrence. When a named later use needs addressable closure, materialize a C.2.1 finding that points to both the result's direct owner and the category-correct basis:

    PatternUseResultClosureFinding@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the independently governed result entity or obtaining relation occurrence
  entityOfConcernKindRef: U.KindRef
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  editionId
  candidatePatternUseRef: U.EpistemeRef, referencing one CandidatePatternUse@Context
  resultExpectationRef: U.EpistemeRef, referencing one PatternUseResultExpectation@Context
  resultDirectOwnerPatternRef: U.EntityRef, referencing one U.MethodDescription
  resultRelativeToGovernedObjectRef: U.EntityRef
  resultRelativeToGovernedObjectKindRef: U.KindRef
  resultDirectBasisKind: directRelationOccurrence | operationApplicationBinding | localRelationBearingClaim
  resultDirectBasisRef: U.EntityRef
  resultDirectRelationOrBindingGoverningPatternRef?: U.EntityRef, referencing one U.MethodDescription
  resultLocalClaimDerivationGoverningPatternRef?: U.EntityRef, referencing A.6.RCD
  resultLocalClaimBasePredicateGoverningPatternRefs[]?: U.EntityRef, each referencing one U.MethodDescription
  resultFlowPosition: patternSelectionFlowResult | selectedPatternApplicationFlowResult | downstreamSubjectWorkFlowResult
  resultBearingPathSliceId?: PathSliceId
  resultBearingDesignRunTag?: DesignRunTag
  closureBoundaryRef: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context

    The three flow-position values are descriptive PUA roles, not kinds, relations, or occurrence identities. The finding's claim graph names the result entity, its direct owner, the exact governed object relative to which the result wording is true, and exactly one direct-basis branch. For a direct relation occurrence it names predicate, participants, applicability, obtaining, occurrence identity, and the direct governor. For an A.6.1 binding it names operation, application, argument or result binding, and its direct governor. For an A.6.RCD local C.2.1 claim, the relation-or-binding governor is absent; the claim ref, polarity, substrate or constructor, base predicates, their direct owners, participants, case facts, and any support or warrant required by the receiving use are recoverable, with the derivation governor named separately. The claim does not obtain. If the result itself is a relation occurrence, entityOfConcernRef and resultDirectBasisRef may designate that same occurrence. The closure finding reports those facts; it creates none of them.

    Open A.15.PROD only when the closure claims that exact dated Work, through independently identified actual changes and the applicable identity rule, first constituted an entity. A relation occurrence may first obtain through its direct predicate; an evaluation or decision becomes current under its own direct owner; a non-agentive change needs no production claim. Completion, evaluation, acceptance, publication, continuation, and later use remain separate. If the claimed result existed already, use 4.6 instead. If no direct basis is recoverable, retain the independently governed entity and return the exact missingGovernor or missingInformation boundary rather than minting a closure relation.

    Path slice and DesignRunTag are both present only when the exact result-bearing position and its one TFS are already recoverable under E.18; otherwise both are absent. These fields are provenance cues, not identifiers for another TFS, a network, or a cross-flow relation.

    Record receiving-use disposition separately, and only for a named reliance:

    PatternUseReceivingUseDispositionFinding@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the same result entity or relation occurrence as the closure finding
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  editionId
  resultClosureFindingRef: U.EpistemeRef, referencing one PatternUseResultClosureFinding@Context
  receivingUseRealizationState: realized | intendedNotYetRealized
  receivingGovernedObjectRef?: U.EntityRef
  receivingGovernedObjectKindRef?: U.KindRef
  realizedReceivingUseDirectBasisKind?: directRelationOccurrence | operationApplicationBinding | localRelationBearingClaim
  realizedReceivingUseDirectBasisRef?: U.EntityRef
  realizedReceivingUseDirectRelationOrBindingGoverningPatternRef?: U.EntityRef, referencing one U.MethodDescription
  realizedReceivingUseLocalClaimDerivationGoverningPatternRef?: U.EntityRef, referencing A.6.RCD
  realizedReceivingUseLocalClaimBasePredicateGoverningPatternRefs[]?: U.EntityRef, each referencing one U.MethodDescription
  intendedReceivingPatternRef?: U.EntityRef, referencing one U.MethodDescription
  intendedReceivingGovernedObjectKindRef?: U.KindRef
  intendedReceivingUseDescriptionRef?: U.EpistemeRef
  receivingUseRealizationConditionRef?: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context

    In the realized state, the receiving governed object, kind, direct-basis kind, and basis ref are present; the intended positions are absent. The same branch rule separates a direct relation or A.6.1 governor from an A.6.RCD derivation governor and the direct owners of the local claim's base predicates. The claim graph exposes the exact participants and facts. In intendedNotYetRealized, the intended pattern, governed-object kind, description, and condition are present together and all realized positions are absent; an intention is not an obtaining use relation. A stop without a receiving use has no disposition finding.

    When ordinary language says that a result from one TFS is used as an input, tool, context, or constraint in another, treat those words only as cues. Name the exact result-bearing position and exact receiving position—one FlowPositionRef for each—plus the directly governed relation occurrence connecting their participants, and keep the result's kind unchanged. With no direct relation kind or predicate, return missing-governor; with a governor but undecided facts, leave the relation open and name the grounding boundary; with a false predicate, assert no occurrence; with an obtaining occurrence but a missing endpoint binding, return missing-endpoint-binding and name that binding. Use E.18 for each TFS-local position and local DesignRunTag; use E.18.NET only when independently identified TFS values must be treated together as a network. No input, tool, context, constraint, result, or adjacency label supplies the direct relation.

    When the thing being called a result is U.Work, identify that dated occurrence under A.15.1. Planning, setup, authorization, triggering, or enabling work does not produce that Work. Call the occurrence a result of the selected use in a reliance-bearing closure only when the exact category-correct basis for that reading is present; otherwise keep the Work and the pattern-use description separate.

    Pre-existing and still-absent subject results

    When the expected entity existed before the current use, the current use may establish a C.2.1 grounding finding about that unchanged entity:

    GroundingBasisPair:
  groundingRelationOccurrenceRef: U.EntityRef
  groundingGoverningPatternRef: U.EntityRef, referencing one U.MethodDescription

PreExistingResultGroundingFinding@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the pre-existing entity
  entityOfConcernKindRef: U.KindRef
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  editionId
  candidatePatternUseRef: U.EpistemeRef, referencing one CandidatePatternUse@Context
  resultExpectationRef: U.EpistemeRef, referencing one PatternUseResultExpectation@Context
  groundingBasisPairs[1..*]: GroundingBasisPair
  groundingAdequacyDescriptionRef: U.EpistemeRef
  groundingUseBoundaryRef: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context

    Each GroundingBasisPair preserves one relation occurrence with its direct governor. The finding's ClaimGraph names the grounded proposition and the covered subject claim. For a C.2.1 episteme a pair may cite an exact EpistemeEmpiricalGroundingRelation; for another subject it uses the direct measurement, observation, evidence-use, diagnostic, or subject predicate that actually grounds that proposition. Inspection, a record, or evidence proximity does not ground the entity by itself. If no direct grounding basis is recoverable, return its exact blocker. The pre-existing entity is not newly produced.

    If the current use calls the grounding finding its result, add a separate PatternUseResultClosureFinding@Context whose EntityOfConcern is that finding. Its direct basis must connect the finding to the current method, plan, Work, transformation, evaluation, decision, or receiving-use object through a relation occurrence, A.6.1 binding, or category-correct local claim. The occurrence that grounds the pre-existing subject does not by itself make the grounding finding a result of the current use. Cite A.15.PROD only when exact dated Work and its actual changes first constituted the finding episteme.

    When the expected subject result still does not exist, close the current use only on an exact interim PatternUseResultClosureFinding@Context. Its entity has its own direct owner and category-correct basis relative to the current governed object. Keep the subject-result expectation open. A plan for machining does not become a machined component; a treatment recommendation does not become a changed clinical state; an assessment plan does not become learned capability.

    Reliance-bearing final-practice test

    Use this test when the declared teaching, rehearsal, or evaluation use is to establish that a participant can select a pattern, preserve the kind and direct basis of its result, and leave another participant a replayable continuation. This is deliberately relianceBearing: the evaluator relies on the selected basis, expectation, grounding state, and continuation. Its row count is a test condition, not a general rule for pattern use. The test does not require or assert a wider CGUS.

    PatternUsePracticeContinuationDescription@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the selected CandidatePatternUse@Context
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  editionId
  actionOrProposedUseDescriptionRef: U.EpistemeRef
  expectedResultDescriptionRef: U.EpistemeRef
  expectedResultKindRef: U.KindRef
  directPatternIdentifier: PatternIdentifierValue
  directPatternName: PatternNameValue
  currentConditionDescriptionRef: U.EpistemeRef
  continuationDisposition: continue | branch | return | stop

FinalPracticePatternUseTestResult@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the selected CandidatePatternUse@Context
  claimGraph: U.ClaimGraph by value
  referenceSchemeRef: U.ReferenceSchemeRef
  editionId
  practicalUseQuestionRef: U.EpistemeRef, referencing one PracticalUseQuestion@Context
  selectedCandidatePatternUseBasisRelationRef: U.EntityRef, referencing one CandidatePatternUseBasisRelation@Context
  selectedFirstResultExpectationRef: U.EpistemeRef, referencing one PatternUseResultExpectation@Context
  selectedFirstResultGroundingState: SelectedFirstResultGroundingStateValue
  selectedFirstResultFlowPosition: PatternUseResultFlowPositionValue
  newlyCurrentSubjectResultClosureFindingRef?: U.EpistemeRef, referencing one PatternUseResultClosureFinding@Context
  preExistingResultGroundingFindingRef?: U.EpistemeRef, referencing one PreExistingResultGroundingFinding@Context
  preExistingGroundingResultClosureFindingRef?: U.EpistemeRef, referencing one PatternUseResultClosureFinding@Context whose EntityOfConcern is that grounding finding
  expectedSubjectResultAbsentInterimResultClosureFindingRef?: U.EpistemeRef, referencing one PatternUseResultClosureFinding@Context
  selectedFirstResultReceivingUseDispositionFindingRef?: U.EpistemeRef, referencing one PatternUseReceivingUseDispositionFinding@Context
  practiceContinuationDescriptionRefs[3..5]: U.EpistemeRef, each referencing one PatternUsePracticeContinuationDescription@Context
  branchOrReturnContinuationDescriptionRef: U.EpistemeRef, referencing one member of practiceContinuationDescriptionRefs
  continuableWorkStateDescriptionRef: U.EpistemeRef
  explicitUnknownDescriptionRef: U.EpistemeRef
  minimalClarificationPatternRef: U.EntityRef, referencing one U.MethodDescription
  expectedClarificationResultKindRef: U.KindRef
  admittedDemonstrativeSliceRef?: U.EpistemeRef, referencing one DemonstrativeUnfoldingSlice@Context
  demonstratedPatternUseRowRefs[3..5]?: U.EpistemeRef, each referencing one DemonstratedPatternUseRow@Context

    Each practice continuation description states an action or proposed use, the expected result and its kind, the full PatternID and pattern name, and the condition under which that continuation is current. Its entityOfConcernRef resolves to the same selected CandidatePatternUse@Context as the test result. The test passes only when at least one of the three to five descriptions has continuationDisposition=branch or return, the final continuable work position is explicit, and one consequential unknown names the minimum clarification pattern and expected clarification-result kind. The selected basis relation resolves to that same candidate; the candidate names the same question and expectation as the test result, and the expectation and test result name the same descriptive flow position.

    The practice descriptions remain ordinary PUA epistemes when no wider CGUS is admitted. If a wider CGUS is later admitted, admittedDemonstrativeSliceRef and demonstratedPatternUseRowRefs[3..5] are both present or both absent. The rows correspond in order to the existing practice descriptions, and each row's sourcePracticeContinuationDescriptionRef points to its corresponding description. They do not replace or retype the descriptions, candidate, subject result, or continuable work position.

    SelectedFirstResultGroundingStateValue is newlyCurrentSubjectResult | preExistingWithGrounding | expectedSubjectResultAbsent. Exactly one state branch is filled:

    • For newlyCurrentSubjectResult, fill newlyCurrentSubjectResultClosureFindingRef and leave the other state positions absent. The closure separates result identity or obtaining under the direct owner from the basis that makes it this use's result. A relation occurrence may first obtain through its direct predicate; an evaluation or decision becomes current under its own owner; an actual non-agentive change remains under A.3.4. Cite A.15.PROD only when exact dated Work and its actual changes first constituted an entity under its identity rule.
    • For preExistingWithGrounding, fill both preExistingResultGroundingFindingRef and preExistingGroundingResultClosureFindingRef and leave the other state positions absent. The grounding finding names the already-existing entity and its paired grounding relations and owners. Its separate closure uses another category-correct basis to make that finding the exercise's result; a subject-grounding occurrence alone does not. Cite A.15.PROD only if exact dated Work first constituted the finding episteme. The exercise does not produce the pre-existing entity.
    • For expectedSubjectResultAbsent, fill expectedSubjectResultAbsentInterimResultClosureFindingRef and leave the other state positions absent. The interim entity has its own kind, direct owner, exact governed relative object, and category-correct basis. It may support later work but does not satisfy the selected subject-result expectation.

    Fill selectedFirstResultReceivingUseDispositionFindingRef only when the declared test relies on an addressable realized or intended receiving use. It must point to the selected state-specific closure, including the grounding-finding closure in the pre-existing branch. The continuable-work description says what project work can proceed from this state-specific result. The test fails when it merely retells a card, expands into a whole-project plan, treats a public template as a recommendation, claims performed work without an A.15.1-grounded U.Work, infers a physical, clinical, organizational, or learned change from its description, or asserts a CGUS only because the practice contains several rows.

    Replay and currentness

    For immediate ordinaryBounded use, recover from the conversation the working subject and question, the direct pattern inspected, the useful result or honest interim entity, the governed relative-object kind, the category-correct direct basis, and the stop or return. Do not reconstruct a candidate dossier, flow position, or receiver merely to replay a cheap local use.

    When a named later use relies on fuller replay, recover the exact EntityOfConcern, effective reference scheme, practical question, selected direct pattern and edition-pinned Solution, expected result kind and direct owner, descriptive flow position, exact governed relative object, category-correct direct basis with its separate governors, grounded actual or honest interim entity, any separately current receiving-use disposition, and stop or return boundary from the support epistemes materialized for that reliance. Add claim scope, project work, model-use structure, qualification window, receiver, or another working condition only through its exact neighboring relation when that relation changes the replayed use.

    Recheck the smallest affected claim or relation when the concern, candidate basis, direct Solution, expected result, result grounding, flow position, receiving-use condition, or boundary changes. Reopen pattern selection only when that change alters candidate fit; a new measurement of the same result does not by itself select another pattern. G.11 governs edition, telemetry, currentness-window, and decay orchestration; PUA supplies the use-specific values and change conditions that orchestration inspects.

    Archetypal Grounding

    Episteme result: a usable problem card

    A team has a vague recurring pump-failure concern and asks whether it can be articulated well enough to guide later method selection. In cheap ordinary use it can say, "Use C.22.2 to make a usable problem card," then state the bounded concern, affected entity, obstacle, stakes, evidence state, and honest next use. Those contents can leave the exact C.22.2 ProblemCard episteme and selectedPatternApplicationFlowResult position recoverable without stating or recording either one. Name them explicitly only when a nearby kind confusion or named reliance requires replay; C.22.2 and C.2.1 still govern the episteme.

    If the card did not exist before this exercise and the team claims that the drafting episode first constituted it, identify the dated drafting U.Work, the card's C.2.1 identity rule, the actual changes, and the local A.15.PROD entity-identity-inception claim. That claim establishes the card's Work-attributed inception, not by itself that the card is this PUA use's result. A reliance-bearing closure separately names the category-correct basis that makes the card the result relative to the current application or governed object. Without the inception basis, do not say that pattern application produced the card; state only the card content and leave its inception provenance open. Any later P2W participation uses its exact direct relation or local claim. The team need not materialize PUA closure records during a cheap conversational use.

    Evaluation specification without a ProblemCard

    An architecture team already has a bounded comparison question and needs no accepted C.22.2 ProblemCard episteme. It applies A.19.ECS and states one exact EvaluationCharacteristicSpaceSpec with declared coordinates, scales, comparators, and evidence rules; A.19.ECS and C.2.1 govern that specification episteme. The optional problemCardRef remains absent.

    The application-flow label is only a readable PUA position. If the team claims that exact planning or specification Work first constituted the episteme, cite its local A.15.PROD inception claim for that subject fact. A reliance-bearing PUA closure separately identifies the category-correct basis that makes the specification a result relative to the current application or governed object. If a later comparison actually uses the specification, cite the exact direct relation, A.6.1 binding, or local relation-bearing claim governed by that comparison pattern. Without the corresponding basis, keep the specification, its PUA closure, and the later comparison separate.

    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 position, exact receiving position, and directly governed relation occurrence or 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 directly governed compiler-use relation occurrence. The compiler edition keeps its kind. Return to E.18 when either TFS-local position is unresolved; return to 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.

    AI-assisted ordinary use returns the subject result

    An engineer asks an AI assistant to apply an already selected A.19.ECS pattern to a pump-comparison question. The needed result is one exact EvaluationCharacteristicSpaceSpec with admitted coordinates, scales, comparators, and evidence rules. No later use asks for a durable pattern-selection trace.

    The assistant returns the specification content in ordinary language and keeps the concern, direct pattern, and stop condition recoverable in the conversation. The text is the required specification only when it satisfies the A.19.ECS and C.2.1 identity rules. Successful ordinary use creates no candidate, fit, applicability, rationale, expectation, or closure record merely because AI helped. If the use also claims first constitution, identify the actual responsible Work and local A.15.PROD inception claim. If the available basis cannot support the specification, name the unresolved coordinate, scale, comparator, or evidence-rule position, return to A.19.ECS, and leave the completed-specification expectation open. Materialize that return as PatternUseBoundaryCondition@Context only when a named reliance needs an addressable boundary; do not emit a complete meta-record stack.

    Physical result: work is still future

    A machining team applies a planning pattern for a dimensionally accepted component and states one exact U.WorkPlan under A.15.2. If it claims that planning Work first constituted that plan episteme, cite the local A.15.PROD inception claim. The metal blank remains unchanged.

    The plan is the independently governed entity at the selectedPatternApplicationFlowResult position. The component remains an open downstreamSubjectWorkFlowResult expectation until dated machining Work occurs. The team may continue with the A.15 work patterns; it cannot fill the component position with the plan, simulation, inspection checklist, or generated prose.

    After machining Work occurs, identify the exact A.3.4 transformation and the direct work-to-change predicate or admitted local claim. If the Work first makes a new component satisfy its identity rule, cite the separate A.15.PROD inception claim; if a completion criterion is satisfied, cite the separate completion claim. Evaluation, dimensional evidence, and acceptance remain separately governed. A reliance-bearing PUA closure must additionally name the category-correct basis that makes the component or changed state the result relative to the exact machining Work or other governed object; neither the flow position nor result wording supplies it.

    Clinical result: a state and its note stay separate

    A clinician uses a direct decision pattern to state one treatment-plan episteme. The decision pattern and C.2.1 govern the plan; a claim that dated decision Work first constituted it requires its local A.15.PROD inception basis. The plan may describe an intended receiving use, but it does not establish that treatment occurred or that the patient's state changed.

    After treatment Work occurs, identify the clinical change through A.3.4 and its exact direct treatment-work-to-change governor. The clinical state and the case-note episteme can both be current, but they keep different identities and relations. The note may support grounding and later reliance; it does not become the patient's state.

    If the clinically relevant state existed before the current pattern use, return a PreExistingResultGroundingFinding@Context whose claim graph cites the exact examination, measurement, diagnostic, or evidence-use relation that grounds it for the present question. The examination does not produce that state or supply an unknown earlier treatment history. Missing direct grounding returns its exact blocker.

    Learned capability and assessment remain separate

    Teaching is dated Work under its direct educational and A.15 patterns. A later assessment episteme may support a claim that the learner demonstrated a bounded capability or skill only through the exact educational, assessment, evidence-use, or subject predicate governing that claim. The capability and the assessment episteme remain distinct. A completed lesson, assessment plan, or filled record cannot occupy the learned-capability position by itself; a missing capability governor returns missing-governor rather than a generic learning result.

    Pre-existing result: inspection does not reproduce it

    A maintenance engineer inspects an installed pump that predates the current pattern use. Current measurements may ground the pump for a compatibility question only through the exact measurement, observation, diagnostic, or evidence-use relations owned by the applicable patterns; the historical production claim lies outside the basis.

    Use PreExistingResultGroundingFinding@Context for the present grounding and cite its exact GroundingBasisPair values. An inspection note or record may describe the pump and support evidence use, but it cannot replace the physical pump or occupy the expected subject-result position. Keep producing-work provenance absent. The current inspection neither manufactures the pump nor proves how it was manufactured. If the direct grounding relation cannot be recovered, return that blocker instead of treating inspection proximity as grounding.

    Repair a plan-as-component closure locally

    A machining rehearsal selected the correct planning pattern and stated a valid U.WorkPlan, but its closure named the plan as a downstreamSubjectWorkFlowResult and treated the component expectation as satisfied. The concern, candidate basis, direct pattern, and WorkPlan remain sound.

    Repair the expectation and closure finding: place the U.WorkPlan in the descriptive selectedPatternApplicationFlowResult position, cite its exact A.15.2 identity and any current A.15.PROD inception claim for Work-attributed first constitution, and separately cite the category-correct basis that makes this plan the result relative to the current pattern use. Remove the unsupported component closure and any realized receiving-use finding that depended on it, and keep the component as an open downstream expectation. The next current use enters the A.15 work family. No new candidate selection or reconstruction of the WorkPlan is needed.

    Complete trace, absent result

    An automated report raises pattern-use trace completeness to 100 percent by filling every candidate, rationale, expectation, and boundary position. Operators begin treating the green report as completion, while the direct basis for the claimed result and the intended receiving use remain absent more often.

    The trace measure improved while subject progress worsened. Keep completeness as a trace-quality measure, apply E.13 to the substitution, and evaluate PUA success from the exact result or honest interim entity, its direct owner, the exact method, plan, Work, transformation, evaluation, decision, or receiving-use object relative to which the phrase is true, its category-correct direct basis, and any separately current receiving-use disposition. Empty result-basis positions are not repaired by adding more support records.

    Bias-Annotation

    • Recognition-only bias. A matching title or trigger word is treated as application. Repair by inspecting the direct pattern's full problem and solution conditions and naming the expected result, its direct owner, governed relative-object kind, and category-correct basis.
    • Record-as-result bias. A candidate form, trace, note, dashboard, or assessment record replaces the subject result. Repair by restoring the exact entity or relation occurrence, its direct owner, and the separate category-correct basis that makes it the result relative to the current governed object.
    • Plan-as-work bias. Intended work or a generated plan is reported as performed work. Return to A.15 and ground the dated occurrence before asserting U.Work.
    • Flow-collapse bias. A selection result, application result, and downstream-work result are merged because each is called "result". Restore the three descriptive positions, each independently governed entity and basis, and any current E.18 crossing.
    • Maximum-trace bias. Every use emits every schema. Return to the named reliance and materialize only distinctions that it will use.

    Conformance Checklist

    IDCheckPassing condition
    PUA-1Current concernThe working subject or relation and practical question are recognizable in domain language before the PatternID; an exact kind is explicit only when a nearby kind difference changes the use.
    PUA-2Direct inspectionProblem frame, Problem, Forces, Solution, Consequences, ordinary boundary, and stronger neighbor were inspected.
    PUA-3Useful resultOrdinary use distinguishes the independently governed entity or relation occurrence from nearby values and identifies the kind of method, plan, Work, transformation, evaluation, decision, or receiving-use object relative to which it is a result. Exact kind, direct owner, category-correct basis, and descriptive flow position are explicit only when ambiguity or named reliance makes them necessary.
    PUA-4Reliance profileOrdinary use remains conversational; every materialized support record names the receiving reliance that needs it.
    PUA-5Honest closureThe use distinguishes a newly current entity, relation occurrence, evaluation, decision, or change under its direct owner; a pre-existing entity with new paired grounding; and an exact interim entity while the expected subject result remains absent. A materialized closure cites the result, direct owner, governed relative object, and category-correct direct basis before any descriptive flow position. A.15.PROD appears only for an exact Work-attributed entity-inception claim.
    PUA-6Work integrityU.Work names an A.15.1-grounded occurrence and is never said to be produced by planning, setup, authorization, or another Work. A claim that Work first constituted another entity cites the exact A.15.PROD inception claim and its direct work-to-change bases.
    PUA-7Receiving useThe immediate continuation is understandable when one is current. A materialized realized-use finding cites the exact receiving governed object and one category-correct direct basis, keeping any A.6.RCD derivation governor distinct from base-predicate owners. An intended-use finding asserts no obtaining relation. A genuine stop has no receiver or disposition finding.
    PUA-8ReturnChanged concern, basis, result, pattern, or use opens a named return instead of silent reinterpretation.

    Common Anti-Patterns and How to Avoid Them

    MisuseWhy it failsRepair
    Select from the pattern nameSimilar symptoms can have different problem frames and forces.Inspect the direct pattern and state the result that would answer the current question.
    Fill the candidate record firstThe record freezes a choice before the Solution and boundary are understood.Inspect first; materialize the candidate only for a named reliance.
    Report generated text as the resultText can describe a physical, clinical, organizational, or learned result without producing it.Name the exact interim episteme and leave the subject expectation open.
    Treat a support record as proofA well-formed record proves only that fields were written.Ground inspection, Work, the result entity, its direct basis, evidence, and any receiving-use relation through their own patterns.
    Call one result the next flow's inputThe same entity may participate in another TFS as an input, tool, context, constraint, or other governed participant without changing kind, but those labels and adjacency do not identify its relation.Name the exact source and receiving positions—one FlowPositionRef for each—and the directly governed relation occurrence. If it does not obtain, keep the positions separate and state the exact missing-governor, unresolved-grounding, false-predicate, or missing-endpoint-binding boundary. Use E.18 for each TFS-local position and E.18.NET only for the network of independently identified TFS values.

    Consequences

    Benefits. A cold reader can apply one pattern and reach a useful result without learning a meta-workflow. Ordinary use remains light, while high-reliance use can preserve the exact result, its direct owner, the governed relative object, the category-correct basis with separate governors, and any separately current receiving-use disposition. Physical, clinical, learned, organizational, work, and epistemic results keep their own governors instead of being forced into one result or product family.

    Costs. A success claim is complete only after the exact entity or relation occurrence, direct owner, governed relative object, and category-correct direct basis are recoverable. Reliance-bearing use may add addressable findings. Cross-flow participation requires both exact TFS-local positions and the directly governed relation; E.18.NET is added only when independently identified TFS values must be treated together as a network.

    Rationale

    FPF patterns are action-guiding method descriptions, but readers meet them in concrete situations. The missing middle is neither discovery nor recommendation: follow one selected conditional Solution to identify the first independently governed result that answers the current question; if the direct basis for treating it as this use's result is absent, stop and name the missing basis.

    Separating ordinary semantic checking from conditional record materialization protects both usability and rigor. A conversation can be sufficient for a bounded reversible question. Another person's later use, an audit, an automated use, or an expensive decision can demand addressable support. The same ontology serves both profiles; only the reliance changes the recording granularity.

    The first-result boundary prevents proxy completion. A plan, note, simulation, or assessment may be valuable and may be the independently governed entity at the current pattern-use position. It cannot stand for a later physical, clinical, organizational, or learned change. Stop where the current direct basis supports value, then continue under the pattern that governs the next Work or relation.

    SoTA-Echoing

    Source or practice lineProblem-solving move taken hereAdoption and boundary
    Pattern-language practice: situation recognition, conditional solution, consequences, and neighboring-pattern compositionBegin with direct inspection of the full pattern rather than title matching, then use one conditional Solution to identify the first independently governed result and its direct basis, or stop when that basis is missing.Adopt the conditional result-or-stop logic. Reject recipe following, pattern-ID matching, and generic application-to-result inference as sufficient use.
    Jin, Bai, and Oulasvirta, Modeling Trial-and-Error Navigation With a Sequential Decision Model of Information Scent, arXiv:2603.11759 (2026)Make bounded inspection, wrong-turn recognition, and explicit return part of the ordinary use rather than assuming one perfect first selection.Adapt the navigation result to pattern use. The preprint does not decide FPF ontology, shortlist size, or whether records are needed.
    Current FPF A.10, B.3, E.18, E.18.NET, C.2.1, and G.11 evidence, assurance, TFS-local position, network, support-episteme, and currentness practicesKeep the result, its direct owner, governed relative object, category-correct direct basis, exact local positions, any separate receiving-use relation, and any current network reading addressable when another participant or system will rely on them later.Adapt conditionally through relianceBearing; reject universal trace production and universal cross-flow edges, and keep evidence, assurance, direct-relation, local-claim, network, and currentness claims with their governing patterns.
    Current FPF E.11, E.11.PUR, and A.15Separate public discovery, one selected-pattern use, recommendation or coordination, intended work, performed work, and entity inception.Adopt as the governing ontology for those boundaries. PUA adds the user-side use method and C.2.1 findings that cite, but do not replace, direct subject relations.

    The practical implication is direct: inspect enough to detect a wrong turn, record only what a named later use needs, and never infer a subject result from the existence of its trace.

    Conditional pattern use is the lineage anchor, not a claim that traditional pattern-language practice already supplies PUA's result and flow ontology. Recipe following, PatternID matching, and universal trace production are the common comparators; PUA rejects them because they respectively hide conditions, substitute names for inspection, or spend apparatus without a receiving reliance.

    The 2026 navigation study is a current preprint anchor rather than settled consensus. Reopen its wrong-turn and return adaptation when peer review, replication, or use evidence changes the observed value of inspection, memory, or backtracking. Reopen the ordinaryBounded and relianceBearing split when real receiving uses repeatedly lose needed distinctions or pay trace cost without later use. G.11 orchestrates that evidence and currentness; PUA changes the profile boundary or exact support relations.

    Relations

    • Builds on: E.11 for public practical-use guidance, E.8 for action-guiding pattern form, E.18 for each TFS-local position and local DesignRunTag, E.18.NET when independently identified TFS values form a network, direct subject owners for every cross-flow relation occurrence, A.6.P.WMR and A.6.RCD when its governor or direct claim cannot be recovered, A.15 for planning and work, C.2.1 for support epistemes, and A.6.5 for slot discipline.
    • Coordinates with: E.11.PUR for applicability, recommendation, and coordination; E.18.1 for accepted problem-to-work carry-through; E.22 and E.23 for evaluation and repeated improvement; G.11 for currentness orchestration; and each direct pattern that governs the selected result.
    • Returns to: E.11 when no direct pattern is yet selected, E.11.PUR when recommendation or ordering among several candidate uses is current, and the exact subject pattern when the result or work claim leaves PUA's boundary.

    E.11.PUA:End

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