For The Geeks

This page is for readers who want a stronger mental model of the strategy's deeper mechanics before they trust it more fully.

It is not the field reference.

It is not the expression guide.

It is not the token catalog.

Those jobs belong to:

• YAML Section Reference
• Expression Language Reference
• Default Token Reference

The job of this page is narrower: explain why the builder behaves differently from a flatter strategy, what problem that difference is trying to solve, and how you can verify the behavior without needing the implementation details.

Why This Page Exists

Some parts of the strategy matter to trust even if they are not the first thing a new user needs to learn.

These are the kinds of mechanics that advanced readers notice quickly:

• context and participation are separated instead of flattened together
• exits can stay attached to scoped trade context rather than acting like loose percentages
• non-market prices can behave as fixed commitments or moving targets depending on how the workflow is authored

Those mechanics matter because they change how the chart should be read.

If you do not have a mental model for them, the builder can feel "smart but mysterious."

This page is here to remove the mystery without turning the manual into an implementation dossier.

The Three Mechanics Most Worth Understanding

If you understand those three mechanics, a large portion of the builder's "why did it do that?" moments start to resolve.

Mechanic 1: Setup Windows Instead Of One Flat Signal Layer

The easiest way to understand the setup engine is to stop thinking of the strategy as one giant question.

A flatter strategy often behaves like this:

• if a signal is true, act
• if the signal is false, do nothing

Axiom Strategy Lab Pro gives you a more deliberate model:

• first decide whether the market context is valid
• then decide whether participation should happen inside that context

That separation is the first big trust mechanic in the builder.

Why this exists

Without setup windows, one of two things usually happens:

• the entry logic becomes overloaded because it has to carry context, timing, and management permission all at once
• or the strategy stays simple but loses the ability to express how conditions evolve over time

The setup layer solves that by turning context into something the strategy can track.

What the user gains

You gain the ability to think in cleaner questions:

• is the market state valid yet?
• is it still valid?
• has it confirmed?
• has it cooled down?
• is later behavior allowed to depend on that state?

This makes the workflow easier to reason about. It also makes the chart easier to verify because the builder is no longer pretending every decision lives inside one trigger.

The tradeoff

The tradeoff is that the workflow becomes more expressive but also more layered.

If you skip the setup mental model, the chart can feel inconsistent when it is actually obeying a perfectly coherent state machine.

Where the global path fits

The global path exists for rules that are not attached to a named setup.

That means the builder can support both:

• setup-owned behavior
• always-available behavior

This is useful, but it also creates one of the biggest sources of confusion: a rule behaving through the global path can look like a setup-owned rule that "ignored the setup."

The cleaner interpretation is usually simpler: it was not setup-owned in the first place.

Best way to verify this mechanic

Run a small comparison:

1. author one entry that belongs to a named setup
2. author another that behaves through the global path
3. watch how they differ when the named setup is inactive, confirming, confirmed, or canceled

That one comparison teaches a great deal.

Mechanic 2: Scoped Exit Handling Instead Of Loose Percent Thinking

Many traders carry a weak mental model of exits.

They imagine every exit as taking a casual percentage from a pooled position, as if all management paths are interchangeable slices of whatever happens to remain.

This builder is more deliberate than that.

Why this exists

Once you support:

• multiple entries
• multiple take-profit legs
• multiple stop legs
• broad setup-owned behavior
• more specific entry-targeted behavior

a loose exit model becomes much harder to trust.

The builder is trying to preserve context so that management does not collapse into a vague afterthought.

What this changes for the reader

It means the right questions are not only:

• what percent does this leg control?

but also:

• what trade context does this leg belong to?
• is it broad or specific?
• is this management path still coherent after part of the position is gone?

That is a more demanding model, but it is also a more useful one for serious workflows.

The tradeoff

The tradeoff is conceptual weight.

You gain more coherent management behavior, but you also lose the lazy comfort of pretending every exit is aimed at one anonymous pool.

A useful mindset shift

Stop thinking of exit legs as decorative percentages.

Start thinking of them as authored management claims against a real trade context.

That shift alone makes multi-leg workflows much easier to read.

Best way to verify this mechanic

Run a small test:

1. use one entry group
2. attach multiple management legs
3. watch what happens after a partial close
4. compare that with a case where management is explicitly aimed at a specific entry scope

You are not trying to reverse-engineer the builder. You are trying to prove to yourself that the management path has memory and structure.

Mechanic 3: Fixed Versus Monitored Prices

This is one of the most practically important mechanics in the whole strategy.

It decides whether a non-market path behaves like:

• a price that is committed once the order is active
• a price that keeps adapting while it waits

Why this exists

Both behaviors are legitimate.

Some methods want a resting commitment:

"When this opportunity appears, place the level and leave it there."

Other methods want a moving interpretation:

"As long as the order has not filled, keep the level synced to current conditions."

The builder supports both because they are meaningfully different strategy choices.

What this changes for the reader

It changes what should feel surprising.

If a non-market path keeps moving, that is not automatically suspicious. It may be exactly what the workflow asked for.

If a non-market path stays fixed, that is not automatically stale. It may be exactly what the workflow asked for.

The real question is whether the authored choice matches your intention.

The tradeoff

Fixed prices are often easier to narrate after the fact.

Monitored prices can stay closer to evolving context, but they can also create more confusion if you forget they are meant to move.

Best way to verify this mechanic

Run the same basic non-market idea twice:

1. once with fixed behavior
2. once with monitored behavior

Then compare:

• whether the working level moves
• whether the resulting fills differ
• whether the chart path becomes easier or harder to explain

This is one of the highest-value comparison tests in the manual because it turns an abstract option into a visible difference.

What These Mechanics Are Trying To Protect

All three mechanics are trying to protect the same larger goal: keep the strategy from collapsing into a noisy pile of conditions that only looks precise from a distance.

More specifically, they help preserve:

• clearer context
• clearer participation logic
• clearer management scope
• clearer expectations around order behavior

That does not make the workflow automatically good.

It makes the workflow more expressive in ways that can be verified.

What These Mechanics Do Not Prove

This page should increase understanding, not increase deference.

These mechanics do not prove:

• that the underlying idea has edge
• that the chosen assumptions are realistic
• that the token inputs deserve trust
• that a cleaner-looking chart path is necessarily better

They simply explain why the builder behaves the way it does when authored a certain way.

That distinction matters. A sophisticated engine is still only as trustworthy as the workflow you author inside it.

Good Questions To Ask After Reading This Page

If this page is doing its job, it should leave you with better questions, such as:

• did I use a named setup where context really matters, or did I lean on the global path out of convenience?
• are my exits attached to the scope I actually meant to manage?
• do my non-market paths need to stay fixed or keep adapting?
• does the workflow feel more explainable because of these mechanics, or just more elaborate?

Those are strong questions. They lead back to verification instead of toward blind trust.

Best Next Step After This Page

Pick one mechanic and prove it to yourself on the chart.

Do not try to hold all three in your head as theory.

The right rhythm is:

1. choose one mechanic
2. build the smallest example that reveals it
3. watch the chart behavior
4. decide whether the mechanic now feels earned instead of mysterious

That is the whole spirit of this page: less mystique, more method.