#System Aggregation and Holon Delimitation

B.1.2 · Stable · Part B holonic construction pattern · Normative unless a section is explicitly informative · Part B - Trans-disciplinary Reasoning Cluster

#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.

Type: Part B holonic construction pattern Status: Stable Normativity: Normative unless a section is explicitly informative

Use this pattern when one exact entity recognized under the already admitted U.System kind, or one exact entity still being evaluated under A.1 for that kind, is being considered as a whole and an engineering decision depends on coordinating its independently governed part-whole, delimitation, crossing, function/bearer, and whole-characteristic claims.

#Relations

#Content

#Use This When

Use this pattern when one exact entity recognized under the already admitted U.System kind, or one exact entity still being evaluated under A.1 for that kind, is being considered as a whole and an engineering decision depends on coordinating its independently governed part-whole, delimitation, crossing, function/bearer, and whole-characteristic claims.

Typical moments:

• a machine, plant, robot, vehicle, building asset, service organization, or operating unit is proposed as a whole assembled from exact constituents;
• a system-level characteristic is to be rolled up from constituent characteristics;
• a supply, signal, measurement, control, source, publication, evidence, or transformation relation is being mistaken for a part relation;
• a functional element must be distinguished from and allocated to physical, organizational, software, or operational bearers;
• a named decision needs one recoverable view of the system boundary, exact crossings, and compatibility choices without turning that view into the system.

First useful move. Name the exact whole and its A.1 recognition status, the decision being made, and each load-bearing claim. For every claim, select its direct owner and either recover the exact result or state the exact missing governor or information. Only then ask whether their joint organization itself changes the named decision.

What goes wrong if missed. System aggregation becomes a drawing exercise. Ports, suppliers, documents, digital twins, dashboards, source records, and measuring instruments become components by placement. Functional elements become physical parts by label. External change or measurement is read as containment. One convenient record then appears to establish all those unrelated facts.

What this buys. B.1.2 coordinates one engineering aggregation decision while leaving system recognition, exact parthood, assembly, delimitation, crossing, function, bearer, characteristic, evidence, description, representation, and decision claims with their direct owners.

Not this pattern when.

• If the exact entity has not yet been evaluated under the already admitted U.System kind, use A.1; do not promote the proposal into a durable kind-like label.
• If one exact part-whole relation is the question, use A.14 and its direct specialization.
• If constructive assembly grounding is the question, use C.13.
• If functional behavior or a functional element is the question, use A.6.F and the exact architecture structural-view owner.
• If module or bearer allocation is the question, use A.6.M and the exact architecture or part-relation owner.
• If a mathematical aggregation lens is the question, use C.29.
• If the question is project system-of-interest designation, role assignment, Work, transformation, service/access, evidence, description, or publication, use that direct owner; B.1.2 neither identifies nor owns those relations.

#Problem Frame

B.1.2 specializes B.1 for system holons, but it is a coordination method rather than the owner of one omnibus system-aggregation relation. The useful engineering question is which exact independently governed facts must be considered together for one aggregation or delimitation decision.

Keep five frequently collapsed objects distinct:

1. The exact system whole. It is independently recognized under A.1 and its direct identity rule.
2. Its environment. In this pattern, environment means the exact external referents and exact crossing relations made relevant by a stated delimitation and use. It is not a generic surrounding object; an exact medium is named separately when that medium is itself the subject.
3. An actual containing system. The larger system of which S is an admitted part exists for this claim only when an exact part-whole relation independently obtains. Interaction or spatial surrounding is not enough.
4. The project system-of-interest. Project designation or selection is a separate claim from U.System identity, environment, parthood, role, and architecture. B.1.2 does not derive it from a box or aggregation decision.
5. Use qualification and neighboring relations. Context is not one world-side container supplied by B.1.2. When claim scope, effective reference scheme, or a bounded model-use structure qualifies a use, recover that exact qualifier under its direct owner. Recover any role assignment or other neighboring relation separately. None delimits the system, identifies its environment, or establishes containment by itself.

B.1.2 does not make Gamma_sys the pattern head, create generic boundary or interaction U-kinds, or infer a part-whole relation from transformation, coordination, responsibility, or representation.

#Problem

Without B.1.2:

1. Boundary by drawing. A box in a diagram is accepted as system delimitation.
2. External relations become parts. Suppliers, grids, sensors, controllers, teachers, measuring instruments, or digital twins are placed inside the system because they interact with it.
3. Functional and physical structures collapse. A resistor symbol, control function, chassis function, or service role is treated as a physical component by label.
4. Whole-level characteristics lack grounding. Mass, capacity, reliability, safety, throughput, assurance, or agency-like characteristics are rolled up without saying which bearers, relations, and scales support the claim.
5. Transformation becomes containment. A tool, teacher, actuator, script, or controller changes a holon and is then treated as its part or containing whole.
6. Coordination record becomes ontology. One aggregate-shaped record silently creates systemhood, parts, boundary, crossings, allocation, evidence, and representation instead of pointing to independently governed facts.

#Forces

#Solution

Use B.1.2 to coordinate one named system-aggregation or delimitation decision across independently governed results. Do not introduce SystemAggregationRelation@Context, HolonDelimitationRelation@Context, HolonBoundaryCrossingRelation@Context, or another record-shaped relation merely to hold the answers together.

#Recover Each Direct Result Or Blocker

Naming those results together does not create a further world-side relation. Stop at the first direct blocker that prevents the named decision; do not weaken it into an aggregate-shaped placeholder.

#Select A Structure Only When The Joint Organization Matters

If the joint organization of several exact results itself changes the named decision, select one ordinary U.Structure under A.22. Recover all four identity discriminators: exact independently identified constituents, exact selected obtaining relation occurrences, exact constraints as applied, and one named selection-use frame with its admissible action or stop.

