# PoC Trading Swarm — Validazione Strategica

**Autore**: Adriano Dal Pastro
**Data**: Maggio 2026
**Status**: Design document — pre-implementazione
**Versione**: 0.1
**Documento correlato**: `coevolutive_swarm_system.md` (sistema completo)

---

## 1. Razionale della deviazione

Invece di committere 12-18 mesi al sistema co-evolutivo completo descritto nel documento principale, partiamo con un **proof-of-concept strategico** focalizzato su trading, con architettura semplificata, per validare empiricamente se l'idea di base funziona prima di investire nel sistema full.

**Cosa il PoC valida**:
1. Lo swarm produce strategie che superano il null hypothesis statistico (Deflated Sharpe Ratio significativo)?
2. Le strategie sono qualitativamente diverse o cloni leggeri?
3. Le strategie sopravvivono al regime change out-of-sample?
4. Quanto del successo viene da modelli costosi vs economici (ablation multi-tier)?
5. Lo swarm batte una baseline statistica tradizionale (random forest + feature engineering)?

**Tempo target**: 3-4 mesi a impegno significativo.
**Budget LLM target**: $2-4K.

**Decisione post-PoC**:
- Se passa tutti i 5 test → procedere con sistema completo (documento principale)
- Se passa parzialmente → iterare sul PoC, identificare bottleneck
- Se non passa → riformulare. Forse l'edge degli LLM agents è in altri domini, non in pattern discovery numerico

---

## 2. Architettura semplificata

### 2.1 Cosa cambia rispetto al sistema completo

| Aspetto                | Sistema completo            | PoC                                |
|------------------------|-----------------------------|------------------------------------|
| Popolazioni evolventi  | 4 (3 layer + protocollo)    | 1 (solo Hypothesis)                |
| Hypothesis layer       | Evolve via GA               | Evolve via GA (K=50)               |
| Falsification layer    | Evolve via GA               | Hand-crafted, 1 agente fisso       |
| Adversarial layer      | Evolve via GA               | Hand-crafted, 1 agente fisso       |
| Protocollo             | Co-evolve                   | Fisso, designed manualmente        |
| Domini di applicazione | Multipli                    | Solo trading BTC/ETH               |
| Idiom emergence        | Sì                          | No                                 |
| Speciation             | Sì                          | Versione semplificata (clustering base) |
| Tier multi-model       | Sì (S/A/B/C/D)              | Sì (semplificato a B/C principalmente) |
| Human-in-the-loop      | Strutturato ogni 20 gen     | Review settimanale informale       |

**Filosofia**: massimizzare apprendimento, minimizzare complessità implementativa.

### 2.2 Schema architetturale

```
                ┌───────────────────────────────────┐
                │   PROTOCOLLO FISSO (S-expression) │
                │   ~15 verbi designed manualmente  │
                └─────────────┬─────────────────────┘
                              │
                              ▼
   ┌──────────────────────┐
   │  HYPOTHESIS SWARM    │   ← UNICO layer che evolve
   │  K=50 agenti         │
   │  Tier mix: B/C       │
   │  GA: tournament,     │
   │  speciation base,    │
   │  novelty bonus       │
   └──────────┬───────────┘
              │ ipotesi formalizzate
              ▼
   ┌──────────────────────┐
   │ FALSIFICATION (hand) │   ← FISSO
   │ 1 agente Tier-B      │
   │ Funzione: traduce    │
   │ ipotesi in regole +  │
   │ chiama backtest +    │
   │ valuta con DSR       │
   └──────────┬───────────┘
              │ strategie validate
              ▼
   ┌──────────────────────┐
   │ ADVERSARIAL (hand)   │   ← FISSO
   │ 1 agente Tier-A      │
   │ Funzione: red team   │
   │ con checklist statica│
   │ (lookahead, regime,  │
   │ crowding)            │
   └──────────┬───────────┘
              │ strategie sopravvissute
              ▼
   ┌──────────────────────┐
   │   FITNESS LOOP       │
   │   Update agent_fitness│
   │   Selezione + GA     │
   └──────────────────────┘
              │
              ▼
        Generazione N+1
```

