What a Change Affects

Description

Open a saved step and, above its Save buttons, Weave says what a change to it would reach:

Changes to this step affect 8 downstream steps in 2 workflows.

The sentence counts the steps that read a table this step writes, the steps that read what those write, and so on, up to ten steps downstream. It is read from the saved settings of the project’s steps, so it is instant, it is an exact count of the steps that list these tables as a source, and no AI is involved. It is there to inform the save, not to gate it: you can always save.

What the Sentence Says

Weave says	What it means
Changes to this step affect 8 downstream steps in 2 workflows.	Eight steps read what this step writes, directly or through other steps, and between them they sit in two workflows. A step in two workflows is one step, in both.
Changes to this step affect 3 downstream steps: 2 in 1 workflow and 1 in no workflow.	A downstream step that is not placed in any workflow is counted, and listed under Not in any workflow.
Changes to this step affect 3 downstream steps, none of them in a workflow.	Every affected step is unplaced. With one step: “affect 1 downstream step, which isn’t in any workflow.”
Changes to this step affect at least 8 downstream steps in at least 2 workflows. Weave stopped looking 10 steps downstream.	The chain of readers runs longer than ten steps. The counts are a floor, not a total, and the sentence does not break them down by placement.
… You can’t open 2 of them.	Two of the affected steps are hidden from your role. They are counted, so the sentence stays right, but not named. When every affected step is hidden the sentence ends “You can’t open any of them.”, or “You can’t open it.” for one.
No other step lists a table this step writes as its source.	No step names one of these tables as its source. A step that reaches a table through a SQL query or an expression isn’t counted, and How Weave knows says so.
This step doesn’t write a table, so Weave has nothing downstream to follow.	The step produces something other than a project table, such as a file, an email or an ERP posting, and Weave can’t follow who uses that.
Weave couldn’t check what changes to this step affect.	The preview could not be read. Following the chain needs read access to steps, workflows and tables, so a role missing any one of them sees this. Saving works as usual.

See the Steps

Show the steps lists the affected steps by workflow. Workflows you can open come first, by name; the workflows you can’t open follow as one group; steps in no workflow come last. Within a workflow the nearest readers are listed first, and steps you can’t open are counted at the end of the list rather than named. A step that is in more than one workflow is listed under each of them, and How Weave knows says so. A long list scrolls.

How Weave Knows

How Weave knows, under the sentence, shows what Weave did and what it left out:

What Weave did — followed each table this step writes to the steps that read it, and on through what those write, up to ten steps downstream.
Where it came from — the tables this step writes, and the saved settings of every step in the project. A table your role hides is listed as one you can’t open, and a table named in the step’s settings that doesn’t exist yet is listed by that name.
What Weave didn’t check — steps that reach these tables through a SQL query or an expression rather than by listing them as a source; dashboards, views, exports and anything outside this project that read these tables; whether the affected steps would fail, or just run on different data; and edits to this step you haven’t saved.

When It Appears

For a saved step only. A new step, or a duplicate you haven’t saved yet, has no readers to count.
It refreshes after Save while the step stays open, since a save can change which table the step writes.
It reads the project’s saved settings, so it never costs an AI call and keeps working when no AI provider is available.