#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 it is part-whole, boundary crossing, order, temporal phase, resource, representation, evidence, publication use, source use, or another direct relation defined or tested by the applicable pattern.

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, a collection's belongs-to relation, 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 a distinction among the patterns that define those claims.
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:
  dependencyQuestion:
  intendedUse?:
  claimScopeRef?: U.ClaimScope
  qualificationWindowRef?
  candidateNodeRefs:
  selectedDependencyStructureRef?
  dependencyRelationRefs:
  relationParticipantRefs:
  relationGroundingRefs:
  partWholeRelationRefs?
  boundaryCrossingRelationRefs?
  orderRelationRefs?
  temporalRelationRefs?
  resourceRelationRefs?
  representationRelationRefs?
  evidenceRelationRefs?
  publicationOrSourceUseRefs?
  designRunTag?
  definingOrTestingPatternRefs:

This frame is not a U-kind. It records the current relation claims, their exact participants, grounds and qualifications, the selected dependency structure when one is current, and the patterns that define or test those relations.

#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 rule for that relation 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 a rule that makes the selected relation support that inference;
• performed work from a planned step graph;
• whole reidentification from a graph property without B.2;
• architecture from a graph without an exact described holon, selected structure, and architecture relation or claim.

#Archetypal Grounding (Worked Cases)

#Plant Supplier

Source graph: PowerGrid -> Plant.

If the edge means electricity supply, recover a boundary-crossing or supply relation. The power grid is not a plant part. Use part-whole relations only for admitted plant internals.

#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 patterns that define the method, description, and order claims. If it describes performed Work, use A.15.1 with occurrence identity, timing, evidence, and the exact Work 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 the patterns that define or test them 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; each direct relation is grounded by the facts and rule that make it obtain.

#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-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)