E.11.PUA:4.5 - Actual-result closure and receiving-use disposition
PUA introduces no actual-result relation and no universal actual-use relation. Keep two questions separate: what establishes, under the applicable identity or predicate rule, that the candidate result entity exists or the relation occurrence obtains; and what category-correct basis makes the readable result phrase true relative to the current Method, plan, dated Work, Transformation, evaluation, decision, or later-use object. One relation occurrence may answer both questions only when the result itself is that occurrence. When a named later use needs addressable closure, materialize a C.2.1 finding that states the result assertion, locates its defining or constraining rule content through the applicable ClaimGraph and pattern locator, and records the category-correct basis:
PatternUseResultClosureFinding@Context <: U.Episteme:
entityOfConcernRef: U.EntityRef, referencing the independently identified 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
resultPatternLocator: U.EntityRef, locating the exact FPF pattern episteme whose content defines or constrains the result assertion
resultRelativeToObjectRef: U.EntityRef
resultRelativeToObjectKindRef: U.KindRef
resultDirectBasisKind: directRelationOccurrence | operationApplicationBinding | localRelationBearingClaim
resultDirectBasisRef: U.EntityRef
resultDirectRelationOrBindingPatternLocator?: U.EntityRef, locating the exact FPF pattern episteme whose content defines or constrains the relation or binding
resultLocalClaimDerivationPatternLocator?: U.EntityRef, referencing A.6.RCD
resultLocalClaimBasePredicatePatternLocators[]?: U.EntityRef, each locating one exact FPF pattern episteme whose content defines a base predicate
resultFlowPosition: patternSelectionFlowResult | selectedPatternApplicationFlowResult | downstreamSubjectWorkFlowResult
resultBearingPathSliceId?: PathSliceId
resultBearingDesignRunTag?: DesignRunTag
closureBoundaryRef: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context
The three flow-position values are descriptive PUA positions, not kinds, relations, or occurrence identities. The finding’s claim graph names the result entity, its exact predicate, defining or constraining ClaimGraph, pattern locator, the 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 defining ClaimGraph. For an A.6.1 binding it names operation, application, argument or result binding, and its defining ClaimGraph. For an A.6.RCD local C.2.1 claim, the relation-or-binding locator is absent; the claim ref, polarity, substrate or constructor, base predicates, their ClaimGraph locators, participants, case facts, and any support or warrant required by the dependent use are recoverable, with the derivation-rule locator 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 the A.15.PROD branch needed by the closure: production-work participation, Work-attributed entity inception, or production completion. An inception claim requires independently identified dated Work, actual changes and the applicable identity rule. A completion claim keeps subject-state satisfaction separate from the governor that closes the production Work. A relation occurrence may first obtain through its direct predicate; an evaluation or decision becomes current under its exact subject assertion and defining ClaimGraph; 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 identified 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
realizedReceivingUseDirectRelationOrBindingPatternLocator?: U.EntityRef, locating the exact FPF pattern episteme whose content defines or constrains the realized-use relation or binding
realizedReceivingUseLocalClaimDerivationPatternLocator?: U.EntityRef, referencing A.6.RCD
realizedReceivingUseLocalClaimBasePredicatePatternLocators[]?: U.EntityRef, each locating one exact FPF pattern episteme whose content defines a base predicate
intendedUseClaimRef?: U.EpistemeRef, referencing the exact claim that makes the intended continuation current
intendedReceivingGovernedObjectKindRef?: U.KindRef
intendedReceivingUseDescriptionRef?: U.EpistemeRef
receivingUseRealizationConditionRef?: U.EpistemeRef, referencing one PatternUseBoundaryCondition@Context
In the realized state, the later 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 pattern locator from the A.6.RCD derivation locator and the direct pattern locators for the local claim’s base predicates. The claim graph exposes the exact participants and facts. In intendedNotYetRealized, the intended claim, 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 later 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 direct relation occurrence connecting their participants and its applicable predicate, and keep the result’s kind unchanged. With no direct relation kind or predicate, return missing-governor; with a predicate 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.