YAML Section Reference

Use this page when the question is about the authored contract itself.

Written By AxiomCharts

Last updated About 2 hours ago

YAML Section Reference

Use this page when the question is about the authored contract itself.

This is the page for questions like:

which builder box should this rule live in?
which fields are required for this package type?
what happens if I leave this field out?
which defaults are safe to rely on, and which are better made explicit?
why is the strategy warning me even though the structure looked close?

This page is not trying to teach the whole strategy in one pass. Its job is narrower and more practical: help you author the sections correctly, understand what each field changes, and catch the mistakes that create quiet but misleading behavior.

If you want full example workflows, use Worked YAML Examples alongside this page. If your real question is about the expression language itself, use Expression Language Reference. If your real question is about available values, use Default Token Reference.

The Most Important Idea First

The strategy does not expect one giant YAML document.

It expects separate list snippets inside separate settings boxes.

That matters because many first-time authoring mistakes come from bringing a top-level document mindset into a settings panel that is already divided by side and by job.

The builder works more cleanly when you think of each box as:

one list
of one package family
on one direction

The Eight Authoring Boxes

The strategy separates authoring into eight text areas.

Box	Package family	Direction	What belongs there
long setups	setups	long	long-side context windows
short setups	setups	short	short-side context windows
long entries	entries	long	long-side participation rules
short entries	entries	short	short-side participation rules
long take profits	exits	long	long-side harvesting rules
short take profits	exits	short	short-side harvesting rules
long stop losses	exits	long	long-side protection rules
short stop losses	exits	short	short-side protection rules

How To Read A Package From Top To Bottom

When a package looks dense, read it in this order:

the name tells you what this package is
the ownership tells you what it belongs to
the gate tells you whether it is even eligible
the trigger or active condition tells you when it actually comes alive
the behavior fields tell you how it will operate once live
the scope and allocation fields tell you what share of the workflow it controls

That reading pattern helps because it mirrors the way the builder actually behaves. It also makes review much easier later when you return to an older configuration.

Structural Rules You Want To Get Right Early

Before any individual field matters, the package has to be shaped correctly.

Rule	What it means in practice	Why it matters
each box expects a list snippet	do not paste a full top-level section label into the box	the box already is the section
each package begins as a list item	every new setup, entry, take-profit leg, or stop-loss leg starts as its own item	this is how the builder knows a new package began
field names must match the live contract exactly	near-miss names do not become valid automatically	small spelling drift creates real warnings or silent misunderstanding
expressions can be short or multiline	the builder supports both compact and more readable formatting styles	you do not need to flatten everything into one line
comments are tolerated, but should stay disciplined	comments can help, but too many of them make a dense package harder to read	readability is part of correctness here
blank lines are allowed	visual spacing is fine	spacing does not create new packages by itself
unknown fields warn rather than becoming useful	the strategy may keep parsing, but the unknown field is still not part of the contract	a warning is not permission

Two habits make YAML authoring much less fragile:

keep names exact
keep package intent obvious from the first few fields

What The Builder Validates Versus What You Still Need To Verify

This distinction matters.

Validation can confirm things like:

whether required fields are present
whether a field uses an accepted value family
whether ownership names point at something real
whether allocation and coverage budgets add up correctly
whether a required price field exists for the order type you chose

Validation does not confirm:

whether the trade idea is strong
whether the chart context is truly what you meant
whether a token is carrying a useful signal
whether the final management path matches your intention on a live chart

In other words, validation protects the contract. It does not replace observation.

Setup Packages

Setups define context.

This is where you decide whether a market condition is valid enough to create an operating window for the trade idea. A well-authored setup often makes the rest of the workflow dramatically easier to reason about because later rules can depend on a named context instead of repeating the same logic everywhere.

What a setup is responsible for

A setup can answer questions like:

when does this idea become active?
when should it stop being active?
does it need confirmation before it counts?
does cancellation also need confirmation?
should there be a cooldown before it can become valid again?
how many entries should be allowed inside one activation?

Setup field reference

