What Weave Checks

Description

Weave reads the configuration your project has already saved, and the record of how its workflows have run over the last 30 days, and reports what it finds: a step whose allocation has nothing to allocate, a workflow whose saved structure lists the same step twice, a workflow whose last run failed, a step whose output holds far fewer rows than it usually does. It reads only — nothing it reports changes a step, and it never runs your workflow.

No AI model is involved. Every check is a fixed rule and every sentence is written in advance, so a report costs nothing to produce however often you ask for one.

Three answers, not two

Most checks in PlaidCloud have two answers: your configuration is fine, or it is refused. Weave has a third, and it is the one worth understanding.

Answer	What it means
Weave noticed …	Weave checked this and found a problem.
(nothing said)	Weave checked this and found nothing wrong.
Weave hasn’t checked …	Weave could not judge this at all.

The third exists because silence is ambiguous. When you create an allocation step, PlaidCloud lets you save it before you have filled in its column mapping — you are still building it, and refusing the save would stop you working. A monitor reading that same empty mapping could easily report the step as healthy. It is not healthy; it is unfinished, and nobody has looked at it.

So Weave says so. A step it could not judge is reported as unchecked, with the reason, and it is never counted, sorted or coloured as if it had passed.

There is a fourth thing Weave can say, and it is not an answer about your step at all: Weave has no rule for …. That means Weave has no check for that kind of thing and never judged it. Unlike “hasn’t checked”, nothing you do to the step will produce a verdict, so the two are worth telling apart: finish an unchecked step and Weave will judge it; a step it has no rule for stays unjudged however much you change it.

What a report looks like

A report opens with a summary that names its own denominator, so you can see how much of the project it covers:

Weave fully checked 3 of the 417 steps and workflows in "Cost Model", and found 1
problem in the parts it could judge. 1 more it hasn't fully checked.
Weave has no rule for 412 steps and 1 workflow it looked at, so they have not been
judged either way.

Weave noticed the step "Spread Overheads": No driver split value column found. One
driver column must have the role "Split Value".
Weave hasn't checked the step "Regional Split" — its column mapping is empty.

When a project has tables written on a schedule or given a freshness threshold, the first line counts them separately: Weave fully checked 31 of the 36 steps and workflows, and 3 of the 4 tables expected to be kept up to date, in “Finance”, and found 2 problems in the parts it could judge.

The fraction in the first line is deliberate. Three steps checked and found clean is not the same statement as a clean project, and the opening line carries its own scale so that it cannot be quoted without one. “In the parts it could judge” is there for the same reason: where something was judged only in part, the problems found cannot be pinned on the steps the line has just called checked. The second line names what Weave has no rule for at all, and says out loud that those have not been judged either way — not that no check was needed.

How Weave Knows

Every finding has a How Weave knows link under it, which opens a panel showing how Weave reached it:

The check — what the rule tests, in plain words, with the limits it uses, such as how many earlier runs it compares a count against.
The evidence — the values the check used. For a row count that changed, that is the latest count, the average of the earlier runs, how much the count usually moves from run to run, and the range outside which Weave reports it.
Where it came from — the run, the run history, the step’s saved settings, the scheduled event or the table the evidence was read from. One shown as a link opens where you would look at it, such as the workflow or Table Explorer.
What Weave didn’t check — what the rule leaves out. This is never empty: a check that a table was written on time, for example, doesn’t look at what was written.

For a finding Weave couldn’t check, the panel shows the check and the reason it couldn’t run, and no evidence.

The panel names only what you can see. A step, workflow or table your role hides is listed as one you can’t open, never by name, and when a workflow’s last run failed in steps you can’t open, the evidence counts those steps rather than naming them. No AI is involved in building the panel.

The panel appears on the Weave tab and in a review. A review’s AI-written summary has one too, saying it was written by AI, from how many findings, and what Weave checked before showing it. A review that an AI assistant runs through PlaidCloud MCP leaves the panel out.

What Weave checks today

Allocation column mapping. For an Allocation with Dimension or Allocation Split step, that there is a numeric column to allocate, a numeric driver value to allocate it by, a hierarchy where one is needed, and — for a split — a numerator and a denominator that names a column the source table actually has. These are the same checks that run when you save the step, reading what was already saved. Saving also checks the assignment dimension itself — that it exists, and that it has exactly one driver property — which Weave does not, so a step the save refuses for that reason produces no Weave finding.

