Paper-first: how we de-risk going live with new strategies

The riskiest moment in an automated betting strategy is not after the first loss. It is the minute before the first live bet, when a user has seen enough backtest output to feel confident but not enough live market behavior to know whether the strategy is operationally sane.

That is why Glitch Edge is paper-first by design. The Free plan is not a toy version of the product. It is the safest place to make a strategy prove that it can operate against live odds without touching money.

Paper-first does not mean timid. It means disciplined.

Backtests answer the wrong first question

A backtest can be useful. It can tell you whether a hypothesis was worth exploring over a historical window. But it cannot fully reproduce the live market path:

• prices move between evaluation and bet attempt,
• markets suspend,
• limits change,
• events start early or late,
• lineups and injuries arrive with messy timing,
• and your strategy may fire too often when many correlated markets appear together.

A backtest says, “this idea might deserve a live shadow run.” It should not say, “turn on live automation now.”

The gap between those two statements is where paper mode belongs.

Paper mode should be live except for money movement

A useful paper run uses the same strategy rules, odds source, worker schedule, settlement logic, and ledger shape that live mode would use. The only difference is that no bet is sent to Cloudbet.

That gives the user evidence about the whole system, not only the model. The ledger should show inspected markets, qualifying markets, simulated bet records, rejections, cap events, settlement, and timing.

If a strategy would have placed a bet but the odds moved outside the allowed range before action, that should be visible. If the daily bankroll cap prevented the sixth qualifying bet of the day, that should be visible. If settlement did not arrive cleanly, that should be visible.

Automation without visibility is just a faster way to be surprised.

Define promotion criteria before the run

Do not decide promotion criteria after a good week. Write them before the paper run starts.

A basic promotion checklist might include:

• minimum number of qualifying bets,
• maximum drawdown in simulated ledger,
• maximum rejected evaluations due to stale odds,
• settlement coverage rate,
• no single league or team dominating exposure,
• and no cap breaches that would have surprised the user.

The exact thresholds depend on the strategy. A narrow strategy may only fire a few times per week. A broad moneyline strategy may fire many times per day. The important part is that the rules are written before the outcome is known.

Inspect losing days first

Most users want to inspect the best simulated day. Start with the worst one.

A losing paper day reveals whether the strategy behaves like infrastructure or like a mood. Did it keep firing into a correlated market? Did it stake larger after losses? Did it ignore a cap? Did it chase the same event through multiple market types? Did it pause when data quality degraded?

The product should make these questions easy to answer. A simulated loss is not failure. An unexplained simulated loss is failure.

Paper runs expose product problems too

Paper-first is also how we find platform issues before they become expensive. A strategy may be conceptually sound while the implementation needs better defaults:

• a market filter is too broad,
• the odds window is too narrow,
• a rule name is ambiguous,
• the ledger needs a clearer rejection reason,
• or a cap should be shown before the user saves the strategy.

Those are product fixes, not betting outcomes. They are exactly what a paper-first launch process should surface.

When live mode becomes reasonable

Live mode is reasonable only when the user understands both the strategy and the failure modes. A good paper ledger should make the next step feel uneventful. The user should know the expected daily activity, typical stake range, rejection patterns, and worst simulated sessions.

Even then, the first live configuration should be smaller than ego wants. Low stake, hard daily cap, and a willingness to pause are features, not signs of doubt.

Glitch Edge does not exist to make users more aggressive. It exists to make their chosen automation more controlled.

The simple path

Start at the platform section. Connect the Cloudbet account, create one strategy, and keep it in paper mode. Use /pricing to understand the Free and Pro boundary: Free gives one paper strategy and a full ledger; Pro unlocks unlimited live strategies when the user is ready and eligible.

The right question is not “did the paper run make money this week?” It is “did the strategy behave exactly as I would want it to behave if real money had been on the line?”

If the answer is no, paper mode saved you from learning that lesson live.