A graph shows the relationships. A wave keeps one change coherent. A boundary makes outside work explicit.
Graph: the visible relationship map
A graph names the facts, calculations, and effects that belong to one ordered set of related updates.
Think of a feature, not the whole company
A graph is a useful boundary around work that needs to settle together: a form, a live view, a pricing decision, or one part of a workflow. Inside it, the important relationships are explicit and updates are ordered.
Keep tightly related updates in the same graph.
Use more than one graph when work truly has separate timing or ownership.
Connect separate graphs through an explicit adapter or transport boundary.
Wave: one cause moving through the graph
A wave keeps the updates caused by one change together until the affected part of the graph settles.
Why it exists
One input often updates several branches before they meet again. Treating that movement as one wave lets shared joins wait for the relevant branches and publish a coherent result.
Affected paths know that a change is underway.
New values move through the declared relationships.
A join avoids publishing a half-old, half-new view.
Boundary: where outside work enters
A boundary makes files, network calls, workers, remote graphs, and model calls visible as they enter or leave the graph.
Keep different timing honest
Outside work may finish later, fail independently, or live in another process. Put that work behind a source, pool, adapter, or bridge, then bring its result back as an explicit fact the graph can use.
Do not hide timers or callbacks inside ordinary calculations.
Let the application or package adapter own network transport.
Keep the result and its downstream effects visible in the graph.