#Network of Transformation-Flow Structures

E.18.NET · Stable · Structural pattern for ontic relations (E) · Normative unless explicitly marked informative · 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.

Tech-name: TransformationFlowStructureNetwork Plain-name: Network of transformation-flow structures Type: Structural pattern for ontic relations (E) Status: Stable Normativity: Normative unless explicitly marked informative

Use this pattern when one engineering question depends on two or more independently identified transformation-flow structures, or on nested networks of them, and at least one exact relation connects positions across their boundaries. Typical situations include a toolchain that builds another tool, a production system related to the product it helps produce, or an operating flow whose observation returns to a separate development flow.

#Relations

#Content

#Problem frame — intent and first useful result

Use this pattern when one engineering question depends on two or more independently identified transformation-flow structures, or on nested networks of them, and at least one exact relation connects positions across their boundaries. Typical situations include a toolchain that builds another tool, a production system related to the product it helps produce, or an operating flow whose observation returns to a separate development flow.

Start with the practical choice, not with a graph:

1. decide whether the case is several valuations of one flow structure, an internal portion of one flow structure, or a network of independent flow structures;
2. identify each candidate member independently;
3. name the exact obtaining relation occurrences that connect positions in different members;
4. select only the members, relations, boundary exposures, and constraints needed for the current question; and
5. return one exact network reference, or stop at the proposed description and name the absent identity discriminator or exact relation-status result.

The first useful result is therefore small. It is either:

selectedNetworkRef: one exact TransformationFlowStructureNetwork
directMemberRefs[]: at least two refs to independently identified TransformationFlowStructure or E.18.NET-conforming TransformationFlowStructureNetwork values
selectedCrossFlowRelationOccurrenceRefs[]: exact selected obtaining relations under their direct patterns
selectedNetworkConstraintRefs[]: exact applied endpoint, boundary-exposure, and acyclic direct-member constraints
networkUseFrame:
  questionOrAction: the concrete question answered or action enabled
  forbiddenOverread: what this selection does not establish
returnCondition: the first member, relation, constraint, or use-frame change that reopens selection

or an exact stop such as:

proposedNetworkDescriptionRef: current diagram or record
blockedClaim: "the compiler-building flow produces the compiler-use flow input"
directRelationStatus:
  missing-governor: no direct relation kind/predicate governs these participants and use
  unresolved-grounding: a governor exists but current facts do not decide its predicate
  false-predicate: current facts fail the predicate, so no occurrence fills the network
  missing-endpoint-binding: an occurrence obtains but one required position binding is absent
result: exactly one applicable status above

If any directMemberRefs[], selectedCrossFlowRelationOccurrenceRefs[], selectedNetworkConstraintRefs[], or networkUseFrame value is absent or unresolved, keep proposedNetworkDescriptionRef and name that exact missing discriminator. Use directRelationStatus only for the relation branch shown above; a missing member, applied constraint, or use frame keeps its own stop. Do not assert selectedNetworkRef until all four discriminators are recoverable.

Do not use E.18.NET merely because one flow branches, contains a detailed portion, has several valuations, or is drawn as a network. Use E.18 for one selected TransformationFlowStructure, its valuations and internal U.Transfer relations; use E.18's SubflowRef for one parent-relative internal portion. Use E.18.2 when the current object is a graph, wiring diagram, tuple, category-theory expression, or another mathematical description. Use A.22.CGUS and E.18.3 when the current object is an admitted demonstrative traversal rather than the network itself.

#Problem

Teams routinely connect flows that have different governed objects, Work occurrences, architecture boundaries, valuation state, and change cadence. A development flow produces or changes a tool; another flow uses the tool; another evaluates the use; feedback returns to development. A manufacturing system is changed through one flow while products are made through another. A compiler is built by one toolchain and then participates in a later build.

A single picture can hide three different ontic answers:

