Roulytic Backtest

Define the rule.
Run the history.
Review every result.

Roulytic Backtest is being designed to let users test a clearly defined research rule against historical roulette data while preserving wheel boundaries, session boundaries, every occurrence, and the original sample.

See the workflowResearch methodology
No cherry-pickingNo cross-wheel sequencesForward comparison later
● BACKTEST LAB
PLANNED UI
Import historical spin dataCSV / JSON / manual dataset · wheel and session labels preserved
Pattern
TSF
Target
THIRD + 26
Wheel scope
KEEP SEPARATE
Test mode
HISTORICAL
Occurrence preview — illustrative
Wheel 1 · Session A
#014
HIT
included
Wheel 1 · Session B
#006
MISS
included
Wheel 2 · Session A
#021
HIT
included
Boundary crossing
—
BLOCKED
excluded

Five steps from raw data to a reviewable backtest.

The goal is to make the result reproducible. Another user should be able to understand what was tested, what data was used, and which observations counted.

Import

Bring in historical spins with wheel and session identity intact.

Define

Choose the setup, target, exclusions, and test scope before calculation.

Validate

Check lane mapping, duplicates, malformed rows, and sequence boundaries.

Run

Measure every completed occurrence under the same rule.

Review

Inspect outcomes, sample size, session spread, wheel behavior, and later forward evidence.

1. Import historical data

Bring the data in without losing its structure.

The dataset should not become one giant spin stream. Wheel and session identity are part of the evidence and must survive the import.

CSV

Structured rows for spins, timestamps, wheel IDs, and session labels.

JSON

Useful when the tracker already stores richer session metadata.

Manual

Paste or enter a short historical sequence for a controlled test.

Import validation

Bad input should be visible before the test runs.

✓
Duplicate detectionIf CSV and JSON contain the same session, count it once.
✓
Lane recalculationDerive classifications from the raw roulette number rather than trusting a saved label.
✓
Wheel separationBlock patterns that would cross from one wheel into another.
✓
Session boundariesPreserve separate sessions instead of creating artificial continuity.
2. Define the test

Lock the question before seeing the result.

A useful backtest starts with a clear rule. Roulytic should record the rule alongside the result so it is obvious what was actually tested.

A
SetupExample: a 2-spin, 3-spin, or longer sequence.
B
TargetThe exact outcome definition used to score a hit or miss.
C
Special rulesAny exclusions or special-number behavior must be explicit.
D
ScopeChoose wheels, sessions, date range, and minimum sample conditions.
3. Score every occurrence

Pattern occurrence is not the same as an actual bet.

The research layer should score completed occurrences independently. A separate betting layer can later show which qualifying occurrences were actually wagered.

RECORD
OCCURRENCE
BET
OUTCOME
COUNT?
Example A
Yes
No
Hit
Research
Example B
Yes
Yes
Miss
Both
Example C
No
No
—
Ignore

What a backtest result should show.

A single percentage is not enough. Roulytic should expose the context around that percentage so users can see how much evidence it actually represents.

N

Occurrences

Total completed setups under the defined rule and test scope.

W/L

Hits & misses

Transparent counts, not only the favorable result.

%

Historical rate

Descriptive performance for the tested sample, not the probability of the next spin.

S

Session spread

How broadly the observations are distributed instead of being concentrated in one session.

W1

Wheel profile

How the same rule behaved on each wheel without combining raw sequences.

25

Recent windows

Planned 25 / 50 / 100 views to show whether the historical picture changes across different windows.

LS

Streak profile

Consecutive hits or misses can be reviewed as descriptive session behavior.

26

Special behavior

Where relevant, special-number handling should be visible instead of hidden inside the score.

Historical result

Backtest

Historical data helps identify whether an idea deserves prospective testing. It is where the research question begins.

1
Known past dataUseful for discovering and describing candidate structures.
2
Higher hindsight riskRules can accidentally be shaped around what already happened.
THEN
Prospective result

Forward test

After the rule is frozen, future occurrences show whether the historical result holds up under new evidence.

1
Future observationsCollected after the test rule has already been defined.
2
More useful validationCan strengthen, weaken, or contradict the historical candidate.
What the app should prevent

Research errors that create false confidence.

!
Cross-wheel pattern creationNever join raw sequences from different wheels.
!
Double-counting sessionsDetect duplicate CSV/JSON uploads and overlapping files.
!
Mid-test rule rewritingPreserve the original rule and record deliberate future versions separately.
!
Small-sample promotionA high percentage from a few observations should remain visibly immature.
Research language

Backtesting describes history. It does not predict the next spin.

Important: A historical hit rate is a measurement of that historical sample. It should not be presented as the probability that the same target will occur on the next roulette spin.
Planned for Roulytic.app

Test the idea. Preserve the evidence.

Roulytic Backtest is being designed as a research tool that makes rules, samples, boundaries, and results visible — so a promising historical pattern can be tested properly instead of treated as a prediction.

Join Early Access