Entry rules are organized into three blocks: long, short, and filters. The engine evaluates them on every closed bar (or every minute, if any condition is on-tick - see Evaluate mode).

The blocks

long - conditions that, when satisfied, open a long position. Has its own logic field (AND or OR) and a list of conditions.
short - same shape as long, but opens a short. A strategy can define long only, short only, or both. If both fire on the same bar the engine ignores the conflict and takes neither.
filters - optional, sit outside long/short. Every filter must be true for either side to fire. Use them for regime conditions like "ADX > 20" or "outside the weekend" that apply to both directions.

Logic: AND vs OR

The logic field inside long or short decides how that block's conditions combine:

AND - every condition must be true on the same bar. Use when you want multiple confirmations.
OR - any one condition firing is enough. Use when you have several independent signals that should each open a trade.

Filters always AND with the side block, regardless of the side's own logic. The full picture:

fire_long  = (long.logic apply to long.conditions) AND (all filters true)
fire_short = (short.logic apply to short.conditions) AND (all filters true)

Condition shape

Every condition has a type. The type decides what other fields it accepts. The most common types:

Type	What it tests
`comparison`	indicator vs value or another indicator (`>`, `<`, `>=`, `<=`, `==`)
`crossover`	one indicator crosses another (`above` / `below`)
`threshold`	a value above or below a bound
`in_range`	indicator inside `[min, max]`
`price_distance`	price within N% of an indicator
`trend_change`	the trend detector just flipped
`price_in_supply_demand_zone`	live price inside the nearest active zone

The full reference lives under Conditions.

Order doesn't matter

The engine evaluates every condition on every bar. There is no short-circuiting based on the order you list them. Put the most important (or readable) condition first for clarity, not performance.

Trend detection is separate

trend detection is its own top-level block. It runs before entry conditions and produces a bull/bear/sideways label. You can reference it from an entry rule with { "type": "trend_change" }, or ignore it entirely by setting trend_detection.method to none. See Trend detection methods when that article ships.

Common mistakes

Mixing concerns in long.conditions that should be filters. If a condition applies equally to long and short (e.g. "session is active"), move it to filters. Easier to read, easier to maintain.
Using OR when you wanted AND. OR is rare in practice. If you find yourself with five OR conditions, you probably want five separate strategies, each with one AND-only rule.
Forgetting that on-tick conditions skip the bar-close cadence. An on-tick condition re-evaluates the whole rule every minute. If one condition needs on-tick semantics, accept the runtime cost.