Concepts
The graph is the coordination surface.
GraphReFly organizes work as inspectable topology: one graph owns one ordered concurrency domain, waves carry updates through declared edges, and async or remote work re-enters through explicit boundaries.
Summary
A graph is the single-thread concurrency domain for related updates; causal influence can still cross graphs through explicit delayed boundaries.
Use It
Keep tightly related updates inside one graph when they need to settle together. When work crosses a graph, process, worker, or runtime boundary, model that boundary explicitly instead of pretending it is the same immediate update.
- One graph serializes its own propagation.
- Cross-graph influence returns through a wire bridge or package-owned adapter.
- Graph boundaries explain concurrency, not every possible causal relationship.
Summary
A wave is the ordered update unit that lets dirty notifications, values, and settling behavior stay explainable.
Use It
Think of an update as one coherent movement through declared edges. The shared docs describe the behavior; package docs own the exact APIs that create or observe it.
- One message array is one wave.
- Dirty state reaches joins before changed values settle.
- Downstream reducers should see coherent inputs, not half-old mixes.
Summary
Async work, host callbacks, worker pools, and remote runtimes belong at explicit boundaries that re-enter the graph with visible facts.
Use It
Keep ordinary graph propagation synchronous and inspectable. Put files, network calls, background workers, and cross-runtime transport behind sources, pools, adapters, or bridges that publish explicit graph-visible results.
- Do not hide timers or callbacks inside reductions.
- Use package-owned adapters for environment-specific IO.
- Keep package API details delegated to language-local docs.