#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 subject 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 local positions in different members—for example one position concerned with design work and another with production, verification, or later operation—record each leaf-local binding and the exact directly governed relation between them. Those ordinary member descriptions create no fixed TFS taxonomy or lifecycle phase.

#Preserve the direct cross-flow relations

For every relation used by the network, recover:

• the exact obtaining occurrence;
• the exact relation kind;
• the subject 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 recover its exact subject predicate and defining ClaimGraph: the relation kind must have passed relation-kind admission, and current case facts or constituting history must satisfy the predicate affirmatively. Only then does one world-side occurrence obtain. Its identity remains fixed by that exact occurrence-identity rule and A.6.REL when a named use 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
    relationFunctionClaimRef: 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.

#Project system-of-interest and recursive build-the-builder

For one project question, practitioners ask which independently identified flow structures must be considered together to connect production and later operation of the project system-of-interest, and which builder branches must also be visible. The actual project remains composite U.Work; the selected network is a non-agentive U.Structure. Project designation, U.System identity, a role interpretation, and any assignment remain separate.

For a compiler-and-application use, practitioners independently identify five TFS values by the questions they answer:

1. a TFS whose loci bind the compiler-edition preparation and directly governed source-use facts needed by the build;
2. a TFS whose loci bind Work and changes of pre-existing build substrates plus production and identity-inception claims for one bootstrap compiler;
3. a TFS whose loci bind application-production Work and the exact use of that admitted compiler;
4. a TFS selected for release-assurance questions; and
5. a TFS selected for deployment and operation after the application system exists.

These descriptions are not TFS kinds or lifecycle phases. No transformation of a not-yet-existing compiler or application is asserted. Each TFS, Work occurrence, change of a continuing referent, production claim, identity-inception claim, completion claim, role assignment, and later operation/use fact keeps its subject pattern.

In this worked use, CompilerArchitectureTeam-1 : U.System performs dated CompilerNetworkSelectionWork-5 : U.Work under obtaining CompilerNetworkSelectionAssignment-5; the separately identified result episteme records the accountable selection decision. During that Work the team selects nested networks only after exact cross-member relations obtain and every endpoint is bound. CompilerRealizationNetwork selects members 1 and 2 through the exact source/use, production, or other admitted occurrences needed by that use. ApplicationCompilerUseNetwork selects that network and member 3 through the exact compiler-input or operation-application occurrence supplied by its subject pattern. ReleaseAssuranceNetwork adds member 4 through its exact evaluation or assurance occurrence. DeliveryOperationNetwork adds member 5 through its exact deployment, participation, application, or use occurrence. The names are local designators; every selection still needs direct members, obtaining relation occurrences, applied constraints, and its own networkUseFrame. The project Work, network, result episteme, team, assignment, and selection Work remain different objects.

A compiler-production case can close on separately grounded identity inception, production completion or readiness, evidence, and decision while naming the application-build position as the downstream use outside that closed case. Project-level reasoning continues into the member where the compiler later participates. The same joint-selection question recurs for a builder system: select the TFS in which that admitted builder performs exact Work together with the independently identified TFS or nested network concerning production and identity inception of the builder, or its later change after it exists. Shared identity creates no edge; use exact production, inception, participation, application, use, or other directly governed occurrences and endpoint bindings.

The bootstrap compiler result is exposed from the outer network through one finite member path:

ExposedFlowPositionRef:
  networkStructureRef: DeliveryOperationNetwork
  memberPath[]:
    - ReleaseAssuranceNetwork
    - ApplicationCompilerUseNetwork
    - CompilerRealizationNetwork
    - 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. FlowValuation, path slices, and DesignRunTag remain leaf-local. “Builds”, “uses”, “evaluates”, and “delivers” are ordinary cues until each link resolves to an admitted relation kind, complete participant signature, obtaining occurrence, and endpoint bindings.

Before these identities and relations are grounded, A.1.STM may show the dependency only as a Plain provisional long-mantra map and must name the missing member, governor, false or unresolved predicate, occurrence, or binding. It is not yet an E.18.NET selection. Once the network is admitted, a separate A.22.CGUS demonstrative slice may traverse admitted positions and relation-reference epistemes; it remains a demonstration, not the project, network, case, or Work order.

#N-ary relation and feedback cycle

A manufacturing release relation has three participants under one direct domain pattern: one product-definition position in a TFS selected to answer the development question, one equipment-readiness position in a TFS selected to follow the changes that establish equipment readiness, and one release-condition position in a TFS selected for assurance. 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 a position in a TFS selected for operation or use back to a position in a TFS selected to answer the development question. The relation occurrences form a feedback cycle, while the selected direct-member nesting remains acyclic. The feedback does not make the operation-or-use TFS a member of itself and does not turn observation into development Work.

#Architecture and two demonstrative boundaries

For one containing 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 merely to fill the architecture field.

A Plain A.1.STM long-mantra map may display proposed members and a missing cross-member link before network admission. It names the intended final result and the absent member, governor, predicate result, occurrence, or endpoint binding; it asserts neither an E.18.NET structure nor a CGUS.

After the network is admitted, a separate teaching mantra may show one finite admitted dependency slice. The slice uses 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, make the path the whole network, or turn a leaf-local DesignRunTag into a project phase.

#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 cue “transformation-flow network” is 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
  SubjectPatternLocator: 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: A.15.6 for actual project Work, project system-of-interest designation, and subject- or claim-centred case closure; A.1.STM for a Plain provisional long-mantra display and backward/forward attention use; 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, causal or acting positions, Work, production, and work-to-change claims; E.17 for publication; E.11 for public entry and recognition; and E.11.PUA for using one already selected pattern to reach its first useful result.

Does not replace: the direct pattern that defines or constrains 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-08-04 — upstream FPF commit 67092138 (github.com/ailev/FPF)