YAML Reference

Written By Axiom Admin

Last updated About 1 month ago

YAML Reference

This page documents every field the engine accepts in each YAML section, what each field does, and why you would use it. If you want to understand how the pieces interact — how setups gate entries, how exits target entry groups, how the state machine flows — read Rules & Risk first. This page is the field-level reference. It tells you what you can write. Rules & Risk tells you what it means.

For the expression syntax used in condition and price fields, see Expression Reference. For the list of token names you can reference, see Default Tokens.

When examples use names like EMA_200, EMA_20, RSI_K, or ATR_14, assume those are custom tokens you connected from indicators on your chart. They are not built in.

YAML structure basics

Each YAML section is a list of items. Each item starts with a dash (-) at the root indent level, followed by key-value fields indented beneath it. The dash is required — it tells the parser where one item ends and the next begins.

Example
- setup_name: MY_SETUP
  setup_active_when: PRICE_CLOSE > EMA_200
  setup_confirm_count: 3

- setup_name: ANOTHER_SETUP
  setup_active_when: VOLUME > 1000000

Indentation matters. Fields must be indented consistently under their item dash. The parser uses indentation to determine which fields belong to which item. Tabs are automatically normalized to two spaces, so tabs will not cause parse errors — but using spaces explicitly is still recommended for consistency. Two-space indentation is conventional.

Colons separate keys from values. setup_name: MY_SETUP is a key-value pair. The space after the colon is not strictly required (the parser trims whitespace from both key and value), but including it is conventional and improves readability.

Comments. Lines containing # are stripped from that character onward. This applies blindly — the parser does not distinguish between # in a comment and # inside a value. Avoid using # in expression strings.

Expression fields can span multiple lines. If an expression is complex, you can continue it on the next line with additional indentation:

Example
- entry_name: COMPLEX_ENTRY
  entry_trigger_when:
    PRICE_CLOSE > EMA_50
    && RSI_K < 30
    && VOLUME > VOLUME[1] * 1.5

The parser collects continuation lines (indented deeper than the field key) and joins them into a single expression string. This is purely for readability — the engine sees one expression.

The four sections

Your strategy is defined across four section types per direction. Long and short are independent — you write them in separate input fields.

Section	Input field	What it defines
Setups	Long Setups / Short Setups	Market regime filters that gate when entries can evaluate
Entries	Long Entries / Short Entries	Order submission logic — when and how to get in
Take Profits	Long Take Profits / Short Take Profits	Profit-taking exit logic
Stop Losses	Long Stop Losses / Short Stop Losses	Protective exit logic

Each section is pasted into its corresponding text area in the Inputs tab. You can leave any section empty. A strategy with only entries and no setups will use the implicit GLOBAL setup (always confirmed). A strategy with entries but no exits will rely on direction reversals or manual close logic.

Setups section

Setups define when a trading window opens. They do not submit orders — they control whether entries belonging to them are allowed to evaluate. Think of a setup as a regime filter: "the market is in a state where my thesis applies."

Every named setup follows the state machine described in Rules & Risk: INACTIVE → CONFIRMING → CONFIRMED. Entries only fire when their owning setup is CONFIRMED.

Setup fields