Field	Required	Default if omitted	What it controls	What to watch for
setup_name	yes	none	the identity of the setup	it must be unique on that side
setup_gate_condition	no	true	a broader eligibility filter around the setup path	useful when the setup should be globally suppressed under certain conditions
setup_active_when	yes	none	the main condition that makes the setup live	this is the true heart of the setup
setup_cancel_when	conditionally	false when omitted	the condition that invalidates the setup	at least one of cancel or reset behavior must exist
setup_reset_when	conditionally	none	the condition that re-arms the setup path	at least one of cancel or reset behavior must exist
setup_close_on_cancel	no	false	whether cancellation should also clean up related trade behavior	use only when you really want setup cancellation to have direct position consequences
setup_confirm_type	no	bar-count confirmation	how setup confirmation is measured	use deliberately rather than by habit
setup_confirm_count	no	zero	how much confirmation is required before the setup counts	higher confirmation slows the setup and changes frequency
setup_cancel_confirm_type	no	bar-count confirmation	how setup cancellation is measured	matters when you want cancellation to be more deliberate
setup_cancel_confirm_count	no	zero	how much confirmation cancellation requires	can keep a setup from flipping too fast
setup_cooldown_bars	no	zero	how long the setup stays unavailable after cancellation or completion	useful when you want to prevent immediate re-arming
setup_max_entries_per_activation	no	no fixed limit	how many entries may occur within one activation window	negative or careless values can behave more restrictively than expected

How to author setups well

Strong setups are usually:

easy to explain in plain English
strict enough to create real context
simple enough that you can verify them visually

Weak setups usually fail in one of two directions:

they are so loose that later entries are doing all the real filtering
they are so specific that they become invisible except on a tiny slice of history

Common setup mistakes

Mistake	What it causes
no clear invalidation path	the setup may stay live longer than you intended
too much confirmation too early	the setup becomes slow and rare before you understand the base behavior
using setup logic for what really belongs in the entry	context and participation get muddled together
forgetting cooldown exists	the setup seems inconsistent when it is actually obeying its own spacing rule

What to verify after authoring a setup

Before you move on to entries, verify:

when the setup becomes active
when it becomes confirmed
when it cancels or resets
whether any cooldown changes your expectations afterward

If those four things are not clear on the chart, it is too early to widen the workflow.

Entry Packages

Entries define participation.

This is where the workflow answers the question, "If the idea is valid, should the strategy get involved now, and in what form?"

The important word there is form.

An entry is not just a trigger. It also carries order behavior, ownership, allocation, price behavior, expiry, cancellation, and participation limits.

What an entry is responsible for

An entry can answer questions like:

which setup does this belong to?
what must be true before this entry is even eligible?
what makes the entry actually attempt participation?
what kind of order should it use?
how much of the entry budget does it control?
should its price freeze once armed or keep updating?
should it expire if it waits too long?
should it be allowed once or several times?

Entry field reference

Field	Required	Default if omitted	What it controls	What to watch for
entry_name	yes	none	the identity of the entry package	it must be unique on that side
entry_belongs_to_setup	no	global path	which setup owns the entry	blank ownership does not mean "none"; it means global
entry_gate_condition	yes	none	a required permission filter for the entry	if this fails, the trigger never gets a chance
entry_trigger_when	no	true	the event or state that actually causes the entry to act	omitted trigger means the gate can carry most of the burden
entry_confirm_type	no	bar-count confirmation	how entry confirmation is measured	use intentionally; this changes timing
entry_confirm_count	no	zero	how much entry confirmation is required	extra confirmation can filter noise or delay opportunity
entry_order_type	yes	none	whether the entry behaves as market, limit, stop, or stop-limit	order type changes real behavior, not just presentation
entry_allocation_percent	yes	none	how much of the side-level entry budget this package controls	entry allocations must validate toward a full side budget
entry_lock_prices	no	false	whether non-market entry prices freeze once armed	important when you care about fixed versus monitored intent
entry_limit_price	conditional	none	the live or armed limit price	required when the order type uses a limit path
entry_stop_price	conditional	none	the live or armed stop price	required when the order type uses a stop path
entry_id	no	falls back to the entry name for scope	the entry-group identity used by later targeting	be explicit when you plan to target exits carefully
entry_oca_group	no	blank	optional grouping behavior for working entries	use carefully if your workflow depends on order coordination
entry_expire_after_bars	no	no forced expiry	how long a working non-market entry may remain active	this is the clearest place to author entry-level expiry
entry_cancel_when	no	none	the logic that invalidates a working entry	especially important for resting orders
entry_one_shot	no	true	whether the entry should only take one attempt	easy to forget later when wondering why re-entry never happened
entry_pyramiding_max_adds	no	no additional adds by default	how many extra adds are allowed beyond the initial participation	use non-negative values only

Order-type thinking for entries

Different order types are not cosmetic variations.

