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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 11:52:20 UTC · snapshot created 2026-10-03 11:53:41 UTC · last check 2026-10-03 12:15:10 UTC

B.1.2:0 - 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 subject pattern 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 subject patterns.

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 the question is a functional claim, use its direct behavior or realization predicate; use A.6.F when the function wording is unresolved and C.30.ASV when architecture-view conformance is needed.
  • If bearer allocation or parthood is the question, use the direct allocation or part-relation pattern; use A.6.M only when module or interface wording needs repair.
  • If a mathematical aggregation lens is the question, use C.29.
  • If the question is project system-of-interest designation, system-role assignment, Work, transformation, service or access, evidence, description, or publication, use that subject pattern; B.1.2 neither identifies nor defines those relations.