Field	Required	Type	Default	What it does
`setup_name`	Yes	Text	—	Unique identifier for this setup. Used by entries in `entry_belongs_to_setup` to declare ownership. Also generates dynamic state tokens (`<NAME>_CONFIRMED`, etc.) that other expressions can reference.
`setup_gate_condition`	No	Expression (boolean)	`true`	A prerequisite that must be true before activation can begin. If the gate is false, the setup stays INACTIVE regardless of the activation expression. Think of it as a master switch.
`setup_active_when`	Yes	Expression (boolean)	—	The primary activation trigger. When the gate passes and this expression is true, the setup transitions toward CONFIRMED (directly if no confirmation is configured, or through CONFIRMING if it is).
`setup_confirm_type`	No	`BAR_COUNT` or `NUM_TICKS`	`BAR_COUNT`	How confirmation is measured. `BAR_COUNT` counts confirmed bars. `NUM_TICKS` counts script evaluation ticks.
`setup_confirm_count`	No	Integer (>= 0)	`0`	How many bars (or ticks) the activation expression must remain true before the setup reaches CONFIRMED. `0` means no confirmation delay — the setup goes directly from ACTIVE to CONFIRMED.
`setup_cancel_when`	Yes\*	Expression (boolean)	—	Forces the setup back to INACTIVE when true. All attached entries stop evaluating. If `close_on_cancel` is true, open positions from this setup's entries are also closed.
`setup_cancel_confirm_type`	No	`BAR_COUNT` or `NUM_TICKS`	`BAR_COUNT`	How cancel confirmation is measured.
`setup_cancel_confirm_count`	No	Integer (>= 0)	`0`	How many bars the cancel expression must persist before the cancel takes effect. `0` means immediate cancel.
`setup_close_on_cancel`	No	`true` or `false`	`false`	When true, cancelling this setup also closes all open positions from entries that belong to it and cancels their pending orders. This is how you implement "exit everything when the regime changes."
`setup_cooldown_bars`	No	Integer (>= 0)	`0`	After a cancel or reset, the setup stays INACTIVE for this many bars before re-activation is allowed. Prevents rapid re-entry after a failed activation.
`setup_max_entries_per_activation`	No	Integer	None (unlimited)	Caps how many entry fills this setup allows during a single activation window. Once reached, no more entries fire until the setup resets and re-activates.
`setup_reset_when`	Yes\*	Expression (boolean)	—	A hard reset. Clears all counters, latches, and confirmation progress. Forces INACTIVE. More aggressive than cancel — use it when you want a clean slate.

\* At least one of setup_cancel_when or setup_reset_when must be provided. You need not provide both, but one of them is required. Without either, the engine has no way to exit the setup, and validation will reject the YAML.

Why you would use each field

setup_gate_condition — Use this for slow-moving, broad filters. A 200-bar EMA direction, a volatility regime check, a session time window. The gate must be true before the activation expression is even considered. This separates "the environment is right" (gate) from "the specific trigger fired" (activation).

setup_confirm_count — Use this when your activation condition is noisy. A single bar above the EMA is a spike. Three consecutive bars above the EMA is a trend establishing. Confirmation turns a momentary signal into a persistent one. Start with small counts (2–3 bars) and increase only if you are filtering too few false activations.

setup_cancel_when — Use this to close the trading window when the regime changes. If your setup activates on an uptrend and you want to deactivate when the trend breaks, the cancel expression defines that break. At least one of setup_cancel_when or setup_reset_when must be present — the engine requires a defined exit path for every setup.

setup_close_on_cancel — Use this when a regime change means existing positions are no longer valid. If the setup represents "we are in an uptrend" and the uptrend breaks, you may want to not only stop new entries but also close any open trades that were entered under the uptrend assumption.

setup_cooldown_bars — Use this to prevent whipsawing. After a cancel, the setup must wait before re-activating. This is useful when the activation and cancel conditions are close together — without cooldown, the setup can oscillate between CONFIRMED and INACTIVE on every bar, producing chaotic entry behavior.

setup_max_entries_per_activation — Use this to limit how many times you enter during a single setup window. If your setup represents a daily trading window and you only want two entries per day, set this to 2. The cap resets when the setup re-activates after a cancel or reset.

Minimal setup example

Example
- setup_name: TREND_FILTER
  setup_active_when: PRICE_CLOSE > EMA_200
  setup_cancel_when: PRICE_CLOSE < EMA_200

This creates a setup that reaches CONFIRMED whenever price is above the 200 EMA (assuming EMA_200 is a custom token), and cancels when price drops below. No confirmation delay, no cooldown. Entries belonging to TREND_FILTER can evaluate on any bar where price is above the EMA.

