FPF Reference

    C.30.TFS-REL:4.5 - Worked slices

    Preface node heading:c-30-tfs-rel-4-5-worked-slices:62651

    What this page is

    This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

    Methodology

    Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

    Content

    Functional architecture with a transformation-flow relation being claimed. A team says, "The functional architecture is this flow diagram." The repair is:

    functionalStructureViewRef: exact view episteme about required effects and dependencies
functionalElementClaimRefs?: not used; no filled functional-element claim is current
functionalBehaviorClaimRefs?: required-effect claim `authorize payment`
requiredOrDesiredEffectClaimRefs?: required-effect claim `authorize payment`
actualTransformationRefs?: not used; no A.3.4 actual change is claimed
selectedTransformationFlowStructureRefs: exact selected payment-authorization TFS
transformerSideFillerRefs?: not used
candidateBearerRefs?: not used
inputConditionRefs?: not used
outputConditionRefs?: not used
functionalPortRefs?: not used
transformationFlowStructureViewRef: exact description/view episteme about the selected E.18 structure, path, crossing, or flow valuation
transformationFlowStructureRef: TransformationFlowStructure@PaymentAuthorization
selectedPathOrSliceRefs: path slices used for the architecture claim
correspondenceClaimOrRelationRefs: bounded claim that the required effect corresponds to the flow path
nonAdmissibleUse:
  required effect as actual U.Transformation,
  flow diagram as functional architecture itself,
  selected transformation-flow structure as Work occurrence,
  mathematical graph description as evidence sufficiency,
  crossing as gate result,
  flow relation as project decision

    Filled use record:

    ArchitectureTransformationFlowStructureRelation:
architectureRelationOccurrenceRefs: exact obtaining CheckoutService architecture relation
architectureClaimRefs: bounded CheckoutService architecture claim when current
selectedArchitectureStructureRefs: exact selected request-handling and payment-authorization structure
architectureStructuralViewRefs: exact CheckoutRuntimeFlow view episteme
architectureDescriptionRefs: not used; durable description adequacy is not being evaluated here
functionalStructureViewRefs: exact CheckoutRequiredEffects view episteme
functionalElementClaimRefs: not used
functionalBehaviorClaimRefs: required-effect claim `authorize payment`
requiredOrDesiredEffectClaimRefs: required-effect claim `authorize payment`
actualTransformationRefs: not used
selectedTransformationFlowStructureRefs: TransformationFlowStructure@Checkout-v3
transformerSideFillerRefs: not used
candidateBearerRefs: not used
inputConditionRefs: not used
outputConditionRefs: not used
functionalPortRefs: not used
transformationFlowStructureViewRefs: exact PaymentAuthorizationPath description/view episteme
transformationFlowStructureRef: TransformationFlowStructure@Checkout-v3
selectedPathOrSliceRefs: PathSlice@request-to-payment-authorization
crossingBundleRefs: not used
flowValuationRefs: not used
mathematicalDescriptionRefs: not used
correspondenceClaimOrRelationRefs: claim that required effect `authorize payment` corresponds to the E.18 path slice; this is correspondence, not identity or actual change
sourcePublicationOrEditionRef: model or generated-graph edition when the flow relation was extracted from one
extractionOrProbeLocusRef: path-slice extraction or code-agent probe locus when current
relationObservationClassRef: observed, inferred, or unknown relation class when current
unexploredRegionRefs: not used
hiddenRelationStructureReturnCondition: reopen if mathematical-description edition, path slice, relation observation class, or required-effect declaration changes
admissibleUse: inspect whether the functional structure view depends on the E.18 path slice and whether an architecture split or correspondence claim is needed
nonAdmissibleUse: required effect as actual transformation; flow diagram as functional architecture itself; selected transformation-flow structure as Work occurrence; mathematical graph description as evidence sufficiency; crossing as gate result; flow relation as project decision

    Cooling countercase: a selected cooling-flow TFS and RequiredCoolingEffect-1 may fill the required-effect and correspondence fields while actualTransformationRefs stays empty. Only a later A.3.4 occurrence with Rack 7 as exact changed referent, fixed thermal boundary and conditions, actual 38 °C before / heat-removal during / 27 °C after facts, and Rack 7 continuity can fill that field. A separate realization predicate is still needed to relate the actual cooling to the requirement.

    Near miss: if the selected transformation-flow structure has no exact C.30-side architecture reference named by value, the case stays in [E.18](/generated/patterns/E.18). If the same sentence is a mathematical description, use [E.18.2](/generated/patterns/E.18.2); if it is a math-lens-use claim, use [C.29](/generated/patterns/C.29). If it is a Work log, evidence claim, gate decision, or benchmark result, that non-flow claim is governed by its governing pattern and this record keeps only the architecture-to-transformation-flow use.

    Pump-station flow relation. A plant team says, "the safety architecture is the bypass flow." C.30.TFS-REL applies only if the exact plant holon, its actual architecture relation or bounded architecture claim as current, selected control or material-flow structure, and E.18 selected bypass-flow structure are named. The bypass path may be architecture-relevant, but it is not an actual cooling/pumping transformation, safety proof, performed maintenance Work, gate passage, or release permission. The record names the plant architecture locus, selected E.18 path or crossing, hidden relation-structure return condition, and the one architecture move changed by the bypass relation.

    Supply-chain transformation-flow relation. A logistics architecture view may use an E.18 selected flow structure for supplier handoff, transport crossing, freshness window, and valuation. The exact subject holons, actual architecture relations when claimed, and selected supply-chain structures remain named; Work occurrences, contractual commitments, evidence, and gate decisions stay with their governing patterns.

    Neural-network dataflow change. Source labels such as attention block, SSM block, convolution block, memory mechanism, cache mechanism, and MoE expert-selection go through [C.30.STRAT](/generated/patterns/C.30.STRAT) unless the changed value is already recovered. C.30.TFS-REL applies only when the exact changed structure kind and transformation-flow relation are named. A benchmark, ablation, or pruning result may bear on a non-architecture claim named by value, but it does not make the flow relation an architecture decision, actual transformation, or evidence sufficiency by itself.

    Code-agent relation graph. A code-agent relation graph with IMPORTS, CALLS_API, REGISTRY_WIRES, or DATA_FLOWS_TO edges can be used for an architecture-to-transformation-flow relation only with the source publication or codebase edition, extraction or probe locus, relation observation class selected from {observed, inferred, unknown}, typed relation semantics, unexplored regions, and hidden relation-structure return condition when subsequent action relies on hidden distinctions. The graph, representation, file, and publication occurrence remain distinct from both the selected TFS and every direct relation occurrence.

    Last Updated: 2026-07-31 — upstream FPF commit 1eb56cd0 (github.com/ailev/FPF)