When the third case is treated as one giant TFS, local state appears global, an internal U.Transfer is asked to mean production, use, evaluation, feedback, correspondence, and dependency, and a change in one member appears to reidentify everything. When the first or second case is over-split into a network, the model invents members and relations that the engineering situation does not need.

#Forces

#Solution

#Select a dependent non-agentive structure

TransformationFlowStructureNetwork@Context is a dependent, non-agentive specialization of U.Structure owned by E.18.NET and selected through the A.22 identity law. It is not a root U-kind, acting system, holon, workflow, graph, record, publication, FlowValuation, WorkPlan, or performed Work. The @Context suffix qualifies retrieval and use; it adds no identity discriminator.

For N : TransformationFlowStructureNetwork, recover exactly:

StructureIdentity(N) = <
  directMemberRefs[],
  selectedCrossFlowRelationOccurrenceRefs[],
  selectedNetworkConstraintRefs[],
  networkUseFrame
>

The four field names have the same meanings as in the first-use result: exact direct members, exact selected obtaining cross-flow occurrence refs, exact applied network constraints, and one concrete use frame. returnCondition is not a fifth identity discriminator; it records when the current use must return and reselect.

The direct-member set contains at least two exact values. Each member is one independently identified TransformationFlowStructure or one independently identified E.18.NET-conforming TransformationFlowStructureNetwork. At least one selected relation occurrence binds positions in different direct members or in different leaf TFS members reached through them. The use frame says what the practitioner will decide or do with this selected organization and names the forbidden overread. “Current use”, “appropriate network”, and the title of a diagram are not use frames.

A row in a record does not create a member or make membership obtain. This profile needs no generic networkMemberOf relation. If a future receiver needs a separately re-identifiable world-side membership occurrence, reopen that relation question under A.6.RCD; do not infer it from the member list.

#Reidentification and change locality

Replacing a direct member, selected relation occurrence, applied endpoint or exposure constraint, acyclicity constraint, or named selection-use frame identifies another selected network. Reidentifying a nested member reopens every parent network that selects that exact member.

Changing only a name, reference designator, record edition, graph layout, mathematical description, publication, selecting system, selection Work, evidence item, FlowValuation, PathSliceId, or local DesignRunTag leaves the network unchanged when the four A.22 discriminators still resolve to the same values.

#Recurse through finite member paths

The selected direct-member nesting is acyclic. No direct or transitive member path from a network resolves back to that network, and every member path used by a reference is finite. This permits build-the-builder and supply-network recursion without inventing level-1, level-2, or level-3 network kinds.

Cycles among selected cross-flow relation occurrences remain possible when their direct governing patterns permit them. Feedback from operation or evaluation to development is therefore compatible with acyclic membership: the cycle is in the subject relations, not in network containment.

E.18 owns the complete FlowPositionRef identity. Import that tuple unchanged; E.18.NET owns only the ExposedFlowPositionRef extension needed for a boundary position reached through one finite member path:

FlowPositionRef := <
  transformationFlowStructureRef,
  localFlowPositionId
>

ExposedFlowPositionRef := <
  networkStructureRef,
  memberPath[],
  leafFlowPositionRef
>

Every hop in memberPath[] resolves through the preceding network's direct members. Its final member is the TFS named by leafFlowPositionRef. When the path crosses a nested network, the leaf position must be one of the boundary positions that nested network exposes for the current higher-level use. Two different paths to the same leaf TFS position are two different exposures.

The parent network may compose the finite path and use the exposed boundary. It may not copy or silently flatten the nested member's internal structure. FlowValuation, PathSliceId, actual fillings, and DesignRunTag qualify use of a position; they are not part of FlowPositionRef or ExposedFlowPositionRef identity.

#Keep valuation and design/run state leaf-local

Each positionBindingRef cites an already governed E.18 position/valuation binding or a declaration-local binding whose direct pattern supplies participant meanings, value kind, and reference mode. A network introduces no universal cross-flow value kind.