---

## 3. Le quattro trappole del backtesting su crypto

Queste sono le killer specifiche del dominio. Vanno mitigate by design, non come afterthought.

### 3.1 Look-ahead bias subdolo

**Problema**: molti dati "storici" su crypto sono in realtà revisionati ex-post.
- Funding rates: spesso medie giornaliere ricalcolate, non valori real-time storici
- On-chain metrics (MVRV, NUPL, SOPR): formule che cambiano nel tempo, applicate retroattivamente
- Liste top-N token: survivorship bias massiccio
- Sentiment storico: ricostruzioni post-hoc, non disponibili in tempo reale a quei momenti

**Mitigazione**:
- Ogni feature deve avere un campo `availability_lag`: quante ore dopo il timestamp T la feature era effettivamente disponibile
- Backtest engine rifiuta di usare feature prima del lag
- Documentazione esplicita di come/quando ogni feature è stata raccolta
- Preferire fonti che pubblicano archivi real-time (Kaiko, Tardis.dev, Amberdata) a quelle ricostruite

### 3.2 Multiple testing su scala industriale

**Problema**: con 10000 strategie testate, ~100 superano p<0.01 per puro caso. Senza correzione, il sistema produce sempre "vincitori" illusori.

**Mitigazione**:
- **Deflated Sharpe Ratio (DSR)** come fitness primaria, non Sharpe naive
- Tracking del numero totale di strategie testate fino a generazione N (impatta DSR)
- Bonferroni-style correction quando si seleziona "top strategies" da reporting
- Hold-out set finale **mai toccato durante evoluzione** per validation finale

### 3.3 Regime dependency

**Problema**: BTC/ETH hanno regimi macro molto diversi. Una strategia che funziona 2018-2024 può essere semplicemente "long-only momentum con leva". OOS 2026 fallisce.

**Periodi di regime distintivi**:
- 2017: bull mania retail (escluso dal dataset, troppo anomalo)
- 2018-2019: bear lungo
- 2020-2021: DeFi summer + bull istituzionale + COVID
- 2022: collapse cycle (LUNA, FTX, Celsius)
- 2023-2024: ripresa + ETF spot
- 2025-2026: post-ETF, regime nuovo

**Mitigazione**:
- Walk-forward con **purged cross-validation** (López de Prado 2018)
- Train su finestra mobile, test su successiva, **gap di purging** in mezzo per evitare leakage
- Fitness penalizza strategie che funzionano solo su 1-2 regimi
- OOS finale obbligatoriamente su periodo diverso dal training

### 3.4 Backtest ≠ live execution

**Problema**: anche backtest perfetto ha gap col live.
- Slippage non lineare con size (su crypto particolarmente)
- Fees variabili (maker/taker, volume rebates)
- Funding rate sui perp può mangiarsi l'edge
- Liquidità evapora nei momenti che contano
- API outages, exchange downtime

**Mitigazione**:
- Modello di slippage realistico (Almgren-Chriss o simile, non costante)
- Fees accurate (struttura tier per exchange)
- Funding payments simulati per posizioni perp
- Cap su size per evitare strategie che funzionano solo a $100, non a $100K

---

## 4. Dataset Specification

### 4.1 Coverage

- **Asset**: BTC, ETH (focus iniziale)
- **Periodo**: 2018-01-01 → 2025-12-31
- **Train/OOS split**: train 2018-2023, OOS validation 2024, OOS final hold-out 2025
- **Frequenza base**: 1-hour bars (compromesso tra granularità e gestibilità)
- **Frequenze derivate**: 4h, 1d aggregate per features di lungo periodo

### 4.2 Feature catalog

**Price/Volume (sempre disponibili real-time, lag=0)**:
- OHLCV su 1h, 4h, 1d
- Returns log su orizzonti multipli
- Volatility realized (Garman-Klass, Parkinson, RV)
- Volume profile, VWAP