Step expressions. For any step that carries them, that every expression you have written — on a target column, in the Subset clause, or in the Secondary Filter clause — still compiles. A finding names the column or clause so you know which one to open, and gives the error, such as Syntax error at line 1, position 280. The expression itself is under How Weave knows, so a long one doesn’t bury the error. These are the same checks that run when you save the step.

Two cases Weave reports as unchecked rather than judging:

An expression that reads a variable. A step can belong to more than one workflow, and each workflow can set a variable to a different value — or not set it at all. The save gate knows which workflow you are saving from; a scan does not. Rather than pick one and risk calling a working expression broken, Weave reports the step as unchecked where the variable is not set everywhere, or is set to values that disagree. A workflow your role does not show you counts the same way: Weave cannot read its variables either, so it will not claim the step agrees. Where every workflow agrees, it judges the step normally.
Filters and column lists this check does not read. Some step types keep a filter or a second column list on a part of the form the expression check has never read — the two-table joins and Lookup, the allocation splits, Generate Batch, and SAP Post Journal Entry. Saving those steps has always skipped those fields, so Weave does not pass the step on the half it can read: it reports it as unchecked. Multi-Table Join and Delete steps are reported the same way, because their configuration is not in a shape this check can compile.

Something listed twice in a workflow. That no step and no nested workflow appears more than once in the same workflow, and that no two folders sharing a parent carry the same identifier.

How your workflows ran. Weave reads each workflow’s runs from the last 30 days — up to the twenty most recent runs of each workflow — and judges the latest against the ones before it. For the month-end and weekday comparisons below, it also reads a few older runs from the last 180 days. Every comparison is against the workflow’s own history, never against another workflow’s.

Last run failed. A workflow whose most recent run failed is reported, with the date of the failure and, where the runs before it failed too, how many in a row and since when.
Run slower than usual. A run that finished, but whose steps took longer between them than the workflow’s previous finished runs allow for — more than two standard deviations above their average, and at least 5% over it (never less than a second, so a fast workflow is not reported for a few milliseconds). The time is the steps’ added together, so on a workflow that runs steps in parallel it is more than the clock showed. A run that finished faster is not reported.
Target rows unlike previous runs. A step whose output tables held far more or far fewer rows after its last run than after its previous runs in that workflow, by the same measure (and by at least a row). The count is what the tables hold, so a step that appends is judged on the growing total. A step in several workflows is judged separately in each.
Join duplicated more rows than usual. An inner, left or right join that wrote more rows for each row of its main table than after its earlier runs in that workflow — more than two standard deviations above their average, and by at least 5% of it. The main table is Table A for an inner or left join and Table B for a right join. More than one row written per main-table row means some of its join keys appear on more than one row of the other table, so the rows that carry them were written more than once. Weave reports only a figure above 1.00, and only when it is above the join’s usual level, so a join that writes several rows per row by design is reported only if that number rises. For an inner join, only keys that repeat in Table B are seen. A join with fewer than four earlier runs that recorded its main table’s rows is reported as unchecked.

A join that aggregates, or uses Distinct, slicing (Limit) or a Secondary Filter, is reported as unchecked, because each changes the row count itself. So is a join whose main table has no recorded row count, such as a view. The main table’s rows are the ones recorded when it was last written, before the step’s filter on it. A filter that keeps a different share of its rows each run moves the figure too, and can be reported. A change made to the main table some other way, or by a step running at the same time, isn’t seen. Full outer, cross and Multi-Table joins aren’t checked, and a Lookup can’t write a row more than once.
Empty values unlike previous runs. A column of a step’s output table that came out empty in a much larger or smaller share of its rows than after the step’s previous runs — more than two standard deviations from the usual share, and at least five percentage points away from it. Each table a step writes is judged over its own rows.
Import found no files. An import step whose most recent completed run found no files at the path it reads from. The step ends with a warning rather than failing, and creates its target table empty or loads nothing, so the steps after it have nothing from it to read. The finding names the workflow and the path, needs no earlier runs, and clears once a run finds files. A step in several workflows is judged separately in each, and in a workflow you can’t open the path isn’t shown. Weave can’t tell a folder that is empty on purpose from a file that is missing: if an empty folder is normal there, a project Architect can mark the finding as expected, and Weave stops reporting it for that step in that workflow, whatever the path. A run recorded before this check existed doesn’t keep the warning’s wording, so its step is reported as unchecked until it runs again.

