GAD Editorial · Published · · English study · Chinese summary
A recommended node can help an architect find a route through a visual program. It cannot decide whether the resulting facade grid has the intended number of panels, handles an opening correctly or preserves the relationship between rows. Those outcomes need to be stated before the graph grows.
Dynamo introduced machine-learning Recommended Nodes in its Core 2.17 release in January 2023. The feature ranks possible connections using patterns from sample graphs, while the existing Node Type Match method filters by compatible types. The accompanying explanation describes the model as using the triggering node and port rather than the whole graph. Release announcement · Predictive scripting explanation
That published description makes an important distinction for practice: a high-ranked next connection is not a validation of design intent. This evergreen guide concerns node recommendations, not the separate Assistant experience. Check the Dynamo version, host application and available feature in the actual installation before planning a trial.
Define a small geometric result
Begin with a task whose answer can be checked without running a large project model. An illustrative facade exercise might divide a simple rectangular surface into a stated number of rows and columns, then reserve one known region for an opening. Write down the expected panel count, boundary conditions and units.
Keep the first graph limited to geometry and visible intermediate values. Separate this exploration from nodes that create, modify or remove elements in a host model. A small, inspectable test makes it easier to distinguish a misunderstanding of data structure from a problem with the design requirement.
Inspect data as carefully as the preview
Use recommendations to find candidates, then read the selected node's help and examine its inputs and outputs. Check whether the value is a single object, a list or a nested list, and whether the grouping still represents the intended facade rows. A plausible preview can conceal duplicated geometry or a flattened structure that will fail at the next step.
Test an ordinary case, a boundary case and an intentionally invalid input. For example, check the smallest permitted division count and an opening that meets the outer edge. Define how the graph should report an invalid value rather than accepting whatever result happens to appear.
Explain the accepted connection
Keep a note of what each critical branch does and which test demonstrates it. If a suggested node fails, record the failure and choose another route through the normal library or documentation. The ranking is a search aid; it should not become an argument for retaining a connection that does not meet the brief.
When the graph is ready to affect a building model, use a controlled copy and an explicit review step. Compare intended changes with the actual element set, preserve a recoverable baseline and check repeated runs for unintended duplication. Record the host, Dynamo and package versions with the accepted graph.
The handover should include the graph, small test inputs, expected outputs and known limits. A colleague should be able to reproduce the result without reconstructing the original authoring conversation. Evaluate that reproducibility and correction effort alongside the convenience of choosing a recommended node.