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.

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.

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. 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. 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.
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.

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, 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.

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 column and the Weave tab rather than as a message.

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

Being told when a run ends

When a workflow run ends, Weave looks at that workflow and tells the person the run belongs to — the person who started it, or for a scheduled run the person who last saved the schedule — 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 message is only shown while you are signed in, so a problem you have not read is mentioned again at each run’s end.

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.

Reading a finding quiets that finding, not the workflow. A run finding describes the run it came from — its date, its time, its counts — so the next run’s is usually a new finding: a workflow that fails every night is mentioned every night, whether or not you read the night before’s. 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.

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.

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, select it and click Mark Read (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.

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.