E.18.NET:5.2 - 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 and U.System identity remain separate from any local system-role kind, classification, assignment, selection Work, or result episteme. None follows from a project or network label.
For the compiler-and-application use, identify five TFS values by the questions they answer:
CompilerEditionPreparationTFS, whose loci bind compiler-edition preparation and the obtaining source-use occurrences needed by the build;BootstrapCompilerBuildTFS, whose loci bind Work on pre-existing build substrates and the separately grounded production and identity-inception claims for one bootstrap compiler;ApplicationBuildTFS, whose loci bind application-production Work and the exact use of that admitted compiler;ReleaseAssuranceTFS, selected for release-assurance questions; andDeploymentOperationTFS, selected for deployment and operation after the application system exists.
These names designate independently identified TFS values, not lifecycle kinds. They assert no transformation of a not-yet-existing compiler or application. Use E.18 for each TFS, A.15.1 for any current Work occurrence, A.3.4 for a change of a continuing referent, A.15.PROD for production or identity inception, and the applicable relation pattern for each exact cross-member occurrence.
Select the nested network values from those already established inputs:
| Selected network | Direct members | Exact selected cross-member occurrence and ordered endpoint binding | Network use frame |
|---|---|---|---|
CompilerRealizationNetwork | CompilerEditionPreparationTFS; BootstrapCompilerBuildTFS | CompilerEditionSourceUsedByBootstrapBuild-1: CompilerSourceEditionReady -> BootstrapCompilerBuildInput | connect the admitted source edition to the bootstrap-compiler build question |
ApplicationCompilerUseNetwork | CompilerRealizationNetwork; ApplicationBuildTFS | BootstrapCompilerUsedByApplicationBuild-1: exposed ExecutableCompilerResult -> ApplicationCompilerUsePosition | connect the admitted compiler to the application-build question |
ReleaseAssuranceNetwork | ApplicationCompilerUseNetwork; ReleaseAssuranceTFS | ApplicationBuildEvaluatedForRelease-1: exposed ApplicationBuildResult -> ReleaseEvaluationSubject | connect the application result to the release-assurance question |
DeliveryOperationNetwork | ReleaseAssuranceNetwork; DeploymentOperationTFS | ReleasedApplicationUsedByDeployment-1: exposed ReleasedApplicationPosition -> DeploymentApplicationInput | connect the released application to the deployment-and-operation question |
Each named occurrence is independently established under its project predicate before selection. Each network applies its exact endpoint-binding and boundary-exposure constraints plus the acyclic direct-member constraint, and each keeps the use frame in its row. The local names select or add nothing by themselves.
No claim about who selected these networks is required. If the case also needs CompilerNetworkSelectionWork-5, cite each precise performer’s independently established A.13 core and the Work’s independent A.15.1 admission. Add F.6 only if the case also needs exact assignment-bound attribution; its assignment declaration and proof remain outside E.18.NET. Adding or removing the Work or attribution claim changes none of the four network identities above. The result episteme may describe the selected structures and cite a separate selection or decision relation, but it is not a decision or accountability relation by form. Any accountability claim needs its own exact predicate and participants.
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 obtaining production, inception, participation, application, use, or other relation occurrences and their 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, the exact relation-claim result returned by its governing pattern, or the separate missing occurrence, endpoint, or position 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.