Full setup example

Example
- setup_name: TREND_FILTER
  setup_gate_condition: TF_ISDAILY
  setup_active_when: PRICE_CLOSE > EMA_200
  setup_confirm_type: BAR_COUNT
  setup_confirm_count: 3
  setup_cancel_when: PRICE_CLOSE < EMA_200
  setup_cancel_confirm_count: 2
  setup_close_on_cancel: true
  setup_cooldown_bars: 5
  setup_max_entries_per_activation: 3

This setup only evaluates on daily charts (gate), activates when price holds above the 200 EMA for 3 consecutive bars, cancels when price holds below for 2 bars (closing all positions on cancel), waits 5 bars before re-activating, and allows up to 3 entries per activation window.

Entries section

Entries define when and how to submit orders. Each entry belongs to a setup (explicitly via entry_belongs_to_setup, or implicitly to GLOBAL if not specified).

Entry fields

Field	Required	Type	Default	What it does
`entry_name`	Yes	Text	—	Unique identifier for this entry. Generates dynamic state tokens. Used as the order ID basis in the trade list.
`entry_belongs_to_setup`	No	Text	`GLOBAL`	The setup this entry is attached to. The entry can only evaluate when this setup is CONFIRMED. Must match a `setup_name` exactly (case-sensitive).
`entry_gate_condition`	Yes	Expression (boolean)	—	A prerequisite for this specific entry, independent of the setup's gate. Both the setup and the entry gate must pass for the trigger to be checked. Even if you want the gate to always pass, you must write it explicitly (e.g., `PRICE_CLOSE > 0`).
`entry_trigger_when`	No	Expression (boolean)	`true`	The primary entry signal. When the gate passes and this expression is true, the engine proceeds to order construction. If omitted, the entry fires every bar the gate passes.
`entry_confirm_type`	No	`BAR_COUNT` or `NUM_TICKS`	`BAR_COUNT`	How entry confirmation is measured.
`entry_confirm_count`	No	Integer (>= 0)	`0`	How many bars the trigger must persist before the order is submitted.
`entry_order_type`	Yes	`MARKET`, `LIMIT`, `STOP`, or `STOPLIMIT`	—	The order type submitted to the broker emulator.
`entry_allocation_percent`	Yes	Number (0–100)	—	This entry's share of the Properties tab default position size. The engine calculates quantity as `default_qty * (allocation_percent / 100)`. All entry allocation percentages in a direction must sum to 100%. A single entry should be set to `100`. Two equally-sized entries should each be `50`. See Entry sizing below.
`entry_limit_price`	No	Expression (numeric)	—	The limit price for LIMIT and STOPLIMIT orders. Required when `entry_order_type` is LIMIT or STOPLIMIT.
`entry_stop_price`	No	Expression (numeric)	—	The stop price for STOP and STOPLIMIT orders. Required when `entry_order_type` is STOP or STOPLIMIT.
`entry_lock_prices`	No	`true` or `false`	`false`	When true, limit and stop prices are captured once (when the trigger first fires) and held constant. When false, prices recalculate every bar.
`entry_id`	No	Text	Same as `entry_name`	The entry group identifier. Exits use `from_entry_id` to target a specific entry group. If you want multiple entries to share exit logic, give them the same `entry_id`.
`entry_oca_group`	No	Text	None	OCA (One-Cancels-All) group name. Entries sharing an OCA group are mutually exclusive — when one fills, the others are cancelled.
`entry_expire_after_bars`	No	Integer	None	How many bars a non-MARKET order can remain working before it is automatically cancelled.
`entry_cancel_when`	No	Expression (boolean)	None	Cancels a pending (unfilled) order when this expression becomes true. Only relevant for non-MARKET orders that are working.
`entry_one_shot`	No	`true` or `false`	`true`	When true, the entry fires once per setup activation and does not re-submit. When false, the entry can fire multiple times (pyramiding).
`entry_pyramiding_max_adds`	No	Integer	None	Maximum additional fills allowed when `entry_one_shot` is false. Total fills = 1 (initial) + this number.

