#Dependency Structure and Relation Grounding

B.1.1 · 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 an aggregation, architecture, assurance, or construction claim depends on how candidate parts, members, phases, portions, or external relations depend on each other.

#Relations

#Content

#Use This When

Use this pattern when an aggregation, architecture, assurance, or construction claim depends on how candidate parts, members, phases, portions, or external relations depend on each other.

Typical moments:

• a dependency diagram is used to justify a whole-level claim;
• a graph mixes parthood, mapping, order, time, resource, and boundary-crossing relations;
• a project needs to know whether a relation is part-whole, dependence, representation, influence, source use, publication use, or evidence relation;
• a selected dependency structure will be expressed with a graph, table, matrix, or another mathematical or representation lens.

First useful move. Name the dependency relation under concern before choosing graph notation. Then decide whether the relation is part-whole, boundary crossing, order, temporal phase, resource relation, mapping, evidence, publication use, source use, or another directly governed relation.

What goes wrong if missed. A graph becomes the ontology; an edge named "depends on" carries many relation kinds at once; external influence becomes parthood; order and time are encoded as structure; and mathematical checks look precise while the relation being checked remains unclear.

What this buys. B.1.1 lets dependency material bear on B.1 aggregation without letting graph notation decide relation kinds.

Not this pattern when.

• If the current relation word is a mereology question, use A.14.
• If the current part-whole claim needs constructional grounding, use C.13.
• If the current object is architecture selected structure, use A.22 and C.30.
• If the current expression is mathematical-lens choice, use C.29.
• If the current question is performed work, use A.15.1.

#Problem Frame

B.1.1 separates dependency structure from graph representation.

A dependency structure can be ontology-side when a direct pattern has selected the relation under concern. A dependency graph is a mathematical or representation description of that selected relation structure. The graph may be useful, but it is not the holon, not the part-whole relation, and not the constructional grounding by itself.

#Problem

Without B.1.1:

1. Edge drift spreads. ComponentOf, MemberOf, PhaseOf, SerialStepOf, RepresentationOf, source use, evidence relation, and control relation all become generic graph edges.
2. Boundary crossing becomes parthood. A power grid, supplier, teacher, measuring instrument, model, or source record is drawn as a part because it affects the holon.
3. Design and run objects mix. Planned structure, design description, actual work occurrence, and telemetry are placed in one dependency expression without a DesignRunTag or owner distinction.
4. Acyclic graph discipline overclaims. A graph check says something about the drawing, but the ontology-side relation remains ungrounded.
5. Mappings become parts. A digital twin, dashboard, diagram, or architecture description is treated as a constituent of the object it describes.

#Forces

#Solution

Use dependency structure first; use graph representation second.

#Dependency Structure Frame

DependencyStructure@Context:
  structureUnderConcernRef:
  boundedContextRef:
  candidateNodeRefs:
  dependencyRelationRefs:
  partWholeRelationRefs?
  boundaryCrossingRelationRefs?
  orderRelationRefs?
  temporalRelationRefs?
  resourceRelationRefs?
  representationRelationRefs?
  evidenceRelationRefs?
  publicationOrSourceUseRefs?
  designRunTag?
  directOwnerRefs:

This frame is not a U-kind. It records which relation claims are current and which direct owners govern them.

#Graph Representation

Use graph language only when a graph is the selected mathematical or representation lens:

DependencyGraphRepresentation@Context:
  representedDependencyStructureRef:
  nodeExpression:
  edgeExpression:
  graphPropertyChecks?
  mathLensRef?
  publicationOrViewRef?

The graph may express acyclicity, reachability, cutsets, weak links, flow, or traceability. Those checks apply to the graph expression and bear on the selected relation only when the relation owner admits the mapping.

#Relation Grounding Guide

#Graph Checks Are Conditional

Acyclicity, topological order, cutset, reachability, and flow checks are useful only after the graph is selected as a lens over a selected relation structure.

Do not infer:

• parthood from graph adjacency;
• independence from graph separation without relation-owner admission;
• performed work from a planned step graph;
• whole reidentification from a graph property without B.2;
• architecture from a graph without selected-structure and architecture owners.

#Archetypal Grounding (Worked Cases)

#Bias-Annotation

#Digital Twin

Source graph: DigitalTwin -> Turbine.

If the edge means representation, recover the architecture-description, publication, source-use, evidence, or digital-twin relation. The digital twin is not a turbine component by graph adjacency.

#Work Plan And Work Occurrence

Source graph: Prep -> Weld -> Paint.

If the graph describes a method or process view, use the method and order owners. If the graph describes performed work, use A.15.1 with occurrence identity, timing, evidence, and work-part relation. Do not let the same graph do both jobs.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• Dependency views become useful without becoming hidden ontology.
• External influences can be discussed without corrupting parthood.
• Graph checks keep their value and their limits.
• B.1 aggregation receives cleaner part-whole inputs.

Costs:

• A diagram alone is no longer enough; relation kinds and owners must be named.
• Some compact dependency graphs need multiple relation layers or views.
• Graph-based checks may need C.29 when the mathematical lens is relied on.

#Rationale

Dependency language is useful exactly because it is broad. That breadth is also the danger. FPF keeps the breadth for recognition, then restores precision by separating relation kinds, selected structures, mathematical expressions, and publication forms.

B.1.1 therefore does not abolish dependency graphs. It makes them honest: a graph represents a selected relation structure; relation grounding comes from the direct owners.

#SoTA-Echoing

#Relations

• Builds on: B.1, A.1, A.14, C.13, and A.6.5.
• Coordinates with: A.15.1 for work occurrence, B.1.4 for contextual and temporal aggregation, C.29 for graph as mathematical lens, A.22 and C.30 for selected structure and architecture, C.30.AD and C.30.AD.BA for architecture description and digital-twin cases.
• Can contribute evidence to: B.2 when dependency evidence bears on whole reidentification after existing-whole explanations fail.

#B.1.1:End

Last Updated: 2026-08-04 — upstream FPF commit 8b727cba (github.com/ailev/FPF)