Define expected behavior before running the test.

The doctrine's origin

A scenario is a controlled condition with explicit expected behavior.

The definition comes from the Certified Validation QA layer, where it governs formula validation: a test is a controlled condition plus a pre-stated expectation, and that pairing is what turns checking into objective comparison instead of opinion. The Scenario Manager applies the identical contract to strategy questions. A candidate change — branch re-weighting, a management variant, a filter adjustment, an aggression profile — becomes a scenario only when it carries three written commitments made before the run: what is being changed and held constant, what outcomes the change is expected to move and by roughly how much, and what result would count as failure. The third commitment is the one that separates testing from shopping — a scenario that cannot fail was never a test.

Why order matters

Post-hoc interpretation always finds a friendly angle.

Every simulation run emits dozens of statistics, and among dozens of statistics something always improved. The mind reading results without a contract performs an unconscious selection: the improved numbers become 'what the change was really about,' the degraded ones become caveats, and the run retroactively confirms whatever hope launched it. The contract kills the selection by fixing the judging criteria while the mind is still neutral. If the scenario claimed the variant would improve drawdown behavior at modest EV cost, then the drawdown and EV outputs are the verdict — and a run showing flat drawdown with an exciting improvement somewhere unclaimed is a failed scenario with an interesting footnote, not a success with a twist. The footnote is allowed to inspire the next contract. It is not allowed to rescue this one.

The single-variable rule

One change per contract, or the attribution is fiction.

The contract's 'controlled condition' clause does quiet, essential work: a scenario changes one thing. Bundle a branch re-weight with a filter tweak and a sizing adjustment, and any result — good or bad — is unattributable; the bundle becomes an all-or-nothing bet on a story instead of a test of a mechanism. The discipline feels slow, because it is: three candidate ideas mean three contracts, three runs, three verdicts, possibly then a fourth contract for the combination. But the alternative isn't faster testing — it's untestable bundles promoted on aggregate vibes, which is precisely the failure mode the production system's stability depends on preventing. The Scenario Manager's comparison surfaces are built for this shape: the active configuration against alternates differing by one deliberate dimension, over the same evidence.

• One lever per contract. Combinations are their own contracts, run after the components are understood.
• Held-constant is part of the condition: an undocumented second change invalidates the contract even if it 'shouldn't matter.'
• Sensitivity sweeps are legal — one lever across several values is still one controlled condition.

The verdict record

Every contract closes in writing, whatever the outcome.

A scenario ends when its verdict is recorded against its contract: confirmed, violated, or — the honest middle — inconclusive, with the evidence gap named. The record matters beyond tidiness. Confirmed contracts are the entry ticket to the promotion workflow, which will demand the documentation anyway. Violated contracts are cheap immunizations — the written failure prevents the same attractive idea from being re-litigated every time it feels fresh. And inconclusive contracts, honestly labeled, prevent the subtlest corruption: half-evidence hardening into folklore because nobody wrote down that the question was never actually answered. The scenario library thus accumulates into something the system can't get anywhere else — a memory of every road considered, and why each was or wasn't taken.

The key idea

The contract is what makes simulation evidence instead of theater.

The Scenario Manager's machinery — profiles, comparisons, stress runs — is only as honest as the question posed to it, and the contract is the mechanism that keeps questions honest: condition controlled, expectation pre-stated, failure defined, verdict recorded. Everything downstream inherits the honesty — the persistence window has a fixed claim to hold the candidate against, the promotion decision has documentation instead of enthusiasm, and the production system changes only for ideas that predicted their own success before being shown the answers.