**Derivatives (lag tipicamente 5-15min)**:
- Funding rates (Bybit, Binance, Hyperliquid, Deribit)
- Open Interest (per exchange e aggregato)
- Put/Call ratio (Deribit options)
- Implied volatility surface (Deribit)
- Skew, term structure
- Liquidations (volume e direzione)

**On-chain (lag tipicamente 1-6 ore per finalization)**:
- Active addresses
- Transaction count + volume
- Exchange inflows/outflows (Glassnode-style)
- Miner flows
- Whale transactions (>$1M)
- MVRV, NUPL, SOPR (con cautela su revisionalità)

**Macro context (lag variabile)**:
- DXY, gold, S&P 500, yield 10Y (per correlazioni)
- Crypto-specific: BTC dominance, ETH/BTC ratio, total market cap
- Stablecoin supply (USDT, USDC, DAI)

**Sentiment (lag variabile, qualità incerta)**:
- Funding rate come proxy sentiment
- Open Interest variations come proxy speculation
- (Skip Twitter/social per ora — qualità storica troppo bassa)

### 4.3 Data sources

**Preferiti** (real-time archivi):
- Tardis.dev (derivatives, order book, trades — premium)
- Kaiko (institutional grade — premium)
- Amberdata (multi-source)

**Backup gratuiti/cheap**:
- CCXT historical (OHLCV affidabile)
- Binance/Bybit/Deribit API direct (con cautela su gap)
- CoinGlass (derivatives aggregati, qualità media)
- Glassnode free tier (on-chain, limitato)

**Da evitare**:
- Aggregatori che non documentano metodologia
- Source che hanno cambiato formula nel tempo senza versioning

### 4.4 Storage

```sql
CREATE TABLE features (
    timestamp TIMESTAMPTZ NOT NULL,
    asset TEXT NOT NULL,
    feature_name TEXT NOT NULL,
    value DOUBLE PRECISION,
    availability_lag_seconds INT NOT NULL,  -- CRITICO
    source TEXT,
    version TEXT,  -- per gestire cambi di metodologia
    PRIMARY KEY (timestamp, asset, feature_name)
);

CREATE INDEX idx_feat_time ON features (timestamp);
CREATE INDEX idx_feat_asset_name ON features (asset, feature_name);
```

Considerare TimescaleDB se le query temporali diventano colli di bottiglia.

---

## 5. Backtest Engine

### 5.1 Requisiti

- **Determinismo**: stesso input, stesso output, sempre
- **Velocità**: target ≥100 backtest/sec su CPU normale (per gestire 50 agenti × 10 ipotesi/gen)
- **Anti-leakage by design**: rifiuta feature prima di availability_lag
- **Walk-forward integrato**: non opzionale, parte del flow base
- **Realistic execution**: slippage, fees, funding

### 5.2 Architettura

**Linguaggio**: Python+NumPy per il PoC. Rust+PyO3 solo se diventa bottleneck (probabile in fase scaling, non necessario per PoC).

**API base**:
```python
class BacktestEngine:
    def run(self, 
            strategy: StrategySpec,
            features: FeatureSet,
            time_range: tuple[datetime, datetime],
            walk_forward_config: WFConfig) -> BacktestResult:
        ...
    
    def run_with_dsr(self,
                     strategy: StrategySpec,
                     ...) -> tuple[BacktestResult, DSRStats]:
        ...

@dataclass
class StrategySpec:
    entry_rules: list[Rule]      # condizioni di ingresso
    exit_rules: list[Rule]       # condizioni di uscita
    sizing: SizingRule           # position sizing
    instruments: list[str]       # BTC, ETH, BTC-PERP, etc.
    constraints: list[Constraint] # max leverage, max DD, etc.

@dataclass
class BacktestResult:
    pnl_curve: pd.Series
    sharpe: float
    sortino: float
    max_drawdown: float
    n_trades: int
    win_rate: float
    avg_holding_time: timedelta
    fees_paid: float
    funding_paid: float
    slippage_cost: float
    regime_breakdown: dict[str, float]  # PnL per regime
```