DesignRunTag belongs to one exact position binding inside one exact leaf TFS. A network has no network-level FlowValuation, global design/run ladder, or automatic crossing that changes the carried entity's kind. If the same episteme fills a run-side position in a development TFS and a design-side position in a target-system-change TFS, record two local bindings and the exact relation between them.

#Preserve the direct cross-flow relations

For every relation used by the network, recover:

• the exact obtaining occurrence;
• the exact relation kind;
• the direct governing pattern;
• the complete signature and participant order;
• the endpoint member and position binding for every participant; and
• direction only when the direct relation has direction.

An n-ary relation remains n-ary. Do not decompose it into invented binary arrows. A row, edge label, shared entity, temporal adjacency, operation result, plan row, or graph connection never makes the relation obtain.

U.Transfer remains E.18's internal relation kind for one TFS. It is not a universal relation between network members. For any production, use, participation, evaluation, correspondence, feedback, dependency, supply, or other cross-flow relation, first apply its direct owner: the relation kind must have passed relation-kind admission, that owner must supply the direct predicate and applicability, and current case facts or constituting history must satisfy the predicate affirmatively. Only then does one world-side occurrence obtain. Its identity remains under the direct relation owner and A.6.REL when a receiver consumes occurrence identity. The network selects only the exact already-obtaining occurrence ref.

If no direct relation kind and predicate govern the intended participants and use, return missing-governor. If the governor exists but current facts do not decide the predicate, keep a proposed network description and return the exact missing facts or information-sufficiency boundary. If the predicate is false, no occurrence fills the network. If the occurrence obtains but an endpoint position binding is missing, return that missing binding. A row, graph edge, or episteme neither admits the kind nor creates the occurrence. In none of these branches substitute creates, produces, uses, input, output, result, handoff, or transfer as a generic edge.

#Record the network without replacing it

When the selected answer must survive beyond the immediate work, describe it with a separate C.2.1 episteme:

TransformationFlowStructureNetworkRecord@Context <: U.Episteme:
  entityOfConcernRef: one exact TransformationFlowStructureNetwork ref
  entityOfConcernKindRef: TransformationFlowStructureNetwork
  claimScope?: U.ClaimScope
  effectiveReferenceScheme: U.ReferenceScheme
  directMemberRows[]:
    memberRef: TransformationFlowStructureRef | TransformationFlowStructureNetworkRef
  exposedFlowPositionRows[]:
    exposedFlowPositionRef: ExposedFlowPositionRef
    memberPath[]
    leafTransformationFlowStructureRef
    leafFlowPositionRef
  crossFlowRelationRows[]:
    exactRelationOccurrenceRef: U.RelationRef
    exactRelationKindRef: U.KindRef
    governingPatternRef: U.MethodDescriptionRef
    endpointRows[]:
      relationParticipantPositionRef
      memberRef
      flowPositionRef: FlowPositionRef | ExposedFlowPositionRef
      positionBindingRef
  architectureCorrespondenceRowRefs[]?: C.32.CONWAY episteme refs
  selectedNetworkConstraintRefs[]
  networkUseFrame
  preservedNetworkStructure
  lostOrHiddenNetworkStructure
  returnCondition

The record describes the network; it is not the network. Its member and relation rows cite objects that already exist and occurrences that already obtain. An architecture-correspondence row is a qualified reading only. It contributes no member or selected cross-flow relation unless an exact separately grounded relation occurrence and endpoint bindings also satisfy the network identity.

E.18.NET owns this composite locator for one nested cross-flow row:

NetworkCrossFlowRelationRowRef := <
  transformationFlowStructureNetworkRecordRef: U.EpistemeRef, referencing one exact current TransformationFlowStructureNetworkRecord@Context edition,
  exactRelationOccurrenceRef: U.RelationRef,
  orderedEndpointBindingIdentity[]: <
    relationParticipantPositionRef,
    memberRef,
    flowPositionRef: FlowPositionRef | ExposedFlowPositionRef,
    positionBindingRef
  >
