Strategy Specification

This document defines the canonical JSON structure for a KEK strategy.

Strategies are machine-readable specifications that describe what to trade, when to trade, how to size positions, and which risk controls to enforce. They are generated by KEK Mix and validated through backtesting and paper trading before any optional live deployment.

This specification describes structure and intent. Implementation details (exact indicator libraries, execution adapters, exchange constraints) may evolve.

What this covers

Strategy object structure
Indicator + signal definition patterns
Risk and execution constraints
Validation rules and required fields
How strategy variants are represented

Design principles

Deterministic: A strategy spec should be executable without ambiguity.
Composable: Indicators and conditions are modular building blocks.
Validation-first: Specs are designed to pass through backtest → paper trading → monitoring.
Execution-separated: The spec describes intent; execution requires user authorization and a custody boundary.

Strategy object (high-level)

At minimum, a strategy must define:

Identity (id, name, version)
Market scope (assets, timeframe)
Signals (entry/exit)
Sizing
Risk controls

Minimum viable strategy (example)

{
  "id": "strat_001",
  "name": "SMA Cross (BTC-ETH)",
  "version": "1.0",
  "universe": {
    "assets": ["BTC", "ETH"],
    "quote": "USDT",
    "timeframe": "1h"
  },
  "signals": {
    "entry": [
      { "when": "crosses_above", "left": "sma_fast", "right": "sma_slow" }
    ],
    "exit": [
      { "when": "crosses_below", "left": "sma_fast", "right": "sma_slow" }
    ]
  },
  "indicators": {
    "sma_fast": { "type": "sma", "inputs": { "length": 20, "source": "close" } },
    "sma_slow": { "type": "sma", "inputs": { "length": 50, "source": "close" } }
  },
  "sizing": {
    "mode": "percent_equity",
    "value": 0.10
  },
  "risk": {
    "max_leverage": 2,
    "max_position_pct": 0.20,
    "max_total_exposure_pct": 0.50
  },
  "execution": {
    "mode": "paper"
  }
}

Full strategy schema (recommended fields)

Top-level fields

| Field | Type | Required | Notes | |-------|------|----------|-------| | id | string | ✅ | Stable unique identifier | | name | string | ✅ | Human-readable name | | version | string | ✅ | Spec version (e.g. "1.0") | | description | string | ⛔ | Optional summary | | universe | object | ✅ | Market scope and timeframe | | indicators | object | ✅ | Named indicator definitions | | signals | object | ✅ | Entry/exit conditions | | sizing | object | ✅ | Position sizing rules | | risk | object | ✅ | Risk constraints | | execution | object | ✅ | Execution intent and constraints | | variants | array | ⛔ | Optional parameter variants | | metadata | object | ⛔ | Tags, author, provenance, notes |

Universe

Defines what markets the strategy applies to.

{
  "assets": ["BTC", "ETH"],
  "quote": "USDT",
  "timeframe": "1h",
  "venue": "orderly",
  "market_type": "perp"
}

Notes:

venue and market_type are optional and may be enforced by the execution layer.
timeframe should be normalized (e.g., "1m", "5m", "15m", "1h", "4h", "1d").

Indicators

Indicators are named nodes that can be referenced by signals.

{
  "rsi_14": { "type": "rsi", "inputs": { "length": 14, "source": "close" } },
  "ema_50": { "type": "ema", "inputs": { "length": 50, "source": "close" } }
}

Conventions:

Indicator keys must be unique.
Each indicator must declare a type and inputs.
Inputs should be explicit and serializable.

Signals

Signals define entry/exit logic as structured conditions.

Condition shape (recommended)

A condition typically includes:

when (operator)
operands (e.g., left, right, value)
optional filters (additional constraints)

Example operators:

crosses_above, crosses_below
gt, gte, lt, lte, eq
and, or, not

{
  "entry": [
    {
      "when": "and",
      "conditions": [
        { "when": "crosses_above", "left": "ema_fast", "right": "ema_slow" },
        { "when": "lt", "left": "rsi_14", "value": 70 }
      ]
    }
  ],
  "exit": [
    { "when": "crosses_below", "left": "ema_fast", "right": "ema_slow" }
  ]
}

Sizing

Sizing defines how much exposure a strategy may take when signals trigger.

{
  "mode": "percent_equity",
  "value": 0.10,
  "max_positions": 3
}

Common modes:

percent_equity (fraction of equity per position)
fixed_notional (fixed quote size per trade)
volatility_target (risk-based sizing, if supported)

Risk controls

Risk controls define guardrails that must be enforced during simulation and execution.

{
  "max_leverage": 2,
  "max_position_pct": 0.20,
  "max_total_exposure_pct": 0.50,
  "stop_loss": { "type": "percent", "value": 0.02 },
  "take_profit": { "type": "percent", "value": 0.04 },
  "max_drawdown_pct": 0.15
}

Notes:

Risk controls may be enforced differently across backtesting vs paper trading vs live execution.
Constraints should be treated as hard limits, not targets.

Execution

Execution describes intent and constraints. It does not imply autonomous trading.

{
  "mode": "paper",
  "slippage_model": "conservative",
  "max_orders_per_hour": 12,
  "allowed_venues": ["orderly"]
}

Execution modes (typical):

paper — simulation under real market conditions
live — requires explicit user authorization and custody separation

Live execution is optional and should be treated as a separate deployment step.

Variants (optional)

Variants allow representing multiple parameter sets for the same base strategy.

{
  "variants": [
    {
      "id": "v1",
      "overrides": {
        "indicators.ema_fast.inputs.length": 20,
        "indicators.ema_slow.inputs.length": 60
      }
    },
    {
      "id": "v2",
      "overrides": {
        "indicators.ema_fast.inputs.length": 10,
        "indicators.ema_slow.inputs.length": 40
      }
    }
  ]
}

Variant selection may be informed by validation results, drift monitoring, or user intent.

Validation rules (baseline)

A strategy spec should be considered valid if:

Required fields are present (id, name, version, universe, signals, indicators, sizing, risk, execution)
universe.assets contains at least one supported asset symbol
timeframe is normalized and supported by the data layer
All referenced indicator keys exist (e.g., signals referencing rsi_14 must define it)
sizing.value and risk limits are within sane bounds (implementation-defined)
Strategy conditions are structurally valid (operators have required operands)

Validation may also include:

Guarding against contradictory rules
Preventing impossible sizing (e.g., >100% per position)
Enforcing venue constraints for live deployment