What a data node reads

A Load row or Write row node on the canvas does not point at one fixed place. What it reads depends on how the workflow is running:

When the workflow runs as…	The node reads…
a live run or a batch job	the source it is connected to — a sheet, a table, a saved dataset
a backtest	the dataset chosen in the backtest’s settings, as of each step in time
an evaluation	the fixture dataset chosen in the suite’s settings

This is deliberate. A backtest must never read today’s live data, and an evaluation must never read live data either — so the same workflow, unchanged, reads a frozen dataset in those two cases. What you test is exactly what you run.

The node shows all three, so you can see it before you run anything — and each one can be changed right there (see Changing a binding).

Reading the node

Open a workflow in the canvas. Each data node has a Bindings line; click it to expand:

live      → VCs (Google Sheet)
backtest  → 3 configs · latest: Momentum trio (126 rows)
eval      → ⚠ no fixture bound

Each row says what that kind of run would read. The colour tells you whether that is fine:

You see	It means
a name	Bound. That run reads this.
⚠ no dataset bound / ⚠ no fixture bound	That kind of run would refuse to start, because there is nothing safe to read. Fix it before running a backtest or an evaluation.
⛔ credential revoked, ⛔ source detached, ⛔ dataset no longer exists	Bound to something that no longer works. Reconnect the credential, re-attach the source, or choose another dataset.
no live source (grey)	Nothing is connected for a live run. Harmless if this workflow only runs as a backtest or an evaluation.

The node stays folded when everything is ordinary and unfolds by itself, with a ⚠ in its header, when something needs attention — so a warning is visible from across the canvas.

When a backtest has several configurations, the node shows how many and the most recently edited one, plus how many have no dataset.

The node keeps up as you work. Binding a dataset in the Backtest tab, choosing an evaluation fixture, creating or editing a batch job, detaching a source or deleting a dataset all update it — there is nothing to save first. A backtest configuration with no dataset is refused when you try to run it, with the same reason the node shows.

Nodes inside a batch job

The Load row and Write row at the top and bottom of a batch job are different: the job puts them there, and they always read the job’s source and write its target, live. Their rows say reads and writes, and note that a batch job is never backtested or evaluated.

Changing a binding

Open the node in Edit mode (click it, or click Bind… on a node that says no live source). Its settings panel has a Data bindings section with the same three rows, each with one control:

Row	What you can do
live	Pick a connected source for live runs, or clear it. The list shows only sources in this workspace that can do what the node does — a Load row needs a source it can read, a Write row one it can write. The change is saved with the next version of the workflow.
backtest	Pick the dataset a backtest reads. If there are several backtest configurations, choose which one first (the most recently edited is preselected).
eval	Pick the fixture dataset an evaluation reads, or choose No fixture.

Changing a dataset asks you to confirm, and tells you exactly what happens: runs that already finished are unaffected — they scored against the data they had — and a run that is in progress right now stops at its next step, keeping what it already graded. Nothing is locked; the confirmation is the whole rule.

Two rows cannot be changed on the node, on purpose:

• The Load row and Write row inside a batch job always read the job’s source and write its target. Change them in the job’s inspector.
• A Write row that is not inside a batch job cannot be given a live target here: a write outside a batch job would not be recorded in the job’s ledger. Create a batch job for it instead — the node says so and links there. Its backtest and eval rows still work as above.

If you bind a source that this workspace cannot use — one that was detached, or one a Write row cannot write to — saving the workflow is refused on the spot, naming the node and the reason, instead of failing in the middle of a run.

The same bindings are also available where they always were, if you prefer:

To change…	Also in
what a backtest reads	the Backtest tab → the config → its dataset
what an evaluation reads	the Evals tab → Suite settings → fixture dataset
what a batch job reads and writes	the job’s inspector on the canvas

Why a backtest reads a different dataset than my sheet

Because a sheet is now. A backtest asks what your workflow would have decided last March, and the only honest answer comes from data that records when each value became known. That is what a saved dataset is — see Connect your data for how to capture a live source into one and build a history you can backtest over.