Logic Builder Model

This page exists to make the strategy feel easier to think with. Once the model on this page clicks, the builder usually stops feeling like a pile of settings and starts feeling like a sequence of responsibilities. That shift matters. Most frustration with Axiom Strategy Lab Pro is not caused by lack of effort. It is caused by reading several different jobs as if they were one job. This page is here to separate those jobs cleanly.

The Big Picture In One Sentence

You author the structure, the conditions, and the vocabulary. The strategy manages the runtime behavior that follows from that contract. That is the core mental model. If you keep that distinction in view, you will spend far less time blaming the wrong layer when behavior surprises you.

The Six-Layer Reading Model

The builder becomes much easier to use when you read it in layers instead of reading it as one giant logic surface.

The strategy-level risk rails sit across all of those layers. They do not replace them. They can still stop fresh participation even when everything else looks valid.

What You Author Versus What The Strategy Owns

One of the calmest ways to approach a builder is to be very clear about what still belongs to you.

You author

• the setup, entry, take-profit, and stop-loss packages
• the names that tie those packages together
• the logic that decides when a condition is true
• the values the strategy should reference from built-in or custom tokens
• the structure of ownership, scope, allocation, and management

The strategy owns

• reading and validating the builder inputs
• maintaining setup state over time
• translating valid entry and exit intent into native strategy behavior
• tracking position context and package state
• applying the strategy-level rails that can block fresh participation

This distinction is more than academic. It tells you where to look when something feels wrong.

If the chart is quiet because the wrong direction is enabled, that is not an expression problem. If an exit attached to the wrong scope, that is not a token problem. If a custom input is carrying a different meaning than you assumed, that is not a setup problem. The more clearly you separate those layers, the faster troubleshooting becomes.

The Three Authoring Contracts

Most of the strategy's learning burden lives in three contracts.

1. The structure contract

This is the builder's organizational layer. It answers questions like:

• what is a setup versus an entry?
• which setup owns which downstream behavior?
• how many pieces of the position should a leg manage?
• which order path belongs to which side?

If your confusion is about where something belongs, go to YAML Section Reference.

2. The logic contract

This is the meaning layer. It answers questions like:

• when should a setup become active?
• when should a participation rule trigger?
• when should a protective path become valid?
• what live value should an order use?

If your confusion is about the logic language itself, go to Expression Language Reference.

3. The vocabulary contract

This is the data layer. It answers one deceptively important question: what is the strategy actually allowed to see? If your confusion is about available values, token naming, or custom-token behavior, go to Default Token Reference.

These three contracts work together. Most problems show up when the reader is trying to solve one with the tools of another.

Setups Are Operating Windows, Not Trade Commands

This is one of the biggest conceptual upgrades the builder offers, and one of the easiest to miss. A setup is not the trade itself. A setup is the operating window that says, in effect, "this idea is now live enough to pay attention to." That distinction matters because many traders naturally flatten everything into one question: "Is the signal true or false right now?"

The builder gives you a more useful structure:

1. decide whether the market context is valid
2. decide whether participation should happen inside that context
3. decide how the trade should be managed once participation exists

That separation gives you cleaner logic. It also makes the workflow much easier to verify. You can inspect the context layer first instead of treating every trade as a surprise coming from nowhere.

What setups are good at

Setups are where you express ideas like:

• this is a valid environment for the trade thesis
• this market state should stay available until invalidated
• this condition needs confirmation before it should count
• this setup should cool down before being reused

In other words, setups organize patience. They keep later rules from acting as if every bar deserves the same attention.

What readers often get wrong

The most common early mistake is treating setup behavior as if it were optional decoration around the entry. It is not. In this builder, setup state often changes whether later behavior is even allowed to exist. If a setup never becomes valid, the later trade path may stay completely quiet for correct reasons.

Entries Decide Participation, Not Context

Once a setup says the environment is live, the entry layer answers a different question: Should the strategy actually get involved now, and if so, how? That "how" matters just as much as the trigger.

An entry is not only a timing rule. It also carries decisions about:

• ownership
• order type
• confirmation
• sizing
• expiry
• cancellation
• one-shot behavior
• add behavior
• whether a price should stay fixed or keep updating

That is why two entries can look similar at a glance and still behave very differently on the chart.

When an entry surprises you, do not only ask whether the trigger fired. Also ask:

• was the owning context valid?
• was this entry still eligible?
• was it meant to act once or repeatedly?
• did it expire or cancel before it had a chance to fill?
• was the price path frozen or still being monitored?

Those are entry-model questions, not merely trigger questions.

Exits Are Part Of The Same Structure, Not An Afterthought

Many traders carry a weak mental model of exits. They think of them as a loose set of after-the-fact instructions. This builder works better when you treat exits as a first-class part of the workflow.

Take profits and stop losses answer two different management questions:

• how should gains be harvested?
• how should risk be constrained once the trade exists?

