Rainwater publishes performance numbers — both backtest and live. This page explains how those numbers are produced, what they include, and what they don't. Read it before you draw conclusions from any chart on this site.

We publish it because SEC Rule 206(4)-1 (the Marketing Rule) requires methodology to sit at comparable prominence to any hypothetical or historical performance figure we show, and because we want a sophisticated reader to be able to verify what they're looking at without having to ask.

Cloudburst v1.5 — an opening-range-breakout options strategy on QQQ. Entries are decided by deterministic rules, not AI; narrow AI layers operate only after a position is open and never decide whether to enter. Universe is QQQ only. Instruments are short-DTE options, with 0DTE preferred and a hard maximum of 3 DTE.

Each weekday runs its own profile, tuned from years of underlying data — different days exhibit different intraday character, and the strategy adapts. The strategy takes one to two trades per day depending on tier, with a fixed per-trade premium budget and a hard daily loss-lock. Specific entry parameters, day-of-week profiles, and internal layer mechanics are proprietary and not published here. What is published is the resulting equity curve and the methodology behind how those numbers are produced.

Backtest spec figure. The headline backtest baseline (Cloudburst v1.5, Standard tier at ~2-contract average sizing) is 381 trades, 70.3% win rate, 3.6 profit factor, +$21,715 net, with a maximum drawdown of −$334, measured over the causal real-options window (Jan 2022 → May 2026) for v1.5. Both risk tiers and both sizing bases are shown on the strategy page; the full underlying dataset is internal and we are working on publishing the trade-by-trade ledger.

Equity-only ORB sub-backtests. Sub-strategy backtests in the internal repo cover a 491-trade window over roughly 1.5 years with 62-66% win rates depending on phase configuration. These cover the equity-only ORB lanes, not the full Cloudburst v1.5 options stack, and are listed here for completeness only.

Undertow v3 backtest. 15 trading days, from 2026-02-23 through 2026-04-16. The v1 detector alone produced 11 fires at a 91% win rate and +6.94R. The v2 detector alone produced 14 fires at a 93% win rate and +9.97R. The shipped v3 detector restores v1's coverage while keeping v2's exhaustion guard.

Admission-stack overlay. The admission filter that gates whether the first trade of the day is allowed to fire was backtested over 29 trading days, from 2026-03-09 through 2026-04-17. Net contribution was +$71 — three losers blocked and two winners blocked.

Data source. Alpaca IEX 1-minute bars for the underlying. Option premium fills are modeled at the midpoint of the bid-ask spread with realistic slippage applied; live fills can deviate from this in either direction.

What the backtest does NOT include. The $99/month subscription fee is not deducted. Broker commission is not modeled (Public.com is commission-free, but other brokers vary). Per-trade slippage above the modeled midpoint is not included. Exchange fees and taxes are not included. None of these are catastrophic, but a reader projecting future net-of-everything returns from the backtest figure should know they're not in the number.

Baseline. The live track record begins with a $572.59 starting balance on 2026-03-27 in Q's real-money Public.com cash account. Realized P&L tracks positive and grows as the account keeps trading — the current live figure is shown on /run and refreshed daily after the close.

Where it's published. Live data is shown at /run and on the homepage hero panel. It refreshes daily after the 16:15 ET market-close cron pulls Public.com's account API and transaction history into our database. No Vercel rebuild and no manual step is required between the cron firing and the number changing on the site.

Excluded round-trips. The live record excludes two known-bug trades from 2026-04-10 — a pair of round-trips on QQQ260410C00611000 that fired during a code crash-loop, not as strategy decisions. Including them in the headline P&L would still be honest; we exclude them only from per-trade win-rate stats. They appear on the equity curve and in the trade list.

Live is not the backtest. Live results to date have tracked above the backtest win rate, but on a much smaller sample. Expect convergence over time, with some days going the other way.

Hypothetical performance does not represent actual trading and may not reflect material market or economic factors. Past performance does not guarantee future results. Live trading involves risks not present in a backtest, including slippage, partial fills, broker outages, and human error.

Every performance figure on the site sources from one of the following:

• Hero KPI “Live” panel — pulled live from the Public.com account API and the Postgres site_state row written by the daily 16:15 ET cron.
• Hero KPI “Strategy spec” panel — the v1.5 backtest spec figures described in section 3 above (381 trades, 70.3% win rate, 3.6 profit factor, +$21,715 net).
• Calculator persona projections — a hypothetical projection model implemented in rainfall-projection.ts. The hypothetical-performance banner sits at comparable prominence at the top of the calculator page.
• Pricing-page win-rate pills — the backtest spec figure (same source as the hero strategy-spec panel).
• Trade-by-trade list at /run — live broker fills only, paginated from the Public.com transaction history API. No backtest data, no synthetic fills.

The backtest assumes deterministic rules execute correctly. Live results include the cost of any bugs we've shipped that affected an actual fill, the cost of any missed fill from infrastructure outages, and the realized impact of slippage that differed from the modeled midpoint. Backtest and live will diverge on small samples; we expect that, and the only honest response is to publish both side by side so a reader can judge for themselves.

The most relevant example to date is the 2026-04-13 incident — a loss caused by a code bug in the pullback evaluator. The bug was identified and fixed the same evening, and a public post-mortem was published. See /incidents/2026-04-13 for the write-up. That trade sits in the live record; it does not sit in the backtest. This is the kind of cost the live forward-test exposes that a backtest by design cannot.

Questions on methodology, or want the underlying ledger? marquise@rainwater.run.