### 5.3 Execution model

**Slippage**:
```
slippage = base_spread + impact_factor * (size / avg_volume_5min) ^ 0.5
```
Calibrato su book reale per BTC/ETH. Più alto in regimi di alta volatilità.

**Fees**:
- Maker: 0.02% (tipico)
- Taker: 0.05% (tipico)
- Tier per volume non simulato nel PoC (assume tier base)

**Funding** (per perp):
- Pagato/ricevuto ogni 8 ore
- Calcolato su mark price × position size × funding rate

**Constraints automatiche**:
- Max leverage (configurabile, default 5x per il PoC)
- Margin call simulati realisticamente
- Liquidations forzate se margin scende sotto threshold

### 5.4 Walk-forward purged CV

```
Time:    |---------train-----------|gap|----test----|---next gap---|--next test--|
Window 1: [2018-01 ──────── 2020-06] [2020-07 ──── 2020-12]
Window 2:           [2018-07 ──── 2021-06] [2021-07 ──── 2021-12]
Window 3:                     [2019-01 ── 2022-06] [2022-07 ── 2022-12]
...
```

- Training window: 30 mesi
- Gap (purging): 1 mese (evita leakage da event horizon)
- Test window: 6 mesi
- Step: 6 mesi
- Embargo: ulteriori 2 settimane post-test prima del prossimo training (López de Prado embargo)

---

## 6. Hypothesis Swarm (l'unico layer che evolve)

### 6.1 Genome design

```python
@dataclass
class HypothesisAgentGenome:
    # Cognizione
    system_prompt: str
    cognitive_style: str  # "physicist", "biologist", "engineer", "trader_oldschool"...
    
    # Accesso a dati
    feature_access: list[str]  # subset delle feature disponibili
    lookback_window_days: int  # quanto storico vede
    timeframes: list[str]  # ["1h", "4h", "1d"]
    
    # Modello
    model_tier: ModelTier  # B o C principalmente nel PoC
    temperature: float  # 0.6 - 1.2
    
    # Bias di output
    strategy_type_preference: list[str]  # ["mean_reversion", "momentum", "vol_arb", "cross_asset"]
    timeframe_preference: str  # "intraday", "swing", "position"
    
    # Tracking
    parent_ids: list[UUID]
    generation: int
    species_id: UUID
```

### 6.2 Output format (nel protocollo fisso)

```
PROPOSE_STRATEGY(
  id=#strat_47,
  name="vol_skew_momentum",
  
  entry_conditions=[
    AND(
      (deribit_skew_25d > rolling_mean(deribit_skew_25d, 30d) + 1.5*std),
      (btc_funding_8h > 0.01),
      (eth_funding_8h > btc_funding_8h)
    )
  ],
  
  exit_conditions=[
    OR(
      (skew normalized below mean),
      (max_holding > 7d),
      (drawdown > 0.03)
    )
  ],
  
  sizing=KELLY_FRACTIONAL(fraction=0.25),
  instruments=["ETH-PERP-HL"],
  side="long",
  
  rationale="Skew elevato indica fear di puts, funding alto indica long crowding. Cross-section ETH/BTC funding suggerisce ETH outperformance attesa.",
  
  expected_regime="normal volatility, trending",
  expected_failure_modes=["crash con depinning", "regime shift improvviso"]
)
```

### 6.3 Operatori genetici

**Mutazione del system prompt**:
- LLM-as-mutator (Tier-B): "Modifica questo prompt cambiando un aspetto cognitivo, mantenendo intent"
- Probabilità: 60% per agente selezionato

**Mutazione di feature_access**:
- Add/remove 1-3 feature random
- Probabilità: 30%

**Mutazione di temperature**:
- Gaussiana, σ=0.1, clip [0.3, 1.4]
- Probabilità: 20%