Entry sizing: how allocation works

entry_allocation_percent does not set a percentage of equity directly. It sets a percentage of the Properties tab default position size. The engine computes entry quantity as:

quantity = default_entry_qty(price) * (entry_allocation_percent / 100)

Where default_entry_qty comes from TradingView's Properties tab (e.g., "10% of equity" or a fixed contract count).

If your Properties tab says "10% of equity" and you set entry_allocation_percent: 50, the entry gets 50% of 10% = 5% of equity. If you set entry_allocation_percent: 100, the entry gets the full 10%.

All entry allocation percentages in a direction must sum to 100%. If you have one entry, set it to 100. If you have two entries that should split the position equally, set each to 50. If the total deviates from 100% by more than 0.5%, the engine raises a validation error and the strategy will not run.

Why you would use each field

entry_belongs_to_setup — This is how you connect entries to regime filters. Without it, entries evaluate every bar regardless of market conditions. With it, entries only evaluate when the named setup is CONFIRMED. If you defined setups but forgot to set this field, your entries are ignoring your setups entirely.

entry_gate_condition — This field is required. Use it for entry-specific prerequisites that are separate from the setup's gate. The setup gate might say "the market is trending." The entry gate might say "and RSI is not overbought." Both must pass. If you want the gate to always pass, write PRICE_CLOSE > 0.

entry_order_type — This field is required. MARKET orders execute at the next bar's open. LIMIT orders specify a price and wait. STOP orders trigger when price reaches a level. STOPLIMIT combines both. Limit and stop orders interact with expiration, the bar magnifier, and the fill assumption settings in ways that can surprise you.

entry_lock_prices — Use this when you want the limit or stop price to be calculated once and then held. Without latching, a limit price expression like PRICE_CLOSE - 50 * MINTICK recalculates every bar, which means the order target drifts with the market. Latching freezes it at the value calculated when the trigger first fired.

entry_oca_group — Use this when you have alternative entry strategies and want whichever triggers first. Two entries in the same OCA group mean: "I want either this entry or that entry, but not both."

entry_one_shot — The default true means the entry fires once per setup activation and then stops. Set to false for pyramiding — adding to a winning position. Pyramiding interacts with the Properties tab pyramiding limit: even if your entry allows multiple adds, the global limit caps the total concurrent trades.

Minimal entry example

Example
- entry_name: EMA_CROSSOVER
  entry_gate_condition: PRICE_CLOSE > 0
  entry_trigger_when: CROSSOVER(PRICE_CLOSE, EMA_50)
  entry_order_type: MARKET
  entry_allocation_percent: 100

A market order entry on GLOBAL (no setup), triggered when price crosses above the 50 EMA. Gate is always-true. Allocation is 100% of the Properties tab default position size. One-shot by default — fires once and stops.

Full entry example

Example
- entry_name: PULLBACK_LONG
  entry_belongs_to_setup: TREND_FILTER
  entry_gate_condition: RSI_K < 40
  entry_trigger_when: CROSSOVER(PRICE_CLOSE, EMA_20)
  entry_confirm_count: 1
  entry_order_type: LIMIT
  entry_limit_price: PRICE_CLOSE - (10 * MINTICK)
  entry_lock_prices: true
  entry_allocation_percent: 100
  entry_id: PULLBACK_GROUP
  entry_expire_after_bars: 5
  entry_cancel_when: PRICE_CLOSE < PRICE_LOW[3]
  entry_one_shot: false
  entry_pyramiding_max_adds: 2

This entry belongs to the TREND_FILTER setup, waits for RSI to be below 40 (gate), triggers on an EMA crossover with 1-bar confirmation, submits a limit order 10 ticks below the current close (latched), uses the full Properties default position size, allows up to 3 total fills (1 + 2 adds), expires unfilled orders after 5 bars, and cancels the pending order if price breaks below the 3-bar low.