That structure matters because exits are where many otherwise reasonable workflows become unreadable. A good entry can still produce a confusing trade if the management path is broad, inconsistent, or attached to the wrong scope.

What the builder is trying to protect here

The exit layer exists to keep management tied to actual trade context. That means the strategy can distinguish between:

• broad setup-owned behavior
• more specific entry-targeted behavior
• one-leg management
• multi-leg management
• fixed-price behavior
• monitored-price behavior

You do not need to memorize the engine to benefit from that structure. You do need to notice that the exit path is designed, not incidental.

Ownership Is One Of The Most Important Ideas In The Whole Builder

Ownership changes how the strategy behaves. That deserves to be said plainly because many readers initially treat names and relationships as bookkeeping. They are not. They decide which rules are allowed to act together and which rules should ignore one another.

Questions ownership answers:

• which setup gives this entry permission to operate?
• which management rules belong to which context?
• should a trade be affected when a setup cancels?
• is this path broad, specific, or always available?

If ownership is vague in your mind, the chart will often feel more mysterious than it really is.

The Global Path Is Real, Not Invisible

The builder includes a built-in global ownership path. This matters whenever a rule is not attached to a named setup.

The practical meaning is simple:

• some behavior is explicitly tied to a named context
• some behavior is available through the always-available path

Neither is automatically better. They are different. What matters is that you know which one you authored. One of the most useful questions in the whole manual is this: Is this rule acting inside a named setup, or is it acting through the global path? That one question explains a surprising number of "why did this happen?" moments.

Expressions Are The Meaning Layer, Not The Whole Workflow

Expressions usually attract the most attention because they look like the most "technical" part of the builder. But an expression is only one part of the system.

An expression tells the strategy:

• when something is true
• when something should stop being true
• or what live value should be used

An expression does not tell you:

• where that rule belongs
• who owns it
• whether it has permission to act yet
• whether it is tied to one trade path or another
• whether a hard rail is already blocking fresh participation

That is why a valid expression can still produce behavior you did not expect. The workflow around the expression still matters.

Tokens Are The Builder's Vocabulary

Expressions do not read the chart in some vague, magical way. They read tokens. That matters because good logic built on weak vocabulary is still weak logic.

The strategy gives you three token families:

This is one of the places where false confidence loves to hide. A token can exist and still be misunderstood. A custom token can be wired correctly and still carry weak meaning. A true-or-false custom token can look simple while quietly reducing a more nuanced source into a very blunt threshold rule. That is why token literacy matters so much in this builder. Vocabulary quality shapes logic quality.

Risk Rails Sit Across The Whole Workflow

The strategy also includes broader risk controls that can stop fresh participation even when your authored workflow looks valid. This is important because readers often assume a no-trade state means something is broken in the logic. Sometimes the strategy is correctly refusing new exposure.

The safest way to think about the rails is this:

• they are hard behavioral boundaries
• they do not replace your authored trade management
• they can change what sample you are actually reading

That means a quiet chart may sometimes be a receipt, not a malfunction.

The Right Build Order

If you are moving beyond the first quick-start session, this is the cleanest order to build in:

1. shape the setup first
2. verify that the setup behaves on the chart
3. add one entry path
4. verify how that entry becomes eligible, places, or waits
5. add one management path
6. verify that the exit attaches the way you intended
7. only then widen into extra legs, custom tokens, or heavier logic

This order works because it keeps the source of confusion small. If you widen all three layers at once, it becomes very hard to tell whether the problem is structure, vocabulary, or behavior.

Common Misreadings This Model Prevents

"The trigger is the strategy"

Usually it is not. Context, ownership, order type, management, and rails can all change what the trigger becomes in practice.

"If the builder accepted it, the result is trustworthy"

Acceptance means the contract is readable enough to run. It does not mean the contract is wise.

"The global path is basically the same as named ownership"

It is not. Sometimes it is useful. Sometimes it is the exact reason the chart feels different than expected.

"Tokens are just interchangeable values"

They are not. What a token means is part of the strategy, not a cosmetic detail.

A Good Verification Habit After This Page

Once you finish this page, go back to your chart and narrate one trade path in this order:

1. what made the setup valid
2. what gave the entry permission to act
3. what made the order behave the way it did
4. what management path attached afterward
5. whether any broader rail could have changed the result

If you can do that clearly, the builder is starting to become yours. If you cannot do it clearly yet, do not treat that as failure. Treat it as a signal that the next best step is more model work before more complexity.

Where To Go Next

Use the page that matches the part of the model that still feels thin:

• read Settings if you want the panel explained in the order decisions actually happen
• read YAML Section Reference if structure and field placement are the real questions
• read Default Token Reference if vocabulary and state meaning are still fuzzy
• read Rules and Risk if you want a clearer picture of readiness, permission, and blocking behavior

If you only choose one next page, use Settings. It usually helps the abstract model on this page line up with the actual controls you see on the screen.