**Crossover**:
- 50/50 di feature_access da due parent
- Cognitive_style preso da parent migliore
- System prompt: crossover sezione-by-sezione (role/context/instructions/output_format)
- Probabilità: 50% per nuova generazione (resto è mutazione)

**Mutazione di model_tier**:
- Rara (5%), perché impatta costo
- Solo C↔B, non promozioni a A senza fitness eccezionale

### 6.4 Selection

**Tournament selection**, k=5.

**Speciation semplificata**:
- Embedding del system prompt via Voyage o OpenAI ada
- K-means con K=5-7 cluster
- Fitness sharing dentro cluster

**Elitismo**: top 3 agenti per cluster sopravvivono non modificati.

**Immigrazione**: ogni 10 generazioni, 5 nuovi agenti random vengono inseriti (anti-stagnazione).

---

## 7. Falsification Agent (hand-crafted, fisso)

### 7.1 Ruolo

Prende ipotesi dal swarm, le esegue su backtest engine, riporta risultati con DSR e diagnostica.

**NON** valuta soggettivamente. Esegue test deterministici e li interpreta.

### 7.2 Modello

Tier-B (Qwen Max o equivalente). Sufficiente per:
- Tradurre ipotesi in linguaggio naturale → StrategySpec strutturato
- Chiamare backtest engine
- Interpretare output numerico
- Riportare in protocollo

### 7.3 System prompt template

```
Sei un agente di falsification rigoroso. Il tuo ruolo è testare ipotesi 
trading senza pregiudizi e riportare risultati onesti.

Per ogni ipotesi ricevuta:
1. Verifica che le entry/exit conditions siano formalizzabili in regole testabili
2. Verifica che le feature richieste rispettino availability_lag
3. Chiama il backtest engine con configurazione walk-forward standard
4. Calcola Deflated Sharpe Ratio considerando il numero di test fatti finora ({total_trials})
5. Riporta breakdown per regime (bear/bull/sideways)
6. Identifica failure modes osservati nel backtest

Output strict in protocollo S-expression. Nessuna interpretazione narrativa.
Se l'ipotesi non è formalizzabile, ritorna REJECT con motivo specifico.
```

### 7.4 Output format

```
REPORT_BACKTEST(
  target=#strat_47,
  
  metrics=(
    sharpe=1.34,
    deflated_sharpe=0.87,
    p_value=0.04,
    max_drawdown=0.18,
    n_trades=143,
    avg_holding_h=42
  ),
  
  regime_performance=(
    bear_2018=0.42,
    bull_2020=2.1,
    crash_2022=-0.85,
    recovery_2023=1.1
  ),
  
  warnings=[
    "Performance dominated by 2020-2021 regime",
    "DSR significant but multiple testing burden high (8400 strategies tested)"
  ],
  
  verdict=PASS_WITH_WARNINGS  // PASS / FAIL / PASS_WITH_WARNINGS
)
```

---

## 8. Adversarial Agent (hand-crafted, fisso)

### 8.1 Ruolo

Per ogni strategia che passa Falsification, applica una **checklist statica** di attacchi epistemici.

Nel PoC NON evolve. Ha vocabolario fisso di attacchi noti dalla letteratura (López de Prado, Bailey, etc.).

### 8.2 Modello

Tier-A (Sonnet). Qui il reasoning conta — riconoscere lookahead bias subtle richiede capacità.

### 8.3 Checklist di attacchi