Take profits section

Take profits define profit-taking exits. They target open trades from specific entries (via from_entry_id) or from all entries in the same setup.

Take profit fields

Field	Required	Type	Default	What it does
`take_profit_name`	Yes	Text	—	Unique identifier for this exit.
`take_profit_belongs_to_setup`	No	Text	`GLOBAL`	The setup this exit is associated with. If omitted, the exit attaches to GLOBAL. See Exit targeting scope below.
`take_profit_gate_condition`	Yes	Expression (boolean)	—	A prerequisite for this exit to evaluate. Even if you want it always active, you must write it explicitly (e.g., `PRICE_CLOSE > 0`).
`take_profit_trigger_when`	No	Expression (boolean)	`true`	The primary exit signal. When omitted, the exit is always eligible (useful for standing limit orders).
`take_profit_confirm_type`	No	`BAR_COUNT` or `NUM_TICKS`	`BAR_COUNT`	How confirmation is measured.
`take_profit_confirm_count`	No	Integer (>= 0)	`0`	How many bars the trigger must persist before the exit fires.
`take_profit_order_type`	No	`MARKET`, `LIMIT`, `STOP`, or `STOPLIMIT`	`LIMIT`	The exit order type.
`take_profit_allocation_percent`	No	Number	100	What percentage of the anchored position to close. 50 means close half. See For the Geeks for anchored sizing.
`take_profit_limit_price`	No	Expression (numeric)	—	The limit price for LIMIT/STOPLIMIT exits.
`take_profit_stop_price`	No	Expression (numeric)	—	The stop price for STOP/STOPLIMIT exits.
`take_profit_lock_prices`	No	`true` or `false`	`false`	Latch the price on first trigger.
`take_profit_cancel_when`	No	Expression (boolean)	None	Cancels this exit when true. The exit deactivates for the current cycle.
`take_profit_from_entry_id`	No	Text	See scope rules	Targets only the entry group with this `entry_id`. If omitted, the targeting depends on which setup the exit belongs to. See Exit targeting scope below.

Why you would use each field

take_profit_allocation_percent — This controls how much of the position the TP closes. Two TPs at 50% each close the entire position in two legs. Three TPs at 33% each close it in three legs. If total allocation exceeds 100%, all TPs are scaled down proportionally. This is how you build exit ladders.

take_profit_trigger_when — Use this when the TP should only activate under certain conditions. A TP gated on POSITION_PROFIT_PERCENT > 2 and triggered when CROSSUNDER(RSI_K, 70) means: "take profit when RSI starts dropping from overbought, but only after the position is at least 2% in profit."

take_profit_lock_prices — Use this for fixed target TPs. A TP with a limit price of POSITION_AVG_PRICE * 1.05 and lock_prices: true sets the target at 5% above entry and holds it. Without latching, the target would recalculate if the average entry price changes (from pyramiding adds, for example).

take_profit_from_entry_id — Use this when different entries need different exit logic. Your pullback entry might have a tighter TP than your breakout entry. Give them different entry_id values and target each TP at the appropriate group.

Exit targeting scope

How an exit selects which entry groups it applies to depends on two fields:

If from_entry_id is set, the exit only applies to the entry group with that entry_id. This is the most specific targeting.

If from_entry_id is omitted and the exit belongs to a named setup (not GLOBAL), the exit applies to all entries in that same setup.

If from_entry_id is omitted and the exit belongs to GLOBAL (either explicitly or by default because belongs_to_setup was omitted), the exit applies to every entry group in the direction. This is the broadest scope and is often not what you want for complex strategies.

If you have multiple setups with different entries, always set belongs_to_setup or from_entry_id on your exits to avoid unintended cross-targeting.

Minimal take profit example

Example
- take_profit_name: TP_1
  take_profit_gate_condition: PRICE_CLOSE > 0
  take_profit_order_type: LIMIT
  take_profit_limit_price: POSITION_AVG_PRICE * 1.03
  take_profit_lock_prices: true

