Strategy Specs

A strategy spec is Studio's structured format for prediction market strategy execution. It is the reviewable output Studio uses to turn a natural-language trading idea into something that can be backtested, reviewed, and deployed.

A strategy spec is intentionally narrower than a general programming language. It should express the strategy surface: what market to watch, what data to use, when to enter, when to exit, how much risk to take, and when to stop.

Why Strategy Specs Exist

AI is good at drafting strategy logic, but arbitrary generated code is hard to audit. Strategy specs give Studio a safer target:

readable enough for humans to inspect,
structured enough for validation,
constrained enough for backtesting,
portable enough for deployment,
explicit enough to revise without losing the original thesis.

The strategy format is the source of truth. Generated runtime artifacts are derived from it.

Shape of a strategy

A Studio strategy spec usually answers these questions:

Question	Strategy spec area
What venue or market family is this for?	`platform` and `market`
What kind of strategy is this?	`strategy`
How often should it evaluate?	`loop`
What data does it need?	`market` and `edge` references
When should it act?	`rules` or strategy parameters
How much can it risk?	`risk`
When should it stop?	exits, pauses, and guardrails

Example:

version: 1
platform: kalshi
strategy: mean_reversion
market:
  series_ticker: KXBTC
loop:
  interval_seconds: 60
risk:
  max_position_usd: 300
  max_order_size_usd: 25
  price_floor: 0.08
  price_ceiling: 0.92
  stop_opening_minutes_before_close: 30
edge:
  coinbase_btc:
    provider: coinbase
    symbol: BTC-USD
rules:
  enter:
    when: coinbase_btc.return_15m > 0.012 and market.mid_move_15m < 0.04 and market.spread <= 0.06
    side: yes
  exit:
    when: coinbase_btc.return_15m < 0 or market.minutes_to_close < 30

The exact fields available can change as Studio adds supported strategy types and venues, but the design principle should stay the same: write the user's intent as explicit, bounded rules.

Market selectors

Strategies should identify their market scope as precisely as possible.

Common selector patterns include:

a specific venue market,
a venue event,
a venue series,
a query that Studio resolves before backtesting or deployment.

Prefer exact selectors when the user already knows the market. Use discovery-style selectors when the user is still exploring.

Strategy types

Studio can draft several common strategy families:

Strategy type	Typical use
`spread_capture`	Post maker quotes when the spread is wide enough to compensate for risk.
`mean_reversion`	Fade a price move when the move exceeds a threshold and supporting data disagrees.
`panic_fade`	Enter after a sharp dislocation, then exit when the market normalizes.
`observation_momentum`	Follow a signal when external observations confirm the move.
`pre_announcement_drift`	Trade around scheduled information releases with strict timing rules.
`custom`	Compose explicit rules when a named strategy family is not enough.

Use named strategy types when they fit. Use custom only when the behavior really needs a rule expression.

Risk fields

Risk should be present in every serious draft.

Useful fields include:

maximum total position,
maximum order size,
price floor and ceiling,
spread limits,
minimum liquidity,
stop-opening window before close,
stale-data behavior,
daily loss or drawdown pause,
maximum number of open markets,
cancel conditions for maker orders.

AI agents should not remove risk fields to make a backtest look better. If a backtest improves only after risk limits are loosened, that is a result to explain, not a result to hide.

Edge data references

Strategy specs can reference supported external data. Today this includes edge data such as:

historic Coinbase data for crypto-linked strategies,
National Weather Service data for weather-linked strategies.

A strategy should define how edge data affects behavior:

edge:
  nws_chicago:
    provider: nws
    station: chicago
rules:
  enter:
    when: nws_chicago.forecast_probability < market.yes_mid - 0.10 and market.spread <= 0.05

If the edge data is unavailable or stale, the safe behavior is to avoid opening new risk.

Good Strategy Spec Habits

Keep strategy names descriptive.
Put hard risk constraints near the top.
Use comments sparingly when they explain user intent.
Prefer simple thresholds before complex formulas.
Use one market family per draft unless the strategy is explicitly cross-market.
Backtest every material change.
Keep live deployment behavior aligned with the backtested strategy spec.

What Not to Put in Strategy Specs

Do not use strategy specs as a place to encode private implementation details. They should not need internal service names, database structure, cloud topology, or proprietary deployment plumbing.

The public contract is strategy behavior. The user and AI agent should be able to understand the strategy without reading Turbine's internals.