Month ends and weekdays. For a workflow or step that runs at most once a day, a run these checks would report is let off when it is in line with at least four earlier runs on the same kind of day, from the last 180 days, that vary no more, for their size, than its earlier runs on other days. The kinds of day are the last day of a month, the first day of a month, and otherwise the same day of the week. So a month-end load that is always heavy, or a load that always runs light on Mondays, isn’t reported when those runs are steadier for their size than the other days. The calendar only ever lets a run off: it never reports one these checks would pass. Days are counted in UTC, and public holidays and working-day calendars aren’t taken into account. A workflow or step that runs more than once on a day, a failed run and its rerun included, is compared with its earlier runs as before.

A baseline needs at least four previous runs. With fewer, the workflow is reported as unchecked for its run time, and its steps as unchecked for their rows and empty values, each saying how many finished runs it has had, rather than judged against too little. A step whose recorded runs carry no empty-value counts is reported as unchecked for them too. A workflow that has not run in the last 30 days is reported as unchecked, and so is one whose run history could not be read — neither is reported as healthy. On a project with Row Access declared, the rows, join, empty-values and spread-of-values checks do not apply to anyone whose reads are filtered: each is measured over the whole table, so a finding would tell them about rows beyond their grant. See Row Counts and Table Sizes.

What a step’s last run changed. For each table a step’s last run wrote, Weave compares the table as the run left it with the table as it stood before the run started, so it needs no history of earlier runs.

Values spread unlike before the last run. A column whose values spread across their range very differently after the run than before it. The finding gives a shift score: 0 means the spread did not change, and 0.25 or more is a large change, which is when Weave reports it. Only columns holding decimal numbers are compared. Whole-number columns are usually codes, periods or flags, such as an account number or a month, and their spread changes every time new periods load. Empty values are not part of the spread; the empty-values check above covers them.

“Before the run” is the last version of the table that held rows. A version left empty by a run that failed part-way is skipped, so the first good run after a failure is compared with the last good data.

A step’s run is reported as unchecked, with the reason, when a table it wrote:

has Row Access declared on its columns;
held more than 5,000,000 rows before or after the run;
took longer than 10 seconds to compare;
no longer keeps its version from before the run — some lakehouses keep earlier versions of a table for 7 days, so a table rewritten less often than weekly has nothing to compare against; or
was filled for the first time by that run.

A project whose lakehouse keeps no version history is not judged on this check at all.

Values left empty by a type conversion. Each column an Extract step writes has a type, such as text, integer or date, and the step converts every value to it. On a StarRocks lakehouse, a value that can’t be converted, such as N/A going into an integer column, is stored empty, and the run finishes without an error. After an Extract step runs on StarRocks, Weave counts, for each column whose conversion could lose values, the values going in that weren’t already empty and how many of them came out empty, and reports each column where any did. The finding gives the count and the column’s type. It judges the step’s latest completed run in each workflow, so it needs no earlier runs.

Values that were already empty going in aren’t counted. Blank text is, because it is stored empty in a number or date column.
A column whose conversion can’t lose a value, such as whole numbers going into a decimal column, isn’t counted, and neither is a column with no empty values after the run.
If the count takes longer than 30 seconds, or the rows Weave counts don’t match the rows the step wrote, the run is reported as unchecked, and Weave counts again the next time the step runs.
Only Extract steps on StarRocks are checked. A step that uses a Secondary Filter or groups by an expression is reported as unchecked, and so is one that uses Distinct or slicing (Limit) when a column could lose values, because Weave can’t count its rows again without the conversion.
If the step is meant to leave those values empty, a project Architect can mark the finding as expected.
Like the rows and empty-values checks, it doesn’t apply to anyone whose reads are filtered by Row Access.

Scheduled events. For a workflow with scheduled events, Weave compares each event with the runs it has started and with the job in the cluster that fires it. Each time is taken in the event’s own timezone, and a fire is judged 15 minutes after it came due, to give its job time to start.