>

Resolve the record ref first, then match crossFlowRelationRows[] by the exact occurrence ref and the complete ordered endpoint-binding identity. Exactly one row must match. Zero matches or several matches leave the locator unresolved and stop that consumer; never fall back to the containing record, the occurrence alone, or a prose pointer. NetworkCrossFlowRelationRowRef is a reference shape, not a U-kind, episteme, or relation occurrence. Its U.EpistemeRef targets the containing record, never the nested row.

#Keep descriptions, demonstrations, architecture, and Work outside identity

Use E.18.2 for a graph, hypergraph, network expression, wiring diagram, category-theory object, tuple, fold, or other mathematical description of the selected network. State what that description preserves and loses. A rendered graph or publication face remains under E.17 and C.29 as applicable.

Use A.22.CGUS and E.18.3 for an admitted network-aware DemonstrativeUnfoldingSlice@Context. Its finite paths must map to already admitted included positions, its cross-flow relations must cite admitted exact relation-reference epistemes, and its tags remain in leaf-local bindings. The slice demonstrates one traversal; it is neither the network nor an actual trajectory, WorkPlan, or Work occurrence.

Use C.30.TFS-REL when architecture uses the selected network. Name one exact containing holon whose ArchitectureOf@Context selects the network, or explicitly state the inter-holon use and its participating architecture claims without inventing a bearer. Use C.32.CONWAY only for its one-pair architecture-influence reading; the pair neither acts nor becomes the network.

Only admitted systems perform Work. Selecting a network, writing its record, or drawing its graph is not performance by the network. Selection method, selecting system, dated selection Work, result episteme, and accountable decision remain under A.3, A.12, A.15, C.2.1, and C.11 as applicable.

#Archetypal Grounding — worked cases

#Same surface vocabulary, different ontic answers

Several valuations of one TFS. A cooling-loop review compares nominal-load and emergency-load valuations of the same exact cooling-loop TransformationFlowStructure. Both valuations use the same structure positions and internal U.Transfer occurrences. The load value, path slice, and local tags differ; the TFS identity does not. E.18.NET is not used.

Internal coffee subflow. A coffee-brewing TFS exposes a preparation portion containing grinding, dosing, and wetting positions plus their parent-internal U.Transfer occurrences. Its entry and exit remain positions of the brewing TFS. The practitioner uses E.18's SubflowRef; no second TFS or network is created.

Independent network. A roastery-production TFS and a café-brewing TFS have separate governed objects, Work occurrences, valuation boundaries, and architecture change cadence. The direct supply owner has an admitted relation kind, supplies the predicate and applicability, and the current delivery-and-acceptance facts satisfy that predicate for a dispatch position in the first and an accepted-stock position in the second. For ordinary first use, fill the selected network directly:

selectedNetworkRef: RoasteryCafeSupplyNetwork@CoffeeService
directMemberRefs[]:
  - RoasteryProductionTFS@Dispatch
  - CafeBrewingTFS@AcceptedStock
selectedCrossFlowRelationOccurrenceRefs[]:
  - SupplyOccurrence@Lot24Dispatch-to-CafeAcceptance
selectedNetworkConstraintRefs[]:
  - SupplyEndpointConstraint@Dispatch-to-AcceptedStock
  - SelectedExposureConstraint@RoasteryDispatch-and-CafeAcceptedStock
  - AcyclicDirectMemberConstraint@RoasteryCafe
networkUseFrame:
  questionOrAction: decide which accepted stock can enter the coffee-service brewing flow
  forbiddenOverread: shared coffee does not make both members one TFS or make supply a generic edge
returnCondition: either member, the supply occurrence, an endpoint or exposure, acyclicity, or the coffee-service question changes