```
1. Lookahead bias check
   - Tutte le feature usate rispettano availability_lag?
   - Qualche feature è "future-derived" subdolamente?

2. Survivorship bias check
   - La strategia usa universo di asset dinamico?
   - Filtra solo asset sopravvissuti?

3. Regime dependency check
   - Performance concentrata in 1-2 regimi specifici?
   - Cosa succede se rimuovi il regime migliore?

4. Multiple testing severity
   - DSR resta significativo dopo Bonferroni stretto?
   - Confronto con random strategy baseline

5. Crowding plausibility
   - La logica è "ovvia"? Probabilmente già crowded
   - Edge size ragionevole o sospettosamente alto?

6. Implementation friction
   - Slippage assumption realistica per la size?
   - Funding payments inclusi correttamente?
   - Trade frequency compatibile con execution reale?

7. Feature stability
   - Le feature critiche hanno stessa metodologia in tutto il periodo?
   - Source provider ha cambiato formula?

8. Statistical robustness
   - Sharpe sensibile a rimozione top 5% trade?
   - Performance robusta a perturbazioni piccole nei parametri?
```

### 8.4 Output

```
ADVERSARIAL_REVIEW(
  target=#strat_47,
  attacks_passed=[1, 2, 5, 6, 7],
  attacks_failed=[3, 4, 8],
  
  critical_concerns=[
    CONCERN(
      type=regime_dependency,
      severity=high,
      detail="60% of PnL from 2020-2021 bull regime. Removing it gives Sharpe 0.4."
    ),
    CONCERN(
      type=multiple_testing,
      severity=medium,
      detail="DSR significant but only marginally (p=0.04). With 8400 trials, expect ~336 false positives at this level."
    )
  ],
  
  verdict=REJECT  // ACCEPT / ACCEPT_CONDITIONAL / REJECT
)
```

---

## 9. Fitness Function

### 9.1 Agent fitness (per Hypothesis swarm)

```python
def agent_fitness(agent: HypothesisAgentGenome,
                  episodes: list[Episode]) -> float:
    
    # Quality of contributions
    accepted_strats = [e for e in episodes 
                       if e.adversarial_verdict == "ACCEPT"]
    conditional_strats = [e for e in episodes
                          if e.adversarial_verdict == "ACCEPT_CONDITIONAL"]
    
    quality_score = (
        len(accepted_strats) * 1.0
        + len(conditional_strats) * 0.3
    )
    
    # Average DSR of accepted strategies
    avg_dsr = np.mean([e.dsr for e in accepted_strats]) if accepted_strats else 0
    
    # Cost penalty (proporzionale al tier usato)
    cost_per_episode = TIER_COST[agent.model_tier] * agent.avg_tokens_per_episode
    cost_penalty = cost_per_episode * COST_PENALTY_LAMBDA
    
    # Novelty bonus (semantica delle strategie prodotte)
    novelty_score = compute_novelty(agent, all_agents_in_generation)
    
    # Diversity bonus (strategie diverse, non cloni)
    diversity_score = compute_internal_diversity(agent.strategies)
    
    return (
        quality_score
        + avg_dsr * DSR_WEIGHT
        + novelty_score * NOVELTY_WEIGHT
        + diversity_score * DIVERSITY_WEIGHT
        - cost_penalty
    )
```

### 9.2 Pesi iniziali (da calibrare empiricamente)

```python
DSR_WEIGHT = 2.0          # peso forte: vogliamo edge reale
NOVELTY_WEIGHT = 0.5      # bonus moderato per esplorazione
DIVERSITY_WEIGHT = 0.3    # leggero, evita cloni
COST_PENALTY_LAMBDA = 0.1 # da calibrare in base a budget
```

### 9.3 Anti-gaming

- Tracking globale del numero di test fatti per DSR correction
- Cap su `quality_score` per evitare gaming via spam di ipotesi banali
- Adversarial feedback va in fitness (strategie REJECTED penalizzano, non solo non bonificano)
- Periodic audit umano: ogni 10 generazioni rivedere top 5 strategies, marcare "spurious" se gaming

---

## 10. Baseline non-LLM (anti-illusion check)

**Critico**: il PoC deve includere una baseline statistica tradizionale.

### 10.1 Specifica baseline

- **Metodo**: Random Forest + feature engineering manuale
- **Features**: stesso pool del swarm
- **Target**: returns N-bar future (predizione regression o classification)
- **Validation**: stesso walk-forward purged CV
- **Output**: trade signals → backtest engine identico