Scheduled event timetable not valid. An enabled event whose schedule cannot be read.
Scheduled run did not start. An enabled event that has come due without starting a run — since it last started one, or since it was saved if it never has. Where the cluster can tell, Weave adds whether the cluster never fired the event or the job it fired failed. The finding names the last run the event started, or the time it was saved, so it stays one finding for as long as the event stays broken the same way. An event saved since its fire came due is not judged on that fire.
Scheduled event came due during a run. An event that came due while the workflow was still running, so no run started then. A scheduled event never starts a second run of a workflow that is already running; this is reported once so that a schedule tighter than the workflow’s runs does not lose fires unseen.
Scheduled event out of step with the cluster. An event and its job in the cluster that disagree: an enabled event with no job, or with its job paused; a disabled event whose job is not paused; or a job set to a different schedule or timezone than the event shows. Where the cluster cannot be read, the workflow is reported as unchecked for its scheduled events.

An event that has stopped starting runs has no run end to tell you about it, so it shows in the Weave tab rather than as a message.

Tables written on a schedule. For a table that a workflow with an enabled scheduled event writes, Weave checks that the table has been written since the schedule last came due. A table counts as written when a step that writes it finishes. Weave doesn’t look at the table’s data, so it doesn’t see a load made outside the project’s steps. As with the scheduled-event checks, each schedule is read in its event’s timezone and judged 15 minutes after it came due. Weave checks only the tables your role lets you see; without the analyze.table.read role it checks no tables, and its first line counts only steps and workflows.

Table not written on schedule. A table that no step has written since a workflow that writes it came due on its schedule. A write by any step counts, including one in another workflow or a run you started yourself. The finding gives the time of the last write rather than how long ago it was. A run that failed counts as not written, so a failing scheduled workflow’s tables are reported here as well as under Last run failed.

Weave reports a table as unchecked, with the reason, rather than as not written, when:

a workflow that writes it is running, is queued, or has just finished and its results aren’t recorded yet;
a step that writes it was skipped in a run since the schedule came due, either by its own conditions or because it found nothing to do, such as an import whose files hadn’t changed;
a step that writes it can be skipped without a record of the skip: it is in a Standard workflow with a condition that jumps to another step, or in a Standard Serial workflow with a step that goes to another step when it fails, or it sits in a container with conditions or in a loop that may run zero times;
the workflow finished a run since it was due, but the record of the writing step from that run is missing;
a step anywhere in the project picks the table it writes with a variable whose value Weave can’t work out, so it might write this table;
the schedule runs less often than every 180 days, which is as far back as Weave’s run history goes; or
a workflow’s schedule isn’t valid, or the run history can’t be read.

A table isn’t checked at all when:

it has no freshness threshold (below), and no workflow with an enabled scheduled event of its own writes it. A workflow that another workflow runs, through a Run Workflow or Macro step or as a workflow placed inside it, counts only through its own schedule;
the only steps that write it are disabled, sit in a disabled container, or sit at or after a breakpoint; or
it is a view.

The second of these doesn’t apply inside a loop that runs: a loop runs every step inside it, even one that is disabled, in a disabled container, or at or after a breakpoint.

A scheduled event saved after it last came due isn’t judged until it comes due again.

A workflow whose runs take longer than its schedule’s interval skips the fires that come due while it is running, so between runs its tables can be reported as not written; Scheduled event came due during a run reports the cause.

Where the step that last wrote a table is one you don’t have access to, the finding says “a step you don’t have access to” and still gives the time of the write. “180 days” in a finding is how far back Weave’s run history goes, not a fact about the table.

Tables with a freshness threshold. A freshness threshold is the most hours that may pass between writes of a table, from 1 to 4,320 (180 days). A table with a threshold is judged against it instead of against the schedules of the workflows that write it. That lets you set a looser or tighter bound than a schedule gives, and check a table that no scheduled workflow writes. As with schedules, a table counts as written when a step that writes it finishes.

Table not written within its set time. No step has written the table for longer than its threshold. The finding gives the time of the last write and the threshold.

Weave reports a table with a threshold as unchecked, with the reason, rather than as not written, when:

a workflow that writes it is running, is queued, or has just finished and its results aren’t recorded yet;
a workflow that writes it started a run after the threshold passed and finished it, but the record of the writing step from that run is missing;
a step anywhere in the project picks the table it writes with a variable whose value Weave can’t work out, so it might write this table;
no step in the project writes it, such as a table you load by hand, so Weave has no write to measure from; or
the run history can’t be read.

