FPF Reference

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

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

    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: required effects and dependencies
functionalElementRefs?: not used; no selected `FunctionalElement@Context` is being claimed
functionalBehaviorRefs?: required effect `authorize payment`
transformerSideFillerRefs?: not used
candidateBearerRefs?: not used
inputConditionRefs?: not used
outputConditionRefs?: not used
functionalPortRefs?: not used
transformationFlowStructureViewRef: selected E.18 transformation-flow structure, path structure, crossing structure, or flow-valuation structure
transformationFlowStructureRef: TransformationFlowStructure@PaymentAuthorization
selectedPathOrSliceRefs: path slices used for the architecture claim
correspondenceRefs: functional effect to flow path relation
nonAdmissibleUse:
  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 relation record:

    ArchitectureTransformationFlowStructureRelation@Context:
architectureClaimRef: ArchitectureOf@CheckoutServiceContext
selectedArchitectureStructureRefs: selected request-handling and payment-authorization flow structure
architectureStructuralViewRef: ArchitectureStructuralView@CheckoutRuntimeFlow
architectureDescriptionRef: not used; the durable architecture description is not being evaluated here
functionalStructureViewRef: FunctionalStructureView@CheckoutRequiredEffects
functionalElementRefs: not used
functionalBehaviorRefs: required effect `authorize payment`
transformerSideFillerRefs: not used
candidateBearerRefs: not used
inputConditionRefs: not used
outputConditionRefs: not used
functionalPortRefs: not used
transformationFlowStructureViewRef: TransformationFlowStructureView@PaymentAuthorizationPath
transformationFlowStructureRef: TransformationFlowStructure@Checkout-v3
selectedPathOrSliceRefs: PathSlice@request-to-payment-authorization
crossingBundleRefs: not used
flowValuationRefs: not used
mathematicalDescriptionRefs: not used
correspondenceRefs: required effect `authorize payment` corresponds to the E.18 path slice; this is correspondence, not identity
sourceReturnCondition: reopen if mathematical-description edition, path slice, source observation class, or required-effect declaration changes
admissibleUse: inspect whether the functional structure view depends on the E.18 path slice being used and whether an architecture split or correspondence note is needed
nonAdmissibleUse: 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

    Near miss: if the selected transformation-flow structure has no 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 relation keeps only the architecture-to-transformation-flow relation.

    Pump-station flow relation. A plant team says, "the safety architecture is the bypass flow." C.30.TFS-REL applies only if the plant ArchitectureOf@Context, 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 safety proof, performed maintenance work, gate passage, or release permission. The relation record names the plant architecture locus, selected E.18 path or crossing, source-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 architecture claim remains about selected supply-chain structure; 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 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 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 source edition, a source observation class selected from {observed, inferred, unknown}, typed relation semantics, unexplored regions, and source-return condition when subsequent action relies on hidden distinctions.

    Last Updated: 2026-06-17 — upstream FPF commit 646b0b9b (github.com/ailev/FPF)