Rules And Risk

This page is the behavior contract for how the strategy decides what is allowed to happen. Use it when the builder is already loaded and your real question is no longer "what field exists?" but "why did the strategy behave this way?" This page sits between the field references and the chart itself. It is here to help you read runtime behavior in a sane order. If your question is about exact field names, go to YAML Section Reference. If your question is about the logic language, go to Expression Language Reference. If your question is about vocabulary, go to Default Token Reference.

This page is for the bigger behavioral question: What has to line up before the strategy is actually allowed to do something?

The First Principle

The strategy does not jump straight from "logic exists" to "trade happens." It moves through a sequence of permissions. That matters because many users read the chart as if one true condition should produce one immediate trade. A builder like this is more structured than that. It can correctly say no at several different layers before an entry or exit is ever allowed to behave.

The Runtime Sequence In Plain English

The cleanest way to think about the strategy is as a sequence of gates: 1. is the runtime ready at all? 2. is this direction currently allowed? 3. is the setup context valid? 4. is the entry or exit package eligible? 5. does the rule have the prices, scope, and state it needs? 6. is a broader risk rail blocking fresh participation anyway? If you read the chart in that order, confusion usually gets much smaller.

Rule Layer 1: Runtime Readiness

Before the strategy can trade, it has to be ready to trade. That sounds obvious, but it is one of the most common sources of wasted time because users often skip straight to the chart and treat silence like a bug.

What readiness means here

Readiness is not only "the script loaded." In practical terms, readiness means:

• the authored sections were accepted
• required references make sense
• the logic layer is not blocked
• the strategy has what it needs to begin operating
• you confirmed that you reviewed the strategy properties

If any of those is still unresolved, the correct first move is not rewriting the strategy. The correct first move is finishing the readiness path.

Why the properties confirmation belongs here

This strategy treats properties review as part of readiness because tester assumptions can materially change what every result means. That design is doing something healthy: it refuses to treat the report as separate from the assumptions that produced it.

Rule Layer 2: Direction Comes Before Logic

The strategy does not evaluate every side equally all the time. Direction is the broad permission layer that decides whether long logic, short logic, or both are even eligible to matter.

If a clean-looking workflow is doing nothing, direction is always worth checking early.

Rule Layer 3: Setup State Decides Whether Context Exists

Setups are the first real behavior layer. They answer the question: Is this idea live enough to deserve attention right now? That one question carries more weight than many readers initially realize. If the setup is not active, confirming, or confirmed in the way you think it is, later participation rules may never get a valid chance to act.

What setup state can do

Depending on how you authored the setup, it can:

• stay inactive
• become active
• move through a confirmation stage
• become confirmed
• cancel
• reset
• cool down before becoming available again

This is why a setup is not a decorative wrapper around the entry. It is a true operating window.

What setup state changes for the rest of the workflow

If a named setup never becomes valid, entries and exits that depend on it do not get to pretend otherwise. That is why chart-reading discipline matters here. The first practical question is not: "Why did the entry not fire?" The first practical question is: "Was the owning setup actually in the state the entry needed?"

Rule Layer 4: Entries Need More Than A Trigger

An entry can only behave when several different permissions line up. That is important because readers naturally over-focus on the trigger and under-focus on the rest of the package.

What has to line up for an entry to act

This is why "the signal was there" and "the entry was placed" are not the same statement in this strategy.

The practical meaning of order type

Order type is part of runtime behavior, not a cosmetic label. Market behavior, resting behavior, and hybrid behavior all create different chart paths even when the entry idea is otherwise similar. If you see surprising entry behavior, ask: - was this meant to act immediately? - was this meant to rest? - was this meant to wait at a threshold and then rest? The answer often resolves the confusion faster than staring harder at the trigger logic.

Rule Layer 5: Exits Are Managed Behavior, Not Loose Suggestions

Take profits and stop losses are authored separately, but they are part of one coordinated management layer. That matters because exit behavior is where many users discover whether they truly understood the workflow or only understood the idea in broad strokes.

What exit behavior depends on

Exit behavior is shaped by:

• ownership
• gate and optional trigger logic
• order type
• scope
• allocation coverage
• whether prices stay fixed or continue updating

Those are not small details. They explain why an exit: - appeared - did not appear - remained waiting - moved unexpectedly - affected a broader context than you intended

A strong reading habit for exits

When an exit surprises you, ask these questions in order: 1. does this exit belong broadly to a setup or specifically to an entry group? 2. is it supposed to act immediately or rest? 3. should its price remain fixed or keep adapting? 4. is its coverage share coherent with the rest of the management ladder? That order prevents a lot of misdiagnosis.

Ownership Changes Real Behavior

Ownership is one of the deepest behavior rules in the whole strategy. It changes: - what later rules are allowed to inherit - which setup context an entry or exit depends on - whether a cancellation event should affect broader downstream behavior - whether management applies broadly or specifically This is why ownership should never be treated as a labeling convenience. It is a structural decision.

The Global Path Is Always Worth Checking

The strategy includes a built-in global path for entries and exits that are not attached to a named setup. This can be useful. It can also explain behavior that felt unexpected. The key distinction is: - a named setup path acts inside authored context - the global path is always-available context for that side If a rule behaved when you thought the setup should have prevented it, ask whether that rule was actually using the global path. That one question resolves a surprising amount of confusion.

Setup Cancellation Is Not Just A Visual Event

When a setup cancels, that is not only a visual state change on the chart. Depending on how the workflow is authored, cancellation can also affect: - future entry eligibility - existing working orders - broader trade cleanup behavior That is why setup design matters so much. The setup layer is not only a filter. It can shape lifecycle behavior downstream.

Strategy-Level Risk Rails Sit Above The Workflow

The strategy also applies broader rails that can block fresh participation. These include boundaries around things like: - drawdown - consecutive loss days - intraday loss - intraday filled orders - allowed entry direction

The most important way to think about these rails

They are hard limits. They are not: - substitutes for authored trade management - proof that the strategy is disciplined - universal recommendations for your workflow They are simply strategy-level boundaries that can say, "No more fresh participation under these conditions." That means a quiet chart can be the correct state when a rail is active.

What A No-Trade State Usually Means

This list is worth internalizing because it prevents the most common emotional mistake: assuming silence means failure.

Misreadings Worth Stopping Early

"If the trigger was true, the trade should have happened"

Not necessarily. The trigger is only one permission layer.

"If the setup is fine, the rest is probably fine"

Not necessarily. Entries and exits still carry their own behavior rules.

"If the chart is quiet, the strategy is broken"

Often false. Readiness, direction, setup state, and rails all come before panic.

"The risk rails tell me how to manage trades"

They do not. They tell the strategy when to stop allowing fresh participation under broader conditions.

The Shortest Runtime Verification Path

When behavior looks wrong, use this order: 1. confirm runtime readiness 2. confirm direction 3. inspect setup state 4. inspect entry permissions 5. inspect exit scope and behavior 6. check whether a broader rail is blocking participation That sequence is simple, but it is one of the highest-value habits in the entire manual.

Where To Go Next

• Backtesting and Realism if the runtime behavior exists but you are unsure what the report is actually worth
• Troubleshooting if you already have a specific symptom and want the shortest likely cause
• For the Geeks if you want a higher-level explanation of why setup windows, scoped exits, and fixed-versus-moving prices matter so much in this builder