A skipped step doesn’t make a table with a threshold unchecked: the table still hasn’t been written for longer than its threshold. A view can’t have a threshold, and making a table a view clears its threshold. A copy of a table, or a table made from one of its snapshots, starts without one.

To set a threshold, select the table in the project’s Tables list and choose View/Edit Table Details. Under Freshness, select Warn if this table isn’t written for more than, enter the number of hours, and click Update. Clear the check box to remove the threshold. While no threshold is set, the box names the scheduled workflows whose schedules the table is judged on, or says that no workflow you can open writes it on a schedule. Freshness doesn’t appear for a view or for a table you’re creating, or without the analyze.workflow.read role, and changing it needs analyze.table.write.

You can also ask an AI assistant connected through PlaidCloud MCP to set the table’s freshness threshold (its tool is table_upsert, with freshness_max_age_hours), or call the platform API:

PUT /rest/v1/analyze/weave/freshness
{"project_id": "<project>", "table_id": "<table>", "freshness_max_age_hours": 24}

Send null in place of the number to clear it, and the table goes back to being judged on its writers’ schedules. GET /rest/v1/analyze/weave/freshness?project_id=<project>&table_id=<table> returns the threshold and scheduled_writers, the scheduled workflows whose schedules the table is judged on when it has no threshold. Reading a threshold needs the analyze.table.read and analyze.workflow.read roles, and setting one needs analyze.table.write and analyze.workflow.read. You can set a threshold only on a table your role lets you see, and not while the project is locked.

Tables a workflow reads, written to since. For a workflow that reads a table another workflow writes, Weave checks that no other workflow has written to the table since the workflow last read it. A table counts as read or written by a step that names it as an input or an output and finished in a run. Weave reads what the run history records, not the table’s data.

Reads a table written to since its last read. A workflow last read a table in one of its runs, and a different workflow has written to that table since, so its results may be out of date. The finding names the run that last read the table and the workflows that wrote to it. A workflow with an enabled scheduled event, or one that another workflow with one runs, is reported only once a schedule that runs it has come due after the write; a workflow nothing runs on a schedule is reported straight away.

These aren’t counted as written to since:

a write by the workflow itself, including one made during its run by a workflow it runs through a Workflow: Run, Workflow: Loop or Workflow: Conditional Run step;
a table the workflow writes in a run before any step in that run reads it, such as a staging table, unless the write was by a Table: Append or Table: Upsert step, or by a Table: In-Place Delete step with a filter, which keep the table’s other rows; and
a write made before the step that made it was last saved, since the step may have written to a different table then.

Weave reports the workflow as unchecked, with the reason, rather than as behind, when:

it is running, or has just finished and its results aren’t recorded yet;
a step that reads the table was skipped in a run after the write;
the schedule that runs it isn’t valid;
none of its recent runs finished reading the table, while another workflow wrote to it or may have;
a step that reads the table has been saved since its last successful run started, so Weave can’t tell whether that run read it. Any save counts, even one that changes nothing the step reads;
one of its steps reads tables Weave can’t work out from the step’s settings, such as an AI: LLM Step, a Report step, a Run: Remote Python step, or a step that reads several tables and finds one of them by search, as a Table: Union Distinct or Table: Union All step can; picks a table with a variable; names a table by a name more than one table has; reads a view; or reads a table in another project;
a table it reads is also written to by a macro, whose runs Weave doesn’t see, or by a step in another workflow that has run since and picks the table it writes with a variable, names it by a name more than one table has, or writes tables Weave can’t work out; or
its run history can’t be read.

A workflow with no runs in the last 30 days isn’t checked this way.

What this check doesn’t see:

reads and writes older than the run history Weave reads, which is the last 30 days and, for each workflow, its last 20 runs;
a step’s condition that checks a table, which doesn’t count as reading it;
a write by another workflow to a table the workflow adds rows to and then reads in the same run, unless it adds them with a Table: Append or Table: Upsert step;
an earlier read by one step where another step of the workflow read the same table more recently;
a write inside a macro by a step that picks its table with a variable or writes tables Weave can’t work out; and
writes made before the writing step was last saved, even where the save changed nothing it writes, until its workflow runs again.

Without the analyze.table.read role no workflow is checked this way. Where a workflow or table that wrote or was read is one you don’t have access to, the finding says “a workflow you don’t have access to” or “a table you don’t have access to”, without saying how many.

A step whose type Weave has no rule for is reported as uncovered, not as clean.

