Multi_Swarm_Coevolutive/poc_trading_swarm.md

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

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:

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

@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)

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)

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