Scenario Manager · Scenario Discipline
A controlled condition, not a vibe.
Read this first
Scenario discipline
01A controlled condition, not a vibe.
Borrowing the QA doctrine: a scenario is a contract — a controlled test condition with explicit expected behavior, which turns testing into objective comparison instead of opinion. Scenario_Profiles in CP3 then compares the active profile against alternates over real evidence: was another weighting structurally superior, persistently?
- Persistence rule: a profile must look better over multiple weeks and months, not one flattering sample.
- Scenario outputs remain sandboxed until deliberately promoted — the R&D isolation principle.
Where it lives
02Inside Scenario Manager.
This page expands one card of the Scenario Manager page into its own reference. For orientation, the module's own framing: Branch-weight changes, management variants, filter tweaks, aggression profiles — every candidate change becomes a controlled scenario with explicit expected behavior, run in the sandbox and compared before anything is promoted to production.
One variable law
03Scenarios change one thing, or they explain nothing.
A scenario that adjusts the stop policy AND the branch weights produces a result nobody can attribute. The contract format enforces isolation: one variable moves, everything else holds, and compound proposals get decomposed into a scenario chain run in sequence. Slower, and the only version that produces usable answers.
How MARS uses this
A scenario contract specifies expected behavior before the run — and the grid is where contracts get judged. Each column is one controlled condition: same evidence, one variable changed, outcomes rendered against the P10 tail so the contract's promise can be checked instead of remembered.
BASELINE
LIVEcurrent governing profile
TIGHTER STOPS
REJECTEDEV cost exceeds drawdown saving
TNP WEIGHT +10
SANDBOXedge up, adverse tail deepens
FEE MODEL B
CANDIDATEfriction saving survives resampling
How it benefits you
System changes stop being vibes-based. The tempting tweak that costs 0.07R of expectancy for a modest drawdown saving gets rejected by arithmetic before it silently taxes six months of trading - and promising candidates carry their evidence with them into review.
Contracts under judgment: one variable per column, same evidence throughout, the tail cost always in view.
Worked example
The Dynamic 7-Tier Benchmark converts the drawdown distribution into modeled tier-usage expectations: given the gate transitions the evidence implies, T1-T3 should host most deployment while T5-T7 stay exceptional. Live tier dwell is audited against this profile every cycle.
The seven-tier ladder with modeled dwell: how often each tier should be in use given the gate history. High tiers exist to be rare.
Connected inside MARS
This module doesn't work alone.
Go deeper
Operator briefs on this territory.
Deep dive — 01
Define expected behavior before running the test.
Write the expected behavior first, or the run will mean whatever you wanted it to.
Read the full brief →
Deep dive — 02
Compound ideas get decomposed, and the decomposition has a blind spot.
Three isolated tests answer three questions and cannot answer whether the three interact.
Read the full brief →
Deep dive — 03
A library beats a blank page, especially when the question is hostile.
Ad-hoc testing tests what you thought of. A library tests what you would rather not.
Read the full brief →
Take it further
A scenario worth promoting usually survives twenty that were not. The Foundry is where the other twenty go.
Open the AlphaRail Foundry Lab ↗Every module ships in the complete MARS package.
One price. Eleven workbooks, three TradingView indicators, and the full manual library — $497.