Deployment is a decision under uncertainty. A good framework separates three questions:

Is the edge plausible and stable enough to risk money?
What is the smallest capital path that still tests reality?
What observable signals invalidate the thesis?

If you cannot answer all three in writing, you are gambling with extra steps.

Evidence checklist (minimum)

honest out-of-sample protocol (walk-forward or equivalent)
cost and slippage stress pass
parameter stability sanity (small changes do not collapse outcomes)
operational plan (monitoring, incident response, backups)

Risk limits (non-negotiable)

Define before launch:

max drawdown budget
max daily loss
max leverage
kill-switch triggers tied to execution drift

Staged deployment (default)

Start small, increase size only when live metrics match the validated band.

Invalidation rules (the missing half of most writeups)

Write what would make you stop even if you still "believe" in the idea:

repeated slippage failures
structural market changes
repeated deviation from expected trade frequency

A simple scoring rubric (optional but powerful)

Assign 0-2 points each for:

OOS stability across windows
cost stress survival
parameter stability / sensitivity
operational readiness (monitoring, backups, runbooks)

Set a minimum total before live capital. The point is not the exact weights. The point is to prevent one shiny metric from overriding everything else.

Paper trading: what must be true before size increases

Paper trading is not theater if you define pass criteria:

execution metrics within X% of model assumptions
trade frequency within a band versus OOS expectation
no repeated manual overrides

If you cannot measure these, paper trading is just waiting.

Postmortem template (use even when you win)

After 30 live days, write one page:

what matched the model
what diverged
what you will change next time in process (not in parameters)

Winning trades teach less than disciplined reviews.