Clay Conditional Gates

What it does

A run condition is the cheapest performance work in Clay and the most commonly skipped. This skill turns a qualification rule stated in plain language into the exact condition expression, placed on the right column, in the right order, with the pass rate estimated so the saving is known before the run.

When to use it

• add a run condition
• skip enrichment for non ICP rows
• gate this column
• only enrich rows that
• stop paying to enrich junk

What it needs from you

• rule: the qualification rule in plain language
• available: which columns already exist and are cheap enough to gate on
• target: the expensive column that should be gated

How it works

1. Restate the rule as a boolean over columns that already exist. If it needs a column that does not exist yet, say so and place that column first in the order.
2. Prefer a deterministic cheap column over a model judgment for the gate. A gate that costs as much as the column it guards saves nothing.
3. Write the condition expression, and write the negative case explicitly so blank values do not silently pass.
4. Estimate the pass rate from the user's own data if they have any rows, from a stated assumption if they do not.
5. Order multiple gates so the highest rejection rate runs first.
6. State what happens to rejected rows: left blank, tagged, or moved. Blank is a choice, not a default.

What you get back

The condition expression per column, the placement in the run order, the estimated pass rate, and the resulting cost change.

The quality bar

• Blank and null inputs are handled explicitly in every condition
• No gate costs more per row than the column it guards
• Gates are ordered by rejection rate
• The fate of rejected rows is stated

Where it runs

• Claude Code
• Codex CLI
• Cursor
• MCP-compatible agents