Backtesting And Realism

This page is about one question: What is this result actually worth? That question matters because Axiom Strategy Lab Pro is flexible enough to create convincing-looking reports long before the underlying method deserves trust. That is not a flaw unique to this strategy. It is the cost of having a builder that can organize many moving parts cleanly. If you use this page well, it should make you slower in the right places and calmer in the right places.

The Main Boundary

A valid run is not the same thing as a trustworthy run.

The strategy can:

• accept the authored structure
• evaluate the logic
• manage the workflow
• produce trades
• generate a report

None of those guarantees:

• realistic assumptions
• robust logic
• durable market fit
• trustworthy token inputs
• honest interpretation of the result

That boundary belongs at the front because everything else on this page is really an explanation of why that sentence is true.

The Report Is Built On Assumptions, Not On The Rules Alone

Many users speak as if the report comes from their rules and the properties tab is just scenery. It is much more accurate to say: the report comes from the rules under a specific set of tester assumptions. That means the strategy result is shaped by two things at once:

If either surface changes, the result can change in a meaningful way.

The Built-In Tester Posture Deserves To Be Read, Not Inherited Blindly

The production strategy comes with a tester posture already embedded. That posture includes defaults around:

The point is not that these are good or bad by themselves. The point is that they are active unless you changed them on purpose.

The Four Assumption Families To Check First

If the full properties surface feels heavy, start with these four: 1. sizing 2. costs 3. pyramiding 4. timing posture Those four usually explain more report drift than people expect.

Sizing

Sizing changes what every allocation percentage actually becomes in practice. A workflow can look disciplined in percentage terms while carrying very different exposure under a different capital or sizing model.

Costs

Commission and slippage are where many clean-looking results first become more honest. If a strategy only survives under unusually friendly friction assumptions, that is not a small detail. It may be the whole story.

Pyramiding

Pyramiding changes whether layered participation is even possible. In a builder that supports add behavior, this can alter the shape of the entire report.

Timing posture

A timing-sensitive workflow can look very different when intrabar behavior matters. That is why it is dangerous to read every trade as if the strategy only thinks in end-of-bar snapshots.

Why The Properties Review Confirmation Exists

This strategy deliberately asks you to confirm that you reviewed the properties. That design is doing something healthy: it refuses to let you pretend that assumptions are not part of the method. If the strategy did not force that pause, many users would naturally do what humans do under urgency:

• glance at the chart
• see trades
• treat the report as evidence
• only later realize the assumptions were not what they meant to test

The confirmation step is there to interrupt that pattern.

The Same Workflow Can Tell A Different Story Later

One of the most important realism lessons in this strategy is that unchanged authoring does not guarantee unchanged meaning. A workflow can produce a different report because:

• the symbol changed
• the timeframe changed
• the cost assumptions changed
• the participation model changed
• the token inputs changed
• the broader risk rails changed the sample of trades you are actually reading

This is why portability deserves respect. Moving a workflow is easy. Trusting the moved workflow should not be easy.

Intrabar Thinking Matters Here

The strategy is not built as a purely end-of-bar machine. That matters because some users naturally read the chart as if every decision is made only after the bar is complete. In a builder with timing-sensitive confirmation, active order management, and non-market paths, that reading can be too simple.

Practical implications

You should expect that:

• some conditions matter while the bar is still evolving
• non-market behavior may not look like a pure close-only workflow
• timing-sensitive confirmation can feel different than a naïve "bar closed, now act" model

This does not mean the strategy is misleading you. It means the strategy is asking you to read timing with more care.

Price-Locking Changes What You Are Testing

One of the most important realism switches in the builder is whether a non-market price remains fixed once armed or keeps updating while it waits. This matters because those are two different tests.

Neither is automatically more honest in every case. The honest part is knowing which one you authored and reading the result accordingly. If you forget that distinction, a trade can look surprising or "too smart" when the real issue is simply that you are reading fixed and monitored behavior as if they were the same thing.

Custom Tokens Can Add Intelligence Or Add Unseen Fragility

Custom tokens are one of the most valuable features in the builder because they let you bring in chart-linked information beyond the built-in surface. They are also one of the fastest ways to create a report that looks more informed than it really is.

Three realism questions for every custom token

1. is the source itself stable enough to trust?
2. does the token type preserve the meaning I care about?
3. if I removed this token, would I still understand why the trade happened?

If the answer to the third question is no, the workflow may be leaning on a token you have not really verified yet. That is not a reason to avoid custom tokens forever. It is a reason to earn them.

Risk Rails Can Quiet A Strategy And Beautify A Sample

The strategy-level rails can change more than behavior in the moment. They can also change the sample you are reading afterward. That matters because a cleaner-looking report may sometimes reflect:

• broader participation being shut off earlier
• fewer bad periods being included
• fewer additional trades being allowed after stress

That does not make the rails wrong. It simply means you should know when they helped shape the sample. Ask: Did the method improve, or did the rails stop part of the damage from being included in the result? Sometimes the answer is "both." The point is to know the difference.

A Strong Realism Audit After The First Clean Run

Once the workflow is behaving the way you intended, run this audit before you start tuning for better numbers.

Step 1: Inspect one complete trade path

Do not start with the summary table. Inspect:

• one setup becoming valid
• one entry becoming eligible
• one exit path managing the trade

You want to prove that the workflow is explainable before you ask whether it is profitable.

Step 2: Re-read the properties with the result in mind

Now ask:

• what sizing model produced this?
• what cost assumptions softened or hardened this?
• what timing posture shaped this?
• what fill assumptions are implicit in the result?

This step often changes how impressive the report feels, and that is healthy.

Step 3: Stress the flattering parts mentally

Ask:

• would this still look attractive with harsher friction?
• would this still look coherent with a different symbol or timeframe?
• would this still make sense if I removed one custom token?
• would this still be understandable if I had to narrate it to someone else?

If those questions weaken the whole story immediately, the run may not be robust yet.

Common Realism Failures

Treating defaults like recommendations

Defaults are a starting posture, not a promise that they are ideal for your use case.

Treating a smooth curve like proof

A smooth curve can also be the product of convenient assumptions, narrow conditions, or careful overfitting.

Optimizing before understanding the trade path

If you cannot explain why the first few trades occurred, tuning the report only makes the unknown prettier.

Forgetting that costs can decide everything

Some workflows are only convincing before realistic friction is applied.

Forgetting that token quality is part of strategy quality

A clever workflow built on a weak or misread token is still a weak workflow.

Signs You Should Pause Before Trusting The Result

A Better Definition Of Progress

Progress is not only a better backtest. Progress is:

• clearer trade explanations
• better control over assumptions
• fewer surprises in the chart path
• stronger understanding of which results are robust and which are flattering

Those forms of progress are less glamorous, but they are much more durable.

Where To Go Next

• read Optimization when the workflow is understandable and you are ready to tune carefully
• read Operating Checklist if you want a repeatable review routine before trusting future runs
• read Alerts and Automation if a promising backtest is making you eager to operationalize the workflow too quickly
• read Troubleshooting if what you are seeing still feels behaviorally inconsistent rather than merely realism-sensitive