Custom Rule Conditions and Missing Data

A condition is one comparison inside a custom rule's when block, and a rule fires only when its conditions match. This page covers how to write conditions for custom strategies on Kalshi, Polymarket and Polymarket US, then what happens when the data a condition reads is missing. For where conditions sit in a rule and how rules are checked each tick, see Rule anatomy and How rules are evaluated.

Conditions

Condition keys

No other keys are allowed in a condition (unsupported condition key "operator" (allowed: field, op, value, value_field)). A condition must be a mapping, so a string such as "price < 0.4" is a YAML error.

all and any

when holds exactly one group:

• all matches when every condition is true (AND). Two conditions on the same field make a band, such as price >= 0.30 and price <= 0.40.
• any matches when at least one condition is true (OR).

Setting both gives set exactly one of all/any, not both; setting neither, or only empty lists, gives set at least one of all/any. Other group names (none, not) are rejected. Groups do not nest: an any inside an all list is rejected. To express "(A and B) or C", write two rules with the same action.

YAML anchors work if you want to reuse a condition. Define it once with - &flat {field: position_size, op: "==", value: 0} and reuse it in another rule as - *flat. Merge keys (<<:) are rejected inside rules and conditions.

Operators

Always quote operators. In the one-line {field: ..., op: ..., value: ...} style used throughout the Custom Rules docs, an unquoted >, >= or != is a YAML error. Written on its own line (op: >), an unquoted > or != is read as empty (unknown operator "") and >= is a YAML error. Anything else, such as =, => or contains, gives unknown operator.

There are no crossover operators in custom rules. == and != compare exactly, so prefer ranges for computed values like price and unrealized_pnl: price >= 0.50 is safer than price == 0.50. A comparison with an unavailable value is always false, whatever the operator.

value and value_field

value is a plain number. Write value: 0.4, not value: "0.4"; a quoted number is rejected with price requires a numeric value (got string) — remove the surrounding quotes. Booleans, null, .inf and .nan are rejected too. There are two exceptions: time_to_expiry takes a duration string, and a text edge field takes one of its text values.

Units matter, and most mistakes here are unit mistakes:

• Prices and spreads are dollars per contract, from 0 to 1. Write 0.40 for 40 cents. price > 40 can never be true and is rejected as contradictory; price < 40 is always true.
• unrealized_pnl and balance are dollars. P&L covers the whole position, not one contract.
• position_size, order_count and size are counts of contracts, shares or orders.
• Edge fields use their provider's units. NWS humidity and precipitation probabilities are fractions (0.70, not 70), and values outside 0 to 1 are rejected for them.

value_field compares two live fields read from the same snapshot, for example yes_best_ask against no_best_ask, or a Coinbase price against its EMA. Both sides must be numeric fields allowed on your venue. Setting both value and value_field is rejected (exactly one of value or value_field must be set, not both), and so is setting neither.

Studio does not check units across a value_field comparison. Comparing a dollar field with a seconds field saves, so make sure both sides mean the same thing. Behavior validation also cannot analyze value_field conditions; see What the checker cannot see.

Durations for time_to_expiry

time_to_expiry is the only built-in field that takes a duration string instead of a number: a whole number followed by one lowercase unit.

Invalid forms and their errors: a bare number such as 3600 (time_to_expiry requires a duration string (e.g. "6h")), "300" with no unit (unknown duration unit "0" in "300" (want s|m|h|d)), decimals such as "1.5h" (invalid duration magnitude "1.5"), and compound, weekly or uppercase units such as "1h30m", "1w" or "2H". Write "90m" instead of "1h30m". Durations are converted to seconds when the strategy is compiled.

Edge fields measured in seconds, such as the economic calendar's seconds_to_next, take plain numbers, not duration strings.

Missing or unavailable data

Most missing data fails closed: rules on that data stay off rather than trading on a guess. A few values fall back to a number instead, and those are listed under Unavailable values. How that plays out depends on what is missing.

Unavailable values

A single value can be unavailable for a tick, for example a side of the order book that is empty, or an edge value the provider could not compute (a late Coinbase candle, an NWS forecast outage). Every comparison with an unavailable value is false, whatever the operator, including !=, and that applies to either side of a value_field comparison. The condition fails, so an all rule does not match; an any rule can still match through its other conditions. Later rules still run. Backtests behave the same way.

Some fields fall back to a number instead of going unavailable:

NWS alert and forecast-text fields also fall back rather than going unavailable: during an alert outage alert_active reads 0, and during a forecast outage precip_amount_in reads 0. See Edge Data.

When entries are blocked

Some situations block only new entries. Rules are still evaluated: a matching buy_yes, buy_no or composite orders rule is skipped with a blocked decision, and the rules below it, exits included, still run.

An exit whose own conditions read the missing edge or derived value can't fire until it is back, because those conditions are false; exits on price, the book, position or P&L run as usual. Watch data freshness in Monitoring.

When the tick is skipped

Two situations stop rule evaluation for a market altogether:

The decision log records why the tick was skipped.

Errors end the tick

If reading the market or your account fails (a venue API error, for example), or a rule raises an error while being evaluated or executed, the rest of that market's tick is abandoned: no later rule runs, including exits. The next tick starts fresh. On a Kalshi series, other markets in the same cycle still run. On Polymarket, a failed read of the trade history behind unrealized_pnl does not end the tick: P&L reads as unavailable and the other rules still run.

Rule-level causes of errors to avoid: a Kalshi sell with no bid on that side, a Kalshi buy while either side of the book is empty, any Kalshi order while the market's most recent trade is more than 120 seconds old, a Kalshi or Polymarket US buy larger than your Max contracts per order, and a Polymarket US sell_all with no bid to sell into.