Strategy Family

A strategy family is a set of strategy rows that descend from one shared intent — one template, fanned out across symbols, intervals, and leverages. Every row in the family carries the same templateId (a TEXT NOT NULL handle on the strategies table), so the question "which rows came from the same idea?" survives even after the template is expanded into individual (symbol, interval, leverage) leaves.

This dossier IS one family

All 210 strategies in the EMA-cross dossier descend from a single fleet spec (one template, run 83). That is a strategy family at its largest scale: one idea — "EMA crossover" — expanded across 3 symbols (BTC/ETH/SOL), several EMA pairs, 5 leverages (1/2/10/50/100×), two sides (long/short), and an optional volume gate.

Inside that big family sit tighter subfamilies that share more than just the signal. The clearest is the 21/50 · SOL · 1h · long subfamily, where the only thing varying is leverage (a position-size multiplier that scales both profit and loss):

Strategy	Leverage	Trades	Win rate	The relationship
id659	1×	436	31.9%	the un-leveraged base
id523	2×	436	31.9%	same 436 trades, scaled risk
id524	10×	436	31.7%	same signal, far deeper drawdown

These rows fire the same trades — the crossover signal doesn't know what leverage you picked. Leverage only scales the PnL and the drawdown on those identical trades. id659 (1×) bottoms at −5.06% drawdown; id524 (10×) at −41.8%. Same decisions, very different survival.

Why a family is useful — the anti-selection-bias check

A family lets you check consistency across siblings. If a signal has a real edge, the whole subfamily should agree about it — vary the leverage and the significance verdict should not flip, even though the PnL does. id659 and id523 are both edge-significant on the same 436 trades, which is exactly the kind of cross-sibling agreement that makes an edge more believable. This is an anti-selection-bias check: it stops you from cherry-picking the one leverage that happened to print the prettiest number, because the family forces you to look at all of them at once.

Why it exists

Before Phase 125, strategies were symbol-independent templates that fanned out across ENABLED_SYMBOLS at registration time. After Phase 125, each strategy row is one (symbol, interval, leverage) leaf. The family identity — "these N rows came from the same intent" — would have been lost if not captured at row-creation time. templateId preserves it.

How templateId is assigned

• POST /api/strategies (live spawning): Backend mints one UUID per request via crypto.randomUUID(). Every row produced by the cartesian expansion intervals × leverages × symbols shares that UUID. The frontend never sends or sees a templateId pre-write; the response includes it for any future grouping client-side.
• Migration 004 backfill: One UUID was minted per pre-existing strategy row. Each backfilled split (one per ENABLED_SYMBOLS entry) inherited the same UUID. This means a single pre-Phase-125 row that ran on three symbols collapses into three rows in one family.

What it is NOT (yet)

Phase 125 deliberately ships no family UX:

• No group banner rows in the leaderboard.
• No group-level bulk enable/disable/delete.
• No groupBy=family toggle.
• No "spawn this template onto a new symbol" affordance.

The leaderboard ships flat (one row per leaf) — by design. The pain of scanning a large flat fleet motivates Phase 128's grouping work.

Future UX (Phase 128)

Phase 128 owns family-rollup UX. The expected affordances:

• groupBy=family toggle in the leaderboard collapsing siblings into one banner row.
• subgroupBy=symbol (or interval, or leverage) for nested rollup.
• Group-level bulk actions.
• Possibly: a "spawn existing template onto new symbol(s)" shortcut.

Related

• ema cross — the signal every family in this dossier shares; the 21/50 · SOL · 1h · long subfamily (id659/id523/id524) is a concrete example.
• sample size — family pooling as a sample-size mitigation.
• edge — family pooling as an edge-confirmation tactic.