Order type	Best mental model	What to verify
market	participate as soon as permission and trigger align	did the entry happen at the timing you expected?
limit	wait at a chosen price	did the order rest, fill, or expire the way you intended?
stop	wait for a stop threshold to activate	does the stop level make sense in live chart context?
stop-limit	use a threshold plus a resting price path	did you verify both price components, not just the trigger?

Common entry mistakes

Mistake	What it causes
forgetting ownership	the entry behaves through the global path instead of a named setup
focusing only on the trigger	gate, confirmation, price validity, and expiry still matter
treating order type as a small detail	order type can completely change how the same idea behaves
ignoring allocation totals	the strategy will validate the side-level budget, and the workflow can fail if the budget is not coherent
forgetting one-shot behavior	readers expect repeat participation from a package that was deliberately limited

What to verify after authoring an entry

Before you add more entries, verify:

whether the owning setup is actually the one you intended
whether the gate and trigger are doing different jobs or the same job twice
whether the order type behaves as market, resting, or hybrid intent
whether the entry stays active, expires, or cancels for reasons you can explain

Take-Profit Packages

Take profits define how the workflow harvests success.

That may sound straightforward, but it becomes one of the most important design surfaces in the whole builder once you begin using multiple legs, entry targeting, or moving price logic.

What a take-profit package is responsible for

A take-profit package can answer questions like:

should this management path apply broadly or to a specific entry group?
when is the profit-taking path even allowed to exist?
does it need a separate trigger before becoming active?
should it act as a market exit, a resting order, or a hybrid order path?
what share of the profit-taking budget does it control?
should the price freeze once armed or keep updating?

Take-profit field reference

Field	Required	Default if omitted	What it controls	What to watch for
take_profit_name	yes	none	the identity of the take-profit package	names must be unique across the direction's exit set
take_profit_belongs_to_setup	no	global path	which setup owns the management path	blank means global behavior, not no ownership
take_profit_gate_condition	yes	none	the permission layer for the take-profit path	this should usually express when management is relevant
take_profit_trigger_when	no	true at runtime	an extra trigger layer beyond the gate	useful when harvesting should wait for something specific
take_profit_confirm_type	no	bar-count confirmation	how profit-taking confirmation is measured	use when you want exits to be more deliberate
take_profit_confirm_count	no	zero	how much confirmation profit-taking requires	higher confirmation can delay harvesting
take_profit_order_type	no	limit	whether the package exits as market, limit, stop, or stop-limit	trailing behavior is not part of the current contract
take_profit_allocation_percent	no	100	how much of the take-profit budget this leg controls	be explicit once you begin using multiple legs
take_profit_limit_price	conditional	none	the limit component of the profit-taking path	required when the chosen order type uses a limit path
take_profit_stop_price	conditional	none	the stop component of the profit-taking path	required when the chosen order type uses a stop path
take_profit_cancel_when	no	none	when the resting take-profit path should be invalidated	has no real work to do on a pure market exit
take_profit_lock_prices	no	false	whether non-market take-profit prices freeze when armed	important when you want fixed versus monitored targets
take_profit_from_entry_id	no	broad scope	whether this package targets a specific entry group	powerful, but easy to misuse if you are fuzzy on scope

Designing take profits well

The cleanest take-profit designs usually make one thing obvious: what this leg is trying to do differently from the other legs.

Good differences might include:

early versus late harvesting
broad setup-owned behavior versus specific entry targeting
fixed target behavior versus dynamic target behavior

Weak differences usually look like accidental duplication. If two legs seem to be doing almost the same job, the chart often gets harder to read without the workflow getting any stronger.

Common take-profit mistakes

Mistake	What it causes
leaving allocation implicit across multiple legs	coverage becomes harder to reason about and easier to misread
targeting the wrong entry scope	the leg appears attached to the wrong trade context
using moving price logic without realizing it	the target seems to "wander" when monitored behavior was actually authored
treating a market take profit like a resting order	cancellation and price expectations become confused

What to verify after authoring a take-profit path

Verify:

whether the leg is broad or entry-specific
whether the order type matches your mental model
whether the coverage share makes sense in the full ladder
whether the price should stay fixed or update over time

Stop-Loss Packages

Stop losses define how the workflow constrains damage once participation exists.

They deserve just as much deliberate thought as take profits. In many workflows, the stop side is actually where trust is won or lost because it reveals whether the method has clear protection logic or only vague good intentions.

What a stop-loss package is responsible for

A stop-loss package can answer questions like:

when should protection become active?
should it be broad or tied to a specific entry group?
does protection need a separate trigger?
should protection live as market behavior, resting behavior, or a hybrid path?
what share of the stop-loss budget does this leg control?
should its working price stay fixed or keep adapting?