The selected structure is non-agentive. It creates no system, part, crossing, allocation, characteristic, evidence, or decision fact and does not become the system, its environment, or its containing whole. A box, list, graph, table, description, view, or publication can represent or describe the selected organization but supplies none of the four discriminators by form.

#Make Interface Choices About Exact Crossing Relations

When the aggregate exposes, namespaces, internalizes, excludes, or leaves a crossing with its direct owner, make that choice about one exact crossing-relation occurrence and one named use. These words are ordinary decision options, not a closed FPF enumeration and not another relation kind.

Name the direct world facts, affected endpoints, crossing-relation owner, preserved obligation or information, evidence if relied on, and the C.11 ChoiceResult or C.32.PAD ArchitectureDecisionRelation@Project that chooses among the ordinary interface options when either owner applies. A different choice passes only after its admitted direct owner and result are named; otherwise stop with the missing-governor blocker. If a later use must inspect the choice, identify a separate C.2.1 episteme whose claim content describes it and cites that direct result; the episteme does not make the crossing, parthood, compatibility, or decision fact obtain. This preserves interface accountability without an omnibus compatibility-check object. Without that account, an apparent simplification can silently drop an external obligation or proliferate unmanaged endpoints.

#Whole-Level Characteristics

Roll up system-level characteristics only after the exact bearer, characteristic relation or assignment, scale, and aggregation or inference rule are selected under their direct owners.

Useful families include:

• additive quantities such as mass, cost, energy stock, or material amount;
• limiting quantities such as pressure rating, weakest connector, safety class, or availability bottleneck;
• logical or capability claims such as emergency-stop availability or vulnerability exposure;
• architecture characteristics that depend on selected structure.

Use C.16, A.19, and C.29 when characteristic space, scale, threshold, or mathematical lens is relied on for the current claim. Use B.2 when redundancy, closure, or coordination creates or reveals a whole that must be reidentified.

#Functional Elements And Bearers

A functional element in a functional view is not automatically a system part.

Recover separately:

• functional behavior or functional element under A.6.F;
• physical, organizational, software, or operational bearer under A.6.M, A.14, C.13, and architecture owners;
• allocation or correspondence between function and bearer;
• system aggregation only when bearer parthood is independently admitted.

One bearer may realize several functions. One function may require several bearers. This is allocation and correspondence before it is part-whole.

#Archetypal Grounding (Worked Cases)

#Pump Skid

A pump skid may be one exact entity proposed for recognition under the already admitted U.System kind. Pumps, frame, valves, controller, and connectors become its components only when their exact A.14 part-relation occurrences obtain and C.13 grounds the assembly; the proposal, drawing, and component list establish none of those facts.

The power grid, maintenance crew, telemetry dashboard, and supplier are not skid components merely because the skid depends on them. Recover the exact systems or epistemes and their supply, work, telemetry, publication, source-use, or other direct relations. If a maintenance-isolation decision needs their joint organization, an A.22 selected structure may include the exact obtaining crossings without turning them into parts.

#Resistor In A Circuit

A resistor symbol in a circuit diagram is a functional or design-description element. The physical bearer may be a packaged resistor, a length of wire, a transistor region, or a module. Recover the exact function, bearer, allocation or correspondence, and any part relation separately; B.1.2 only coordinates them for the current circuit decision.

#Digital Twin Of A Building Asset

A BIM model, asset register, dashboard, or digital twin may describe the built asset and its systems. It is not the asset's part by being linked in a model. Use architecture-description, publication, evidence, source-use, representation, and designation owners for the description side; use exact part-relation owners only for admitted system parts of the built asset.

#Lathe And Workpiece

The lathe can change the workpiece through a bounded transformation and work occurrence. Those facts do not make the workpiece a lathe component or make the lathe the larger whole containing it. Use A.3.4, A.15.1, A.12, and the exact crossing or participation owner; use part-whole only when an exact relation independently obtains.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• System aggregation remains practical for engineering systems and organizations.
• Boundary and interface concerns become explicit direct-owner work without omnibus relation or check objects.
• Functional architecture, module allocation, and physical parthood stop collapsing into one diagram.
• Digital-twin and publication artifacts stay on the description side unless another direct pattern admits a stronger relation.

Costs:

• Engineering diagrams need relation-owner annotations when used for decisions.
• Some familiar component lists must be split into physical parts, functional elements, external systems, sources, and descriptions.
• Whole-level characteristic claims need scale and relation discipline.

#Rationale

System aggregation is the place where holonic thinking is most tempting and most useful. It is also where false parthood is easy: anything connected, measured, represented, or controlled can be drawn inside a system box.

B.1.2 preserves the engineering payoff by coordinating exact direct-owner results for recognition, parthood, assembly, delimitation, crossings, function, bearer, characteristic, evidence, and description. It selects one ordinary A.22 structure only when their joint organization changes the named decision.

#SoTA-Echoing

#Relations

• Builds on: B.1, A.1, A.14, C.13, A.22, and the direct relation owners selected for the current decision.
• Coordinates with: A.6.F for functional elements, A.6.M for module and bearer allocation, A.22 and C.30 for selected structure and architecture, C.16 and A.19 for characteristics, C.29 for mathematical lenses, A.3.4 and A.12 for transformation and acting-side externalization, and C.30.AD or C.30.AD.BA for architecture-description cases.
• Can contribute evidence to: B.2 when system aggregation no longer explains the whole-level claim and whole reidentification is needed.

#B.1.2:End

---

Last Updated: 2026-08-05 — upstream FPF commit 3dbce514 (github.com/ailev/FPF)