C.30.TFS-REL:4.4a - Architecture use of a transformation-flow structure network
Preface node
heading:c-30-tfs-rel-4-4a-architecture-use-of-a-transformation-flow-structure-network:71519
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
First recover the independently selected E.18.NET network and the architecture question. For one named holon, distinguish an obtaining architecture relation whose selected structure is that exact network from a bounded claim that does not assert such an occurrence. For a question spanning several named holons without a grounded containing holon, use the inter-holon branch. Select exactly one branch from those facts.
- Named containing-holon use. Set
networkArchitectureUseBranch=namedContainingHolon. Name exactly onecontainingHolonRefand one actualcontainingArchitectureRelationRefwhose selected structure is the same exact network.containingArchitectureClaimRefis optional claim/trace content. Keep all participating arrays andnoNetworkBearerHolonAssertedabsent. Member TFS values and their Work, valuations, boundaries, actual transformations, and direct relations remain independently governed. - Explicit inter-holon use. Set
networkArchitectureUseBranch=explicitInterHolon. Put at least two exact distinct holons inparticipatingHolonRefs[]. Add exactly the actualparticipatingArchitectureRelationRefs[]and boundedparticipatingArchitectureClaimRefs[]on which this question relies; a network member whose architecture is not used by the question stays outside those arrays. Keep all containing fields absent and setnoNetworkBearerHolonAsserted=true. This states one architecture-use question spanning named holons; it does not invent a containing holon, architecture relation, or characteristic bearer whose identity is the network. - Single-holon claim use. Set
networkArchitectureUseBranch=singleHolonClaim. Name one exact C.30ArchitectureClaimQ inarchitectureClaimRefs; its content names the described holon H and the same selected network N. Preserve Q'sdoesNotObtain,unresolved, orcandidateOrExpectedOnlydisposition and its scope, reference scheme, and supporting or missing basis. Keep the containing fields and participating arrays absent; setnoNetworkBearerHolonAsserted=true. Use N's admitted positions and relations to inspect the bounded architecture question. Keep the resulting claim or question with its basis. UseadmissibleUseandstopOrReturnConditionto state what may be done with it and what must be recovered before stronger reliance. An unavailable fact remains unknown; a negative claim needs its own C.30 basis. An architecture use that relies on an actual R(H,N) belongs in the containing-holon branch; retaining Q does not supply that occurrence.
Every other populated architecture-side reference must agree with the selected branch. In namedContainingHolon, each value in selectedArchitectureStructureRefs belongs to the containing architecture relation's selected structure route, and each structural view, architecture description, functional structure view, or architecture claim used by this record traces to the same exact containing holon and relation. In singleHolonClaim, each reference traces to H or Q and retains its own actual or modal status; an independently grounded current relation R(H,S) used for comparison does not establish R(H,N). In explicitInterHolon, each such reference traces to one named participating holon and, when actual, its exact architecture relation; a singular reference names only that participant and does not imply a containing architecture. If a reference depends on another holon or architecture relation, add it only when the current question actually relies on it, or use a separate record.
The branches are mutually exclusive. When transformationFlowStructureNetworkRef is absent, networkCrossFlowRelationRowRefs[] and all network branch fields are absent. A network ref without one complete branch is not ready for architecture use. When the record also names a path, slice, crossing, valuation, required effect, or actual transformation, bind it to the exact member TFS and the local positions, participants, or bindings that identify that value. When it names a network-aware unfolding, the E.18.3 substrate branch must name the same exact network and preserve its admitted position mappings, while selectedCGUSRef continues to name the separate A.22-selected CGUS. The network ref does not lift member-local values into network-global state.
Use networkCrossFlowRelationRowRefs[] only for E.18.NET-owned composite locators. Each locator's current containing record must describe the same exact selected network, and the direct occurrence plus complete ordered endpoint-binding identity must resolve exactly one nested row. Zero matches, several matches, or a record for a different network stop this architecture use. The locator identifies the row; it neither creates the relation occurrence nor changes its direct governor.
For every maintainability, capability, responsibility, production, safety, or other architecture-characteristic claim made or used by this record, name the exact holon, actual architecture relation, selected structure, description/view episteme, bounded claim, or other bearer governed by C.30 or the characteristic's direct owner. A network may have selected structural facts—members, relations, recursion, or exposed positions—but those facts do not make an unnamed network the bearer of holon characteristics, agency, Work, production, required effects, or actual transformations.
A network diagram, member graph, mathematical description, publication, or TransformationFlowStructureNetworkRecord establishes none of these architecture uses and does not enter architecture identity. It may represent, describe, or publish the selected network only under its direct representation, description, or publication pattern.
Named containing-holon case. Exact holon ManufacturingPlatform-7 has one obtaining architecture relation whose selected structure is the exact product-development/production-system-change network. C.30.TFS-REL may use that network to localize an architecture change while each member TFS, production relation, Work occurrence, and actual transformation keeps its own owner.
Explicit inter-holon case. Exact supplier holon and exact plant holon use one selected E.18.NET-conforming supply-linked TFS network to inspect a cross-company dependency. Both appear in participatingHolonRefs[], with only the actual architecture relations and claims the question uses in their corresponding arrays. No containing supply-chain holon has been grounded, so noNetworkBearerHolonAsserted=true. The network is not called the architecture of an unnamed enterprise.
Single-holon claim case. N is an independently selected development/production network. Q asks whether N organizes exact ManufacturingPlatform-7; the available account leaves one constituent's inclusion in that holon unknown. Keep Q unresolved and inspect N's admitted cross-member dependency to identify which allocation or boundary fact must be recovered. A proposal to use N instead keeps candidateOrExpectedOnly and may support a bounded comparison. If a sufficient C.30 basis establishes that N does not organize this holon, retain doesNotObtain; missing facts alone do not support that result. These uses retain a useful architecture question without an actual R(H,N). If N's own cross-member relation or endpoint binding is missing, stop at E.18.NET's proposed description or selection blocker instead of naming a selected N. A detached account carries Q's disposition, H, N, basis and usable return; the bare phrase “N is the platform architecture” would lose the distinction on which this use depends.
Last Updated: 2026-10-12 — upstream FPF commit f2bc67dd (github.com/ailev/FPF)