Overview
The Validation node is a data preparation node in a Weave workflow that checks rows against one or more filter criteria and produces output based on the chosen Validation Status. Each validation rule has a Name (descriptive identifier), Criteria (filter expression built in the standard Filter Criteria popup), and Validation Status (Skip or Fail). Skip drops matching rows and emits the remaining data with the original schema; Fail emits a single Message column with a validation report when matching rows are detected.
Validation nodes are added from the Data Preparation category of the node panel. The Filter Criteria popup launched from the Criteria column uses the same UI structure as the Filter node — Column / Filter Condition / Input / Action / Add Group / Delete Group — and may expose an extended operator set beyond the canonical 13.
Note: “Weave” is the current name for what earlier interface versions called “Workflow.” This reference uses “Weave.”
When to use it
- Enforcing data quality rules — “no records with null email”, “no records with negative balances”, “no records with invalid status codes”. Use Fail status to report violations; Skip to clean them out silently.
- Producing named, auditable validation reports that downstream nodes can consume — the Fail output is a structured Message containing the rule name, criteria, and failure count.
- Multi-rule data quality gates — configure several validation rules in one node, each independently evaluated and reported.
- Pre-production data quality checks — run validation rules before destination writes to catch data issues at pipeline boundaries.
Validation rule structure
Each validation rule has four columns in the Validation popup. Multiple rules can be added via the Action + button.
| Column | Description |
| Name | Required. Descriptive identifier for the rule (e.g., “Sepal_length_valid”). Appears in the Fail output as the Validation_name field. Use distinct, meaningful names — they’re how Designers and downstream consumers identify which rule fired. |
| Criteria | Required. Filter button (labeled “Filter” or “Configure Filter” depending on UI version) opens the Filter Criteria popup. Build the criteria using the same Column / Filter Condition / Input row structure as the Filter node. |
| Validation Status | Required. Dropdown with two options: Skip and Fail. Determines how the node handles matching rows. |
| Action | + icon (add another rule row) and delete icon (remove this rule). |
Filter Criteria UI
Validation rules use the same Filter Criteria popup structure as the Filter node — Column / Filter Condition / Input / Action / Add Group / Delete Group. The Filter Condition operator set may extend the canonical 13 operators with additional comparisons.
| Operator | Source |
| Equals, Not Equals, In, Not In, Less Than, Greater Than, Less Than Or Equal To, Greater Than Or Equal To, Like, Empty, Not Empty, Null, Not Null, Starts with, End with etc., | The canonical 13 and more. |
Key behaviors
Multiple rules per node. The Action + button adds additional validation rules within a single Validation node. Each rule has its own Name + Criteria + Validation Status configuration.
Filter Criteria UI may extend the canonical operator set. Validation popup’s Filter Criteria UI show operators beyond the canonical 13 — including Contains, Not Like, Starts With, Ends With. The Filter node article remains the canonical reference for the 13-operator set; this article notes the extended operators visible in the Validation context.
Use Validation for data quality gates; use Filter for general row selection. Validation’s distinguishing features over Filter are: explicit rule Names (documenting intent), the Fail Validation Status (producing audit reports), and multi-rule support (running several checks in one node). For simple row selection without these requirements, use the Filter node — Validation in Skip mode does the same thing as an inverted Filter, but adds overhead the simpler use case doesn’t need.