Stop-loss field reference

Field	Required	Default if omitted	What it controls	What to watch for
stop_loss_name	yes	none	the identity of the stop-loss package	names must stay unique across the direction's exit set
stop_loss_belongs_to_setup	no	global path	which setup owns the protective path	blank ownership still means a real ownership choice
stop_loss_gate_condition	yes	none	the permission layer for the protective path	this usually expresses when protection is relevant
stop_loss_trigger_when	no	true at runtime	an extra trigger layer for the stop path	useful when protection should wait for something specific
stop_loss_cancel_when	no	none	when a resting stop path should be invalidated	does not have practical work to do on a pure market exit
stop_loss_confirm_type	no	bar-count confirmation	how stop-loss confirmation is measured	use with care because more confirmation changes urgency
stop_loss_confirm_count	no	zero	how much confirmation protective action requires	be careful not to delay protection unintentionally
stop_loss_order_type	no	stop	whether the package exits as market, limit, stop, or stop-limit	trailing behavior is handled through continued monitoring
stop_loss_allocation_percent	no	100	how much of the stop-loss budget this leg controls	be explicit once multiple legs exist
stop_loss_lock_prices	no	false	whether non-market stop prices freeze once armed	central when comparing fixed versus moving protective behavior
stop_loss_stop_price	conditional	none	the stop component of the protective path	required when the order type uses a stop path
stop_loss_limit_price	conditional	none	the limit component of the protective path	required when the order type uses a limit path
stop_loss_from_entry_id	no	broad scope	whether this package protects a specific entry group	powerful, but only if you are clear on what it is targeting

Designing stop losses well

A strong stop side usually makes three things clear:

when protection becomes relevant
how the protective path is expected to behave
what share of the position each protective leg is actually responsible for

If any of those three is fuzzy, the chart will usually feel less trustworthy than it needs to.

Common stop-loss mistakes

Mistake	What it causes
assuming the default stop behavior is enough without review	protection may exist, but not in the form you intended
adding confirmation without thinking through urgency	the stop can become slower than your risk model expects
using mixed scopes carelessly	broad and entry-specific protection get tangled together
forgetting allocation still matters on the stop side	coverage can fail or become hard to explain

What to verify after authoring a stop-loss path

Verify:

whether the stop path is broad or entry-specific
whether the order type matches your risk intention
whether any confirmation makes the stop less immediate than you expected
whether the stop price should remain fixed or keep adapting

Validation Rules That Save The Most Time

Several validation rules are especially important because they catch high-impact structural mistakes early.

Validation theme	What it protects
ownership names must point at something real	prevents entries and exits from attaching to imaginary context
entry allocation must validate toward a full side budget	keeps participation sizing coherent across the direction
take-profit coverage must validate within each scope	keeps harvesting ladders from becoming incomplete or contradictory
stop-loss coverage must validate within each scope	keeps protective ladders from becoming incomplete or contradictory
order-type requirements are enforced	prevents resting or hybrid orders from being authored without the prices they need
unsupported values are rejected or warned	keeps near-miss fields from quietly becoming assumed behavior

When the strategy complains, start by asking which of those six themes the complaint belongs to. That usually gets you to the root faster than rereading the whole section.

Defaults Worth Using Carefully

Some defaults are helpful. Some should become explicit once your workflow grows.

Defaults that are usually reasonable for a first proof

setup gate as broadly available
entry trigger as broadly available when the gate already carries the logic
one-leg exit allocations at full coverage

Defaults you should stop leaning on once the workflow becomes serious

blank ownership when you really mean named ownership
omitted allocation in a multi-leg ladder
implicit scope when you really care which entry group a leg belongs to
vague or forgotten price-lock behavior on non-market orders

The general rule is simple: defaults are safest in small, readable examples. The more serious the workflow becomes, the more often explicit authorship is the clearer path.

The Fastest Way To Review A Package That Feels Wrong

When a package looks close but behaves badly, check it in this order:

is it in the right section?
is the name exact?
is the ownership what you intended?
is the gate doing one job and the trigger doing another?
does the order type match the required price fields?
does the scope and allocation make sense?

That order catches a surprising amount before you ever need deeper debugging.

Where To Go Next

read Worked YAML Examples when you want to see these fields used in full, readable strategy patterns
read Expression Language Reference when the structure is correct but the logic text still is not
read Default Token Reference when the field placement is fine but the vocabulary is still fuzzy
read Troubleshooting when you already have a concrete symptom and want the shortest likely cause