A limit order at 3% above entry, price latched on first evaluation. Gate is always-true. Closes 100% of the position (default). Because belongs_to_setup is omitted, this exit attaches to GLOBAL and targets all entry groups.

Scaled take profit example

Example
- take_profit_name: TP_1
  take_profit_gate_condition: PRICE_CLOSE > 0
  take_profit_order_type: LIMIT
  take_profit_limit_price: POSITION_AVG_PRICE * 1.02
  take_profit_lock_prices: true
  take_profit_allocation_percent: 50

- take_profit_name: TP_2
  take_profit_gate_condition: PRICE_CLOSE > 0
  take_profit_order_type: LIMIT
  take_profit_limit_price: POSITION_AVG_PRICE * 1.05
  take_profit_lock_prices: true
  take_profit_allocation_percent: 50

Two TPs that together close the full position: half at 2% profit, the other half at 5%.

Stop losses section

Stop losses define protective exits. The field structure mirrors take profits with a different prefix.

Stop loss fields

Field	Required	Type	Default	What it does
`stop_loss_name`	Yes	Text	—	Unique identifier for this exit.
`stop_loss_belongs_to_setup`	No	Text	`GLOBAL`	The setup this exit is associated with. If omitted, attaches to GLOBAL. See Exit targeting scope above.
`stop_loss_gate_condition`	Yes	Expression (boolean)	—	A prerequisite for this exit to evaluate. Even if you want it always active, you must write it explicitly (e.g., `PRICE_CLOSE > 0`).
`stop_loss_trigger_when`	No	Expression (boolean)	`true`	The primary exit signal.
`stop_loss_confirm_type`	No	`BAR_COUNT` or `NUM_TICKS`	`BAR_COUNT`	How confirmation is measured.
`stop_loss_confirm_count`	No	Integer (>= 0)	`0`	How many bars the trigger must persist.
`stop_loss_order_type`	No	`MARKET`, `LIMIT`, `STOP`, or `STOPLIMIT`	`STOP`	The exit order type.
`stop_loss_allocation_percent`	No	Number	100	What percentage of the anchored position to close.
`stop_loss_stop_price`	No	Expression (numeric)	—	The stop price for STOP/STOPLIMIT exits.
`stop_loss_limit_price`	No	Expression (numeric)	—	The limit price for LIMIT/STOPLIMIT exits.
`stop_loss_lock_prices`	No	`true` or `false`	`false`	Latch the price on first trigger.
`stop_loss_cancel_when`	No	Expression (boolean)	None	Cancels this exit when true.
`stop_loss_from_entry_id`	No	Text	See scope rules	Targets only the entry group with this `entry_id`. If omitted, targeting follows the same scope rules as take profits — see Exit targeting scope above.

Why you would use each field

stop_loss_stop_price — This is the most important field. A stop loss without a price expression is a market exit that fires when the trigger is true. A stop loss with a stop price is a standing order that executes when price reaches the level. The difference is timing: a market stop fires on the next bar after the trigger. A stop-order stop fires intra-bar when price touches the level.

stop_loss_lock_prices — Almost always true for stop losses. You want the stop level set once, based on where you entered, and held. A stop at POSITION_AVG_PRICE - ATR_14 * 2 with latching freezes the stop at 2 ATR below entry and does not drift as ATR changes. Without latching, the stop recalculates every bar, which can widen or tighten your risk in ways you did not intend.

stop_loss_trigger_when — Use this for conditional stops. A stop that should only activate after the position is already working: POSITION_PROFIT_PERCENT > 1. Or a stop that should only arm after price re-enters a certain zone. This lets you build graduated protection logic without forcing every stop to be live from the first bar.

Minimal stop loss example