This filled basis is enough for the immediate selection; it is not a TransformationFlowStructureNetworkRecord@Context. Create that separate descriptive record only when the result must survive the current work. With no direct supply kind or predicate, the same diagram remains a proposed description with missing-governor. With an applicable governor but undecided facts, it remains proposed with the missing grounding or information-sufficiency boundary. With a false predicate, no supply occurrence fills the network. With a satisfied predicate but a missing endpoint binding, it remains proposed with that binding named.

#Recursive build-the-builder

A project distinguishes five independently identified flow structures:

1. a compiler-source-change TFS;
2. a bootstrap-compiler build TFS;
3. an application-build TFS using the admitted compiler artifact through a directly governed project relation;
4. a release-assurance TFS that evaluates the built application through its own direct relation; and
5. a deployment-and-operation TFS whose exact software-use relation is governed separately.

It then selects four nested networks. CompilerBuildNetwork has members 1 and 2. ApplicationCompilerUseNetwork has that independently identified network and member 3. ReleaseAssuranceNetwork has ApplicationCompilerUseNetwork and member 4. DeliveryOperationNetwork has ReleaseAssuranceNetwork and member 5. Every selection has at least two direct members and its own exact obtaining cross-member relation occurrence and endpoint bindings.

The bootstrap compiler result is exposed from the outer delivery network through this exact finite path:

ExposedFlowPositionRef:
  networkStructureRef: DeliveryOperationNetwork
  memberPath[]:
    - ReleaseAssuranceNetwork
    - ApplicationCompilerUseNetwork
    - CompilerBuildNetwork
    - BootstrapCompilerBuildTFS
  leafFlowPositionRef:
    transformationFlowStructureRef: BootstrapCompilerBuildTFS
    localFlowPositionId: ExecutableCompilerResult

Each path entry is a direct member of the preceding network, the final entry is the TFS named by leafFlowPositionRef, and no network repeats. This is one four-entry member path, not four numbered network kinds. “Builds”, “uses”, “evaluates”, and “delivers” remain ordinary cues until every selected cross-member link resolves to its exact direct relation kind, participants, obtaining occurrence, and endpoint bindings.

#N-ary relation and feedback cycle

A manufacturing release relation has three participants under one direct domain pattern: one product-definition position in a development TFS, one equipment-readiness position in a production-system-change TFS, and one release-condition position in an assurance TFS. Its network row keeps the three participants and their order. It is not replaced by three unlabeled arrows.

Later, an exact use-observation relation connects an operating TFS position back to a development TFS position. The relation occurrences form a feedback cycle, while the selected direct-member nesting remains acyclic. The feedback does not make the operating TFS a member of itself and does not turn observation into development Work.

#Architecture and demonstrative reading

For one containing product-development holon, a current ArchitectureOf@Context claim may select the network among its structures. If the selected members belong to separately named holons and no containing bearer is grounded, record the use as inter-holon and name the participating architecture claims. Do not invent one system that contains them merely to fill the architecture field.

A teaching mantra may show a finite admitted dependency slice through the network. The slice uses only the network locator family, cites admitted positions and exact relation-reference epistemes, and keeps omissions and return visible. It does not prescribe project work order and does not make the displayed path the whole network.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for uses of this pattern.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Adoption test: use E.18.NET only when the current question needs independently identified members and at least one exact relation across their boundaries. If one TFS or one parent-relative SubflowRef answers the question, the added network, endpoint, and member-path apparatus buys nothing and stays absent.

#Rationale and naming

The selected head preserves the established TransformationFlowStructure name, says that the members are structures rather than valuations, and supports recursion without fixed levels. The shorter English cue “transformation-flow network” and Russian cue “сеть потоков преобразований” are retrieval wording only after the governed value is clear.

Mint vs reuse: E.18.NET mints the durable names TransformationFlowStructureNetwork, TransformationFlowStructureNetworkRecord@Context, ExposedFlowPositionRef, and NetworkCrossFlowRelationRowRef for the governed value family, separate description episteme, and two pattern-owned reference shapes defined here. It reuses U.Structure, U.Episteme, TransformationFlowStructure, FlowPositionRef, relation kinds, and relation occurrences without changing their meanings; labels, records, and references create none of those values.

