The Dependency Graph
Every notebook is a directed acyclic graph of cells: the engine reads which variables each cell reads and writes, and draws an edge wherever one cell consumes another's value. That graph is what makes the notebook reactive — change a value and only the downstream cells restale.
This page is about seeing and shaping that graph: the DAG pane, manual edges for effects no variable carries, and running part of a notebook on another kernel (regions).
The DAG pane
Open the pane with the 🕸 DAG button in the top bar, or ⌘⇧G. It's a live map of the notebook's dataflow — one node per cell, an edge wherever a cell reads a value another cell writes — laid out automatically and updated as you edit and run.
Node color mirrors each cell's state — fresh / stale / running / errored — so a wave of gold shows exactly what a change restaled.
⚙ display — show setup cells (
using/importand their edges) and show isolated cells (cells with no dataflow edges) are off by default, keeping the graph to the cells that actually pass data.⇅ direction — layout orientation; auto follows the pane shape (a tall pane lays out top-down).
◨ dock and the grip re-side and resize the pane.
🔥 heat map — color cells by accumulated compute time (hotter = more expensive), to find the bottleneck in a pipeline.
🖧 region map — color cells by where they run (see Regions).
Manual edges
The engine infers edges from the variables a cell reads and writes. Some dependencies aren't carried by any variable, though — a cell that writes a file, seeds a database table, or mutates global state that a later cell reads back. Assert those yourself so the engine keeps the two in order:
needs=id1,id2header tag — set it with the 🏷 tag editor or directly in the cell header. It names the earlier code cells this one depends on.🔗 link mode in the DAG pane — click it, then click two cells to draw a manual edge (shown dashed); click a dashed edge to remove it.
Manual edges are first-class: they drive staleness, run order, and cache keys exactly like inferred ones. A needs= that names no earlier code cell (deleted, moved below, or a markdown cell) is inert and flagged with a 🔗⚠ badge on the cell.
Regions — run cells on another kernel
When a notebook is split into regions, some cells run on a second kernel (usually on another host) while the rest stay local. The DAG pane is where you see and steer that split; the region model itself — defining regions, declaring destinations, how boundary values cross — is in Regions.
Steering regions from the DAG
Turn on the 🖧 region map and the graph reorganizes into side-by-side zones — 💻 local and one per region — with each node tinted by where it runs and the cross-zone edges drawn as the boundary hand-offs (labeled by transport: direct / ssh-bridge / relay). Drag a node between zones to reassign it. A node wears a 🖧 badge when its last run executed on a region kernel, and the legend along the bottom names the hosts and hosts the region toolbar.
Click any node for its detail card. For a cell whose last run was remote it shows the provenance: a last ran 🖧 host chip, a moved ⇄ N MB chip for the inputs that had to cross the boundary, a per-transfer breakdown (size · route · throughput), and a Run on picker to reassign the cell to a different kernel in place.
Each region zone header carries a live status dot — hover it for the region's worker card: connection status, host, transport, and CPU / RSS / running-cell telemetry, with 🪵 Log and ✕ Reap actions.
The region toolbar
The region-map legend hosts three tools for the cross-region plumbing.
⇄ peer routing plan — how each region pair is wired: a resolved direct or ssh-bridge route worker-to-worker, or a relay through the hub, with per-host grants and host-key pins. ↻ recalculate probes every pair live so throughput and route are measured now rather than on the next real transfer.
📊 transfers — a dashboard of every boundary move: total moved, throughput over time, a region-to-region grid, and the rate distribution — to see where the data actually flows and how fast.
⇄ connect — the first time two regions on different hosts need a direct worker-to-worker link, Slate asks before exchanging keys (decline and transfers still work — they just relay through the hub). The dialog spells out exactly what it installs — an on-host ed25519 key, a locked-down single-port grant, a host-key pin — then arms the bridge with live progress.
While a value crosses the boundary, the consuming cell shows a live progress bar (⇄ <name>: N/M MB ← host) — driven on its own data channel, so a big move never looks like a hang.
See also
Reactive Cells — the reactive model the graph drives, and the 🔗 upstream focus.
Regions — running part of a notebook on a second kernel, steered from the DAG.
Remotes & Pools — hosts, transports, and warm pools.
Cell Tags & Caching — the
needs=andregion=tags in the header.