fpf.tools
Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading
Source · lines 99671–99684

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 14:36:52 UTC · snapshot created 2026-10-03 14:38:14 UTC · last check 2026-10-03 15:10:10 UTC

E.18.NET:2 - Problem

Teams routinely connect flows that concern different objects, Work occurrences, architecture boundaries, valuation state, and change cadence. A development TFS has positions for the Work that produces or changes a tool; other TFS values have positions for its use and evaluation, with feedback 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:

Working situationWhat is actually selectedWhat to do
Several valuations, paths, or slices share one exact TFS identityone TransformationFlowStructurestay in E.18; do not mint another structure
A detailed portion resolves through positions and internal U.Transfer occurrences of one exact parent TFSone parent-relative SubflowRefstay in E.18; return through the parent’s boundary positions
Independently identified TFS or nested-network values are connected by exact obtaining relations across their boundariesone TransformationFlowStructureNetworkapply this pattern

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.