Unusual metric totals. Each day Weave reads your project’s approved metrics and reports one whose latest finished period came out far from usual, naming the item, such as a customer or a plant, behind the change. See Unusual Metric Totals.

Reviewing one workflow

A review checks one workflow before you rely on it. It runs Weave’s checks on the workflow and its steps, including the steps of any workflow it runs, and three more that Weave runs only in a review, because they read more than the Weave tab can afford to read every time it opens:

An allocation that feeds its own inputs. For each allocation step the workflow runs, whether what it writes flows back — through any steps, in any workflow — into the table it allocates or its driver table. When it does, how much the step allocates, or how it spreads it, depends on what it allocated on an earlier run. Weave names the steps the loop runs through and asks you to check whether the loop is intended. A loop that runs through no allocation step, such as an incremental load that reads the table it appends to, is not reported.
Allocation driver tables and columns. Whether the driver table an allocation step uses exists, and has every column the step reads from it. A driver column the step fills with a constant or an expression is not looked for. A driver table built anywhere else is checked as it stands now; when a step in this workflow builds it, its columns aren’t known until that step runs, so Weave reports the allocation as unchecked rather than passed. It reports the allocation as unchecked, too, when the step picks its driver table with a variable or a folder path, when the workflow is a macro, and when your role can’t see the table.
Row-level security on a renamed column. For each table the workflow writes, whether it has a column tagged with the dimension a row-level security attribute uses but not named after that attribute. Row-level security filters only on columns named after its attributes, so it doesn’t filter on that column. This check needs the Architect role on the project; for anyone else the review says it wasn’t checked, and so it does for a table the workflow names with a variable or a folder path.

A review opens by saying what it found and over how much of the workflow, and never ends on a clean bill:

Weave found 2 problems in the workflow "Q3 Close". It couldn't finish checking 1
of its 8 steps (listed below), so it may have missed problems in those. See below
for what these checks don't cover.

Weave noticed the step "Allocate rent": it uses the column "sq_ft" from its driver
table "Floor space", which doesn't have that column. Pick a column the table has,
or add "sq_ft" to it.
Weave noticed the step "Allocate IT cost": its output flows back into its driver
table "IT driver" through "Build IT driver", so how it spreads what it allocates
depends on what it allocated on an earlier run. Check whether that loop is
intended.
Weave hasn't checked the step "Allocate IT cost" — whether its driver table
"IT driver" has the columns it uses: the step "Build IT driver" builds that
table, so its columns aren't known until that step runs.

Steps your role can’t see count towards the total, and the review says it didn’t check them.

A review lists what it does not check. It doesn’t run Weave’s checks on tables — whether a table written on a schedule is late, and whether a table the workflow reads has been written to since — which read the whole project and run in the Weave tab. For a workflow with allocation steps, it doesn’t check whether every amount being allocated finds a matching driver row or dimension member, whether the source and driver tables hold figures at the same level of detail, or loops that run through a step naming its table inside SQL or with a variable.

To review a workflow, open it on its canvas or its Steps grid and choose Check. The button is there for people who can edit the workflow and read the project’s tables. The Weave Check window shows, in order:

the review’s opening lines;
Summary (written by AI), when the review has a summary;
the review’s Problems, then what it Couldn’t check. A problem the summary points to is marked In the summary, and Go To beside a step’s finding selects that step where you chose Check;
What this check doesn’t cover, always last.

Choosing Check again runs a new review in the same window.

You can also ask an AI assistant connected through PlaidCloud MCP to review a workflow — its tool is workflow_review — or call the platform API. A review needs read access to the project’s steps, workflows and tables. The three checks above don’t appear in the Weave tab; Weave runs them only in a review.

In the Weave Check window and through the platform API, a review that finds problems also carries a summary of one or two sentences written by PlaidCloud’s built-in AI, and up to three of its problems to look at first. The AI is shown only the review’s problems. Before the summary is returned, the problems it points to must be the review’s own, any name it quotes and any digit it writes must appear in those problems, and it may not use a phrase such as “no other problems”. A summary that fails is dropped, and the review comes back without one. A review with no problems has no summary. Through an AI assistant, the review has no summary; the assistant reads the findings itself.

Being told when a run ends

