Settings

This page maps the settings surface in the order a real user usually needs to think through it. That order matters more than it may seem. Most builder frustration does not come from one impossibly hard control. It comes from trying to think about direction, YAML, tokens, diagnostics, and tester assumptions all at once. When everything is mentally equal, the important settings disappear into the background noise. This page is here to fix that.

The Core Rule For Using The Settings Panel

Do not move through the panel from top to bottom like a checklist you are trying to finish. Move through it in decision order: 1. choose what side is allowed to run 2. review the tester assumptions 3. load the rule content for that side 4. add custom tokens only if the workflow really needs them 5. turn on diagnostics only when you have a specific question If you keep that sequence, the builder stays readable much longer.

When To Use This Page Versus A Reference Page

This page is for orientation and decision flow. Use it when your question sounds like: - where should I start in this panel? - which settings are most likely to change behavior? - what should I review before trusting what I see? - what part of the panel answers this kind of problem? Use the deeper reference pages when your question becomes more exact:

Settings tells you where to look. The references tell you exactly what is allowed once you get there.

Read The Panel As Five Different Zones

The strategy becomes much easier to operate when you stop seeing the panel as one wall of inputs.

Once you separate the panel this way, most settings questions get smaller immediately.

Zone 1: Direction And Execution Controls

Start here because these controls decide whether the strategy is even allowed to behave the way you expect.

Strategy direction

This is the broad lane selector for the entire workflow.

If the chart surprises you, direction is one of the first things to check. A beautifully written short-side workflow can still do nothing for perfectly correct reasons if the strategy is only allowed to trade long.

Strategy-level rails

The strategy also exposes broader risk controls that can stop fresh participation. Read them as hard boundaries, not as recipe advice.

These settings matter because they can make a quiet chart correct. That is one of the most useful mindset shifts in the whole manual. A no-trade state is not always a failure state.

The properties-review confirmation

This is one of the most important controls in the whole panel because it changes whether runtime is considered ready. The right order is: 1. review the properties tab 2. understand what you are testing 3. confirm that review The wrong order is: 1. check the box 2. hope the assumptions are fine 3. let the report tell you what happened That box exists to keep you from collapsing those two orders into one careless motion.

Zone 2: Strategy Properties

Even though the properties tab sits outside the main text boxes, it is part of the strategy's operating surface. Treat it that way.

Why the properties tab matters so much

The properties tab shapes: - position sizing - cost assumptions - slippage assumptions - fill assumptions - pyramiding behavior - timing and execution posture That means the same authored workflow can tell a very different story under different property assumptions. If you forget what the properties tab is doing, you can end up "debugging" behavior that is really coming from the tester assumptions rather than the rule design.

The properties worth reading first

If the full tab feels like too much at once, start with these: 1. sizing model 2. sizing amount 3. commission 4. slippage 5. pyramiding 6. execution posture Those six usually explain more report drift than people expect. The goal here is not to optimize them on day one. The goal is to know what test you are actually running.

Zone 3: YAML Authoring Boxes

This is the heart of the builder. The strategy separates authoring by side and by job so the workflow stays structured instead of collapsing into one large rule document.

There are separate boxes for the long side and the short side.

The calmest way to load them

The easiest working rhythm is: 1. populate one side first 2. leave the inactive side blank 3. verify the first path 4. only then widen into the opposite side This reduces confusion because the chart cannot surprise you with behavior you forgot you loaded.

What this page is not trying to do

This page is not the field dictionary. The moment your question becomes: - which field is required? - which field belongs in setups versus entries? - what happens if I leave this out? go to YAML Section Reference. That page is the contract. This page is the map.

Zone 4: Custom Tokens

Custom tokens are powerful because they extend what the strategy can read from the chart. They are also one of the easiest places to add confusion before you add insight. That is why the best time to use them is after a built-in-only workflow already makes sense.

How to think about a custom token row

Each row answers three questions:

The important caution about true-or-false tokens

A true-or-false custom token is not a mind-reader. It does not infer your trading intent from a source. It applies a much simpler interpretation rule. That is often useful. It is also easy to misuse if the underlying source was never truly binary to begin with. If you are unsure whether a custom value should be numeric or true-or-false, numeric is often the safer place to start because it preserves more information.

A good token discipline

Add a custom token only when you can answer these questions clearly: 1. what does this source add that built-in values do not? 2. why does the chosen type preserve the meaning I care about? 3. how will I verify that this token is carrying the value I think it is? If those answers are fuzzy, the token probably belongs later in the build sequence.

Zone 5: Diagnostics

Diagnostics are there to answer questions. They are not there to create a permanent cloud of extra information around every chart.

The right rhythm is: 1. identify the question 2. turn on the one tool that answers that question 3. inspect what you need 4. turn it back off when clarity returns That approach keeps diagnostics from becoming their own form of overload.

The Best Practical Settings Order

If you want one repeatable sequence for normal use, use this: 1. confirm direction 2. review properties 3. populate the active side only 4. confirm whether custom tokens are truly needed 5. clear any validation blockers 6. confirm the properties review 7. use diagnostics only if the chart still feels unclear That sequence is boring in the best possible way. It keeps you from making avoidable mistakes.

Settings Mistakes That Cost People Time

Running both sides too early

This makes the chart harder to read before you have a stable model of what one side is doing.

Treating the properties tab as background

This turns the report into a moving target you do not fully understand.

Adding custom tokens before the base workflow is readable

This hides basic structural confusion under extra vocabulary.

Leaving diagnostics on all the time

This often produces more noise than clarity.

Forgetting that the top-level rails can block fresh participation

This leads people to call the strategy broken when it is actually obeying its own safety boundaries.

One Setting Surface That Deserves Extra Verification

If you use working-order expiry in your workflow, verify it on the chart rather than assuming every visible timing control carries equal authority. The safest posture is: - author explicit expiry where your workflow depends on it - verify the behavior in a small test - trust observation over assumption That principle applies beyond expiry. When a setting changes real trade behavior, chart verification is always stronger than memory.

Returning To The Strategy After A Break

If you are coming back to an older configuration, do not start by rereading all the logic. Start with the surfaces most likely to drift: 1. direction 2. properties 3. active-side content 4. custom-token rows 5. one visible chart path If those five are clean, the rest usually returns quickly.

Where To Go Next

• read YAML Section Reference when you are ready to work field by field
• read Default Token Reference when token meaning or custom-token setup is the real question
• read Rules and Risk when the panel looks right but the runtime still behaves differently than you expected
• read Troubleshooting when you already have a specific symptom and want the shortest likely cause