NameCard:
  NameCardId: NC-TRANSFORMATION-FLOW-STRUCTURE-NETWORK
  GovernedValueRef: TransformationFlowStructureNetwork@Context <: U.Structure
  GoverningPatternRef: E.18.NET
  ReferenceScheme: FPFCoreReferenceScheme
  LocalSenseRef: recursive selected organization over independently identified TransformationFlowStructure or TransformationFlowStructureNetwork values and exact cross-flow relation occurrences, with member boundaries and locally exposed positions preserved
  TechLabel: TransformationFlowStructureNetwork
  PlainLabel: network of transformation-flow structures
  CandidateSet: TransformationFlowStructureNetwork; TransformationFlowNetwork; CrossFlowRelationStructure; TransformationFlowDependencyStructure; CoupledTransformationFlowStructure; FlowOfFlows; CreatorGraph; CreationStructure
  RejectedCandidates: TransformationFlowNetwork can mean one network-shaped TFS; CrossFlowRelationStructure hides the transformation-flow use; TransformationFlowDependencyStructure narrows to one projection; CoupledTransformationFlowStructure suggests one merged TFS; FlowOfFlows conflicts with FlowValuation; CreatorGraph confuses the ontic structure with a graph and narrows change to creation; CreationStructure excludes operation, repair, modification, and reuse
  SelectionRationale: preserve the established TransformationFlowStructure head, make structures rather than valuations the members, and permit recursive membership without numbered levels
  LineageEntries: flow-of-flows and creator-graph examples remain retrieval lineage for the stress cases; fixed two-level and one-giant-flow ontic readings are retired
  RefreshCondition: reopen if repeated use cannot distinguish one TFS with several valuations, one subflow, and a recursive network of independently identified TFS values

#SoTA-Echoing

Each line below is inherited only while the cited current owner keeps both the named body decision and the named source-use row for its declared use. E.18.NET relies on that owner's currentness decision; it does not independently turn the cited literature or tool practice into current authority. When one owner row changes, reopen only the affected line here.

For the working reader, these lines support the boundary already exercised in the worked cases in sections 5.1–5.4: select a network only from independently identified members and exact relations, keep positions and state local to their leaf TFS, treat graphs as descriptions, and let a demonstrative path cite only already admitted positions and relation references.

The F.18 NameCard entries flow-of-flows and creator-graph remain naming and stress-example lineage only; they authorize no current ontology or practice claim. A new need for cyclic member identity, a separately re-identifiable membership occurrence, or cross-flow semantics that cannot preserve the direct relation and its endpoints reopens the E.18.NET architecture decision itself, not the source-currentness status of every row above.

#Relations

Builds on: A.22 for selected-structure identity and non-agentivity; E.18 for one TFS, internal U.Transfer, FlowPositionRef, valuations, paths, slices, and local state; A.6.REL, A.6.RCD, and A.6.P.WMR for exact relation recovery and missing-governor; C.2.1 for the optional descriptive record; and F.18 for the stable local name.

Coordinates with: E.18.2 and C.29 for mathematical descriptions; A.22.CGUS and E.18.3 for admitted demonstrative slices; C.30.TFS-REL for architecture use; C.32.CONWAY for one qualified architecture-influence pair; A.3.4, A.12, and the A.15 family for actual transformation, acting systems, Work, production, and work-to-change claims; E.17 for publication; and E.11.PUA for first-entry recognition.

Does not replace: the direct pattern that governs any selected production, use, participation, evaluation, feedback, dependency, correspondence, supply, evidence, assurance, gate, decision, causal, or work relation. E.18.NET selects already obtaining occurrences for one network use; it does not mint their kinds or make them obtain.

#E.18.NET:End

Last Updated: 2026-07-28 — this section last modified in upstream FPF commit 17edd955 (github.com/ailev/FPF)