When a workflow run ends, Weave looks at that workflow and tells each problem’s owner — see Give a Finding an Owner — about the problems it holds against that workflow, its runs and its steps’ saved configuration alike, that they have not yet read in the project’s Weave tab, as an in-app message. A problem with no owner, or whose owner can no longer see it, goes to the person the run belongs to: the person who started it, or for a scheduled run the person who last saved the schedule. Each problem is mentioned once. While you haven’t read it in the Weave tab, later runs don’t mention it again, so a Workflow Loop that runs many workflows doesn’t fill your screen with repeats. The count on the Weave button keeps it until you read it.

The message stays on screen for 30 seconds and has an Open Weave link, which opens the project’s Weave tab on the findings about the workflow that ran. Click anywhere else on the message to close it.

After you read a problem, it is mentioned again only when what it says changes. A run finding describes the run it came from — its date, its time, its counts — so a workflow that fails every night is mentioned again on the next failure after you read the last one. A configuration problem says the same thing from run to run, so once you have read it, it is not repeated with each run.

A stopped run sends nothing, whoever stopped it. A workflow run by a Macro Run or Macro Concurrent step sends nothing of its own, and that call is not counted among its runs; a workflow started by a Run Workflow or Workflow Loop step is a run of that workflow like any other. Things Weave could not check are never sent this way, and neither are findings about tables written on a schedule or about a workflow’s tables written to since it read them: Weave tells those between runs. See Being told between runs.

Being told is not the same as having read: an alert does not mark the finding read in the Weave tab, and neither does following its Open Weave link.

Each problem a message tells you about is added to the count on the Weave button in the header. See The Weave Button in the Header.

Being told between runs

Some problems appear with nothing running: a table that hasn’t been written on its schedule or within its freshness threshold; a scheduled run that didn’t start, or that came due while the workflow was still running; and a workflow whose tables another workflow has written to since it last read them. No run’s end can tell you about these, so once an hour Weave checks each project for them and tells each problem’s owner — see Give a Finding an Owner — as an in-app message.

The hourly check tells you about each of these problems once, however many checks find it, and its first check of a project tells you about those already there, however long they have stood. It tells you again only after the problem has gone and come back, or after you have read it and what it says has changed, such as a later scheduled run that didn’t start either. A schedule problem is also among a workflow’s own checks, but once the hourly check has told you about it, the message when the workflow’s next run ends doesn’t repeat it until you have read it — see Being told when a run ends. Several problems in one project come as one message, which counts them and quotes the first:

Weave noticed 3 problems in the project “Finance Close”, starting with the table “Sales Daily”: the step “Load Sales” last wrote it on 14 Oct 06:00 UTC, and the workflow “Nightly Load” has been due to run on its schedule since then

A table that more than one workflow writes has no owner until someone assigns one. When it hasn’t been written on schedule, Weave tells the owner of each workflow that was due to write it and didn’t. Any other problem with no owner isn’t sent; it is listed in the project’s Weave tab.

The check runs as each owner, so a message names only what your role lets you see. You are told only as an active member of the project whose role lets you see its steps and workflows, and about tables only if you can read tables.

The message stays on screen for 30 seconds and has an Open Weave link, which opens the project’s Weave tab, on the workflow when every problem in the message is about the same one. A message is only shown while you are signed in, but each problem it tells you about is added to the count on the Weave button in the header, so one you missed is still counted there. Being told doesn’t mark a finding read.

Marking a finding as read

Each finding carries an id, and you can mark it read so it stops appearing as new — in the project’s Weave tab, click Mark Read on its card (see Mark Findings as Read). The id is derived from the finding itself, so a finding you dismissed comes back as new if the underlying problem changes — a step you marked read after fixing one column reappears if a different column later goes wrong.

Read state is yours alone. Marking a finding read does not mark it read for anyone else on the project.

While a workflow that writes a late table is running, Weave reports the table as unchecked instead. If you mark any finding read during that time and the run ends without writing the table, its finding comes back as new.

Two different steps listed twice in one workflow are two findings, so marking one read leaves the other unread. A workflow with no name appears as “unnamed workflow”, and a check that could not run is named by its title, such as “Last run failed”.

A digest

A digest is the same report reduced to what you have not already read, in the same voice. You can ask for one at any time, and you can have it delivered as an in-app notification, with an Open Weave link to the project’s Weave tab.

Findings Weave could not check are part of a digest like any other. A digest that quietly dropped them would be exactly the reassuring silence the third answer exists to prevent.