### 10.2 Confronto

| Metrica                    | Baseline RF | Swarm LLM |
|----------------------------|-------------|-----------|
| Best DSR found             |     ?       |    ?      |
| Avg DSR top-10 strategies  |     ?       |    ?      |
| N strategies passing adv.  |     ?       |    ?      |
| Diversity (semantic)       |     ?       |    ?      |
| Total cost                 |   ~$50      |  ~$3K     |

**Interpretazione**:
- Se Swarm batte significativamente Baseline → architettura LLM sta aggiungendo valore
- Se Swarm pareggia → costo non giustificato per discovery numerica pura
- Se Swarm perde → l'edge degli LLM agents è altrove (creatività su task non numerici, integrazione semi-strutturata)

**Punto importante**: anche se Swarm perde su pattern discovery numerico, NON significa che il sistema co-evolutivo completo è inutile. Significa che la value-add è in altri domini (ipotesi macro, integrazione narrative, generalizzazione cross-domain). È informazione preziosa.

---

## 11. Roadmap Implementativa (3-4 mesi)

### Settimane 1-3: Setup & Dataset

- Setup repo, environment, dependencies
- Data sourcing: identificare provider, sottoscrivere se necessario
- Data ingestion: pipeline dati storici BTC/ETH 2018-2025
- Storage schema (PostgreSQL/TimescaleDB)
- Audit di availability_lag per ogni feature
- Sanity checks: confronto cross-source per validare integrity

**Deliverable**: dataset completo annotato, query-able, con feature catalog.

### Settimane 4-7: Backtest Engine

- Implementazione walk-forward purged CV
- Slippage model (Almgren-Chriss)
- Fees + funding
- DSR computation
- Test di non-leakage (deliberately inject lookahead → engine deve catcharlo)
- Performance optimization (target ≥100 backtest/sec)

**Deliverable**: backtest engine standalone testato. Strategie semplici (buy & hold, 50/200 SMA crossover) producono risultati noti.

### Settimane 8-9: Agenti hand-crafted

- Falsification agent (Tier-B)
- Adversarial agent (Tier-A)
- Protocol fisso (S-expression parser + 15 verbi)
- Message bus auditato semplificato
- Test end-to-end con ipotesi hand-crafted

**Deliverable**: pipeline agente → falsification → adversarial → verdict, funzionante end-to-end con strategie inserite manualmente.

### Settimane 10-12: Hypothesis Swarm + GA

- Population manager (50 agenti)
- Operatori genetici (mutazione + crossover)
- Speciation con clustering embedding
- Fitness computation
- Tournament selection
- Evoluzione per 50 generazioni baseline

**Deliverable**: swarm che evolve, fitness che migliora over generations, output di top strategies.

### Settimane 13-14: Baseline + Comparison

- Implementazione baseline Random Forest
- Run baseline su stesso dataset/timeframe
- Tabella comparison
- Analisi qualitative delle strategie prodotte da entrambi

**Deliverable**: documento di confronto onesto.

### Settimane 15-16: Analisi & Report

- Run finale su hold-out set 2025
- Analysis: ablation multi-tier, regime breakdown, diversity analysis
- Documentazione lessons learned
- Decision document: procedere con sistema completo, iterare PoC, o pivot

**Deliverable**: report finale con risposte alle 5 domande di validazione iniziali.

---

## 12. Costi PoC

### 12.1 LLM costs

| Fase                    | Calls stimate | Tokens stimati  | Tier mix     | Costo  |
|-------------------------|---------------|-----------------|--------------|--------|
| Setup + agenti hand     | ~500          | 2M              | A/B          | ~$50   |
| Test pipeline           | ~2000         | 8M              | B/C          | ~$30   |
| GA run principale       | 50 gen × 50 agent × 10 calls × 5K tok = 125M tok | mostly C, some B | ~$300-500 |
| Repeat runs (3x)        | (per ablation, tuning) | | | ~$1000-1500 |
| Hold-out validation     | ~1000         | 5M              | A (judge)    | ~$80   |
| **Totale**              |               |                 |              | **$1500-2500** |

