The Hidden Chain of Dependencies Inside a Single Parametric Model

There’s the definition you can see on the canvas, and there’s everything it depends on that doesn’t show. Plugin versions, Rhino doc state, tree structure that components expect, values internalized months ago and forgotten, decisions that never made it into a note. Most of the model is implicit, which is how a file that worked yesterday can produce different geometry today without anyone touching the canvas.

Plugins Drift Between Versions And Machines

Build a definition on Pufferfish 3.1, open it later on 3.4, and the output isn’t necessarily the same. Maybe a default shifted, or a component picked up a new input that reordered the old ones. Wires end up plugged into different sockets than the author intended, geometry comes out subtly off, and unless somebody compares outputs nobody notices.
Same problem across a team. Three designers on three different builds of Lunchbox or Kangaroo produce three different outputs from the same file, and nobody checks versions until something downstream has already broken.

Tree Structure Is Part Of The Contract

Every component reads the tree it gets in a specific way. A Loft expecting {0;0} branches with N curves each behaves very differently if you feed it {0} branches with the same total curves.
Often it doesn’t error, the geometry just comes out wrong in ways that don’t surface until someone exports to CAM and the parts nest per branch instead of per piece.
Nothing in the file declares this expectation. Tree shape is part of every component’s interface, except nobody writes that down. Shift the tree upstream and the definition still computes, just on different data.

Constants You Can’t See

Internalizing a slider or baking a number into a panel hides the value without removing it from the model. A year later somebody can’t figure out where 847 mm is coming from. No slider, no parameter, just a Number component nobody thinks to check.
Expressions with hardcoded math do the same thing. A divide-by-1.414 made sense to whoever put it there and is now a magic number. Clusters make it worse, anything inside them is out of view by default.

The File Depends On Its Rhino Doc

Definitions that reference Rhino geometry by layer, GUID, or named view are tied to that document. Rename a layer and it errors, delete a referenced object and components turn red, move the file to a doc with no source geometry and half the definition has nothing to feed it.
Units and tolerances are part of this too, and easier to miss. A definition tested in millimeters at 0.001 tolerance behaves differently in meters at 0.01. Booleans that resolve start failing, joins that close produce open breps. None of it is obviously visible in the GH file.

The Author Is The Last Invisible Dependency

The biggest unwritten dependency in any model is the person who built it. Why a branch is flattened, what made someone pick 0.001 over 0.01, why operations are sequenced a particular way: that reasoning lives in someone’s head, not in the file.
A definition can outlive its author for a while without anyone noticing. The file opens, the geometry generates. The problem shows up when somebody changes something. The change looks harmless and breaks something three branches downstream, because the structure was that way for a reason and the reason left with the author.
Most parametric models that fail in production aren’t failing because the logic is bad. The logic has assumptions inside it that nobody can ask about anymore.

Making The Second Graph Visible

Definitions that survive handoff are the ones where someone made the dependency graph visible:

• plugin versions noted in the file or repo
• scribbles next to sections of definition describing what they do
• no internalized constants without a labeled note
• Rhino doc references kept minimal, and noted down when used
• decisions written down somewhere other than the author’s head

None of it shows up in a render. It’s the difference between a definition that only works for its author and one that survives the project.
That’s most of what we do at Borg Markkula, building systems that hold up after they leave their author’s machine. If that’s a problem you’re running into, we should talk.