Backtest
A historical simulation using defined data, code, position sizing, and assumptions.
- Useful for studying rule behavior
- Requires costs and slippage assumptions
- Hypothetical, not live performance
01 / Evidence classes
Different evidence answers different questions.
A backtest can help evaluate historical rules. Simulation can verify technical behavior. Live records show actual execution. None of them should be silently presented as another.
Simulation
Execution in a paper environment used to test the system and platform without real capital.
- Useful for technical verification
- Fills can differ from live markets
- Does not prove future profitability
Live, unverified
A live-account result that has not been independently verified by an approved source.
- Must be labeled unverified
- Should show the complete period
- Cannot imply outside verification
Live, verified
A live record supported by an approved third-party or source statement.
- Names what was verified
- Names the verification period
- Still cannot guarantee future results
02 / Report anatomy
A useful performance card shows the uncomfortable details.
Better design is not better proof. The label, source, dates, losses, assumptions, and complete record matter more than how dramatic the return looks.
01
Strategy, market, timeframe, and versionYou should know exactly what was tested.
02
Date range and starting capitalThe beginning and end of the evidence period should be visible.
03
Net result and maximum drawdownShow gains and losses in dollars and percent.
04
Trade count, win rate, and profit factorNo single statistic tells the whole story.
05
Costs, slippage, sizing, and evidence classAssumptions belong beside the result.
03 / Metric definitions
Five numbers. Five different questions.
Performance becomes easier to evaluate when the terms are defined consistently across the website, report, sales conversation, and customer documentation.
Net return
The change after the included trading results and stated costs, shown against the defined starting capital.
Drawdown
The decline from a prior account high. Its definition and measurement method should be visible.
Trade count
The number of closed trades included. A small sample can make other statistics less reliable.
Win rate
The percentage of winning trades. It does not show how large winners and losers were.
Profit factor
Gross profit divided by gross loss. It still depends on the period, sample, and assumptions.
04 / Buyer checklist
Ask these questions before trusting a system.
Use these questions with CodeToCashAI or any other automation provider. Good evidence should make direct answers easier, not harder.
What evidence class am I looking at?
Backtest, simulation, live unverified, and live verified records are not interchangeable.
How were the losses measured?
Ask for the drawdown definition, largest losing periods, and whether open-trade movement was included.
What costs and assumptions were included?
Commission, fees, slippage, data, sizing, and execution assumptions can materially change a result.
What can cause live behavior to differ?
Market changes, fills, latency, data, platform behavior, broker rules, and technical failures all matter.
How do I pause and disconnect the system?
You should understand custody, permissions, monitoring, notifications, pause conditions, and shutdown before activation.
05 / Control and custody
The customer should understand and retain control.
An automated process still needs an accountable human. Compatibility, configuration, testing, monitoring, and shutdown are part of responsible implementation.
Account custodyCustomer's approved account
Risk settingsDocumented before activation
Initial environmentSimulation before launch decision
Pause and shutdownCustomer can perform directly
SupportDefined channel and scope
Build your next step around facts
Understand the evidence. Then review the fit.
The free Automated Trading Plan Call reviews your experience, goals, platform, account path, and risk questions. It does not guarantee a trading result.