Più conservativo se aggiungiamo iteration overhead: **budget $2-4K**.

### 12.2 Infrastruttura

- Compute (locale o cloud modesto): ~$200-400 totali
- Storage (data + logs): ~$50/mese
- Data subscription (Tardis o Kaiko per derivatives): variabile, $0-500/mese a seconda della qualità richiesta

### 12.3 Tempo

- Realistic estimate: **3-4 mesi** a 3-4 giorni/settimana effettivi
- Pessimistic estimate: 5-6 mesi se data sourcing risulta più complesso del previsto

---

## 13. Rischi e Mitigazioni

| Rischio                            | Probabilità | Impatto | Mitigazione                             |
|------------------------------------|-------------|---------|-----------------------------------------|
| Data sourcing più complesso        | Alta        | Medio   | Start con CCXT + Binance free, upgrade dopo |
| Backtest engine ha bug subtle      | Alta        | Critico | Test deliberato di lookahead injection  |
| Swarm non batte baseline RF        | Media       | Alto    | È un risultato comunque, non fallimento |
| Costi over-budget                  | Media       | Medio   | Cap hard, monitor settimanale           |
| Time over-budget (5+ mesi)         | Alta        | Medio   | Milestone bi-settimanali, taglio scope se necessario |
| Convergenza prematura del swarm    | Media       | Alto    | Speciation, novelty bonus, immigrazione |
| OpenRouter qualità inconsistente   | Media       | Basso   | Fallback policy, monitor success rate   |

---

## 14. Decisioni Aperte

Da risolvere prima di Fase 1:

1. **Asset focus**: solo BTC, solo ETH, o entrambi? (suggerito: entrambi, per cross-asset features)
2. **Data provider primario**: pagare Tardis/Kaiko o partire con free sources? (suggerito: free per Fase 1, upgrade se necessario)
3. **Hardware**: locale o cloud? (suggerito: locale, dataset ~50-100GB gestibile)
4. **Tier-A budget**: quanto reservare a Sonnet per Adversarial? (suggerito: $300-500 cap)
5. **Frequency primaria**: 1h confermato o scendere a 15min? (suggerito: 1h, evita overfitting su microstructure)

---

## 15. Cosa il PoC NON fa (e va bene)

- NON evolve il protocollo (sistema completo)
- NON co-evolve Falsification e Adversarial (sistema completo)
- NON esplora idiom emergence (sistema completo)
- NON applica a domini non-trading (sistema completo)
- NON cerca breakthrough singoli, cerca **validazione architetturale**
- NON è un trading bot pronto per capitale reale (mai dopo PoC, paper trading prima)

Il PoC è un **esperimento controllato**. Il sistema completo è il prodotto. Sono cose diverse, e va bene così.

---

## 16. Decision Triggers

Dopo PoC, queste sono le decisioni discrete:

**GO al sistema completo se**:
- Swarm produce ≥5 strategie con DSR significativo dopo Adversarial
- Swarm batte baseline RF di ≥30% in best-DSR e diversity
- Strategie sopravvivono a OOS 2025 (regime change)
- Multi-tier ablation conferma valore (no significant loss usando 70% Tier-C)

**ITERATE PoC se**:
- Risultati borderline (alcuni indicatori sì, altri no)
- Bug specifici identificabili (es. GA non diversifica → fix speciation)
- Architettura sembra giusta ma implementazione perfettibile

**PIVOT se**:
- Swarm decisamente perde vs baseline su discovery numerica
- Ma: considerare pivot verso domini non-numerici (offerte commerciali, code review)
- O: considerare uso del swarm come *generator* di ipotesi macro/strutturali, non pattern numerici

---

*Documento da aggiornare durante PoC. Questa è v0.1, scritta prima di qualunque implementazione.*
*Documento principale (sistema completo): `coevolutive_swarm_system.md`*