Example
- stop_loss_name: SL_1
  stop_loss_gate_condition: PRICE_CLOSE > 0
  stop_loss_order_type: STOP
  stop_loss_stop_price: POSITION_AVG_PRICE - (200 * MINTICK)
  stop_loss_lock_prices: true

A stop order 200 ticks below entry, latched. Gate is always-true. Closes the full position.

Field defaults summary

When you omit optional fields, the engine applies these defaults. Note that several fields are required and have no default — omitting them causes a validation error.

Omitted field	Default behavior
`entry_gate_condition`, exit gate conditions	No default — required. Validation error if omitted.
`entry_order_type`	No default — required. Validation error if omitted.
`entry_allocation_percent`	No default — required. Validation error if omitted.
`setup_cancel_when` / `setup_reset_when`	At least one required. Validation error if both are omitted.
`entry_trigger_when`, exit trigger	Defaults to `true` — fires every bar the gate passes
Confirmation count (all sections)	Defaults to `0` — no confirmation delay
Confirmation type (all sections)	Defaults to `BAR_COUNT`
Entry one-shot	Defaults to `true` — fire once per activation
Take-profit order type	Defaults to `LIMIT`
Stop-loss order type	Defaults to `STOP`
Exit allocation	Defaults to `100` — close the entire position
Lock prices (all sections)	Defaults to `false` — prices recalculate every bar
Cancel condition (entries/exits)	No default — the order is never cancelled by condition
Cooldown bars (setups)	Defaults to `0` — no cooldown
Close on cancel (setups)	Defaults to `false` — cancelling a setup does not close positions
`belongs_to_setup` (entries/exits)	Defaults to `GLOBAL` — no setup gating for entries; broadest targeting scope for exits
`from_entry_id` (exits)	Depends on setup — named-setup exits target that setup's entries; GLOBAL exits target all entries

Understanding defaults and required fields is essential for debugging. If the strategy shows a validation error on load, check that all required fields are present. When behavior surprises you, check whether a default is doing something you did not expect — especially one_shot: true (entries fire once), allocation_percent: 100 on exits (closes everything), and belongs_to_setup defaulting to GLOBAL on exits (targets all entry groups).

Common YAML mistakes

Mistake	What happens	How to catch it
Omitting a required field (`entry_gate_condition`, `entry_order_type`, `entry_allocation_percent`, exit gate, or setup cancel/reset)	Validation error — the strategy does not run	Error table shows "Missing required field"
Entry allocations not summing to 100%	Validation error — the strategy does not run	Error table shows the allocation total and the expected 100%
Missing colon after field name	Parse error	Error table
Typo in field name (e.g., `entry_trigerr_when`)	The field is silently ignored — the default value is used instead	Schema summary shows unexpected counts, or expression diagnostics show EMPTY for the field you thought you defined
`entry_belongs_to_setup` does not match any `setup_name`	Validation error — the entry references a missing setup	Error table shows the unresolved reference
`from_entry_id` does not match any `entry_id`	Validation error — the exit references an unknown entry scope	Error table shows the unresolved reference
Setting `entry_one_shot: false` without `entry_pyramiding_max_adds`	Pyramiding is enabled but with no add limit — the entry can fire up to the global pyramiding limit	Unexpected trade count. Set `entry_pyramiding_max_adds` explicitly.
Total exit allocation exceeding 100%	All exit allocations are scaled down proportionally	Actual fill quantities in the trade list are smaller than the YAML percentages suggest. See For the Geeks.
Omitting `belongs_to_setup` on exits in a multi-setup strategy	The exit defaults to GLOBAL and targets every entry group in the direction, not just the intended setup's entries	Exits firing against entries from the wrong setup. Always set `belongs_to_setup` or `from_entry_id` when you have multiple setups.
Expression field on a single line that exceeds TradingView's text area limit	The expression is truncated — the engine parses a partial expression	Compile error in the error table, or behavior that does not match the intended condition. Use multi-line expressions for complex conditions.

See Troubleshooting for the complete diagnostic